Software Aktuelle und alte Versionen

Hallo Sven,

die "State-Machine" des Ardumowers hat ja immer nur einen Zustand - was genau soll denn in diesem Zustand "TEST" gehen (worauf soll dort alles reagiert werden)? Im normalen Betrieb wird ja ständig zwischen allen möglichen Zuständen gewechselt...

Die Lösung wäre einfach gewesen: IMU Abschalten (z.B. pfodApp: IMU->Use 0) :)

Ich vermute das Kernproblem liegt woanders: der Ardumower könnte Fehler besser anzeigen... ich denke da an:
- Falsche Roboter-Lage (IMU Tilt Error)
- Motorstrom ständig zu hoch (Motor Current Error)
- IMU Kommunikationsfehler (IMU Comm Error)
- RTC Kommunikationsfehler Fehler (RTC Comm Error)
- GPS Kommunikationsfehler Fehler (GPS Comm Error)

Beispielsweise könnte man dafür einen "Fehlerspeicher" einbauen welchen man anzeigen lassen kann. Ähnlich wie OBD beim Auto... Und natürlich Fehlerspeicher zurücksetzen...

Gruss,
Alexander
 
@Sven: jetzt verstehe ich das Problem - "checkAccel()", also Überprüfung und Reaktion auf IMU-Modul steht einfach an falscher Stelle (dort wo generell nur die Sensoren ausgelesen werden sollen).

"checkAccel()" sollte besser in die Automaten-Hauptschleife (CASE STATE_FORWARD) verschoben werden, damit auf diesen Sensor wirklich nur beim Fahren reagiert wird...
 
Genanntes Problem wurde behoben (v0_9_1_8). Desweiteren wurde ein Fehlerspeicher eingebaut (kann per pfodApp ausgelesen werden), welcher beim Einschalten des Roboters gelöscht wird (flüchtig/nicht permanent).
 
Da sich ja einige beim ersten Testen fragen, warum der Roboter gerade dies oder jenes macht, ist mir noch ein neues Features eingefallen: Sensor Counters Plotting!

In v0.9.1.9 kann man per pfodApp nun zuschauen, warum der Roboter gerade etwas wie macht - über die Zeit wird das Auslösen aller Sensoren dargestellt - Beispiel: zunächst habe ich den Roboter nach etwa 10 Sekunden gestartet ("state" ist hochgegangen), bei etwa 20 Sekunden hat der Ultraschall-Sensor ausgelöst ("son" ist hochgegangen). Gleichzeitig wechselt der Roboter den Zustand ("state" ist weiter hochgegangen), d.h. führt ein Drehmanöver durch, bis er wieder im ursprunglichen Zustand ist ("state" wieder normal). Bei etwa 37 Sekunden blockiert der rechte Motor ("motR" ist hochgegangen) - das Drehmanöver wiederholt sich und der Roboter ist wieder im Normalzustand ("state")...


sensor_counter_plotting.jpg

Attachment: https://forum.ardumower.de/data/media/kunena/attachments/905/sensor_counter_plotting.jpg/
 
Zuletzt bearbeitet von einem Moderator:
@Sven: ein gutes Beispiel dafür, warum sowas dem Entwickler nicht einfällt : der Entwickler weiß immer welche Version er gerade in Arbeit hat ;-)

Definitiv ein "Must-have" und kommt natürlich in die serielle Ausgabe und pfodApp...
 
Versionsnummern werden nun per pfodApp (und serieller Konsole) für alle Module (Perimeter, IMU, Stepper) ausgegeben. Beim Bandpass Plot wird der gewählte Bandpass nun besser dargestellt. Alle Plots kann übrings mit zwei Fingern vergrößern um Details besser beurteilen zu können.
 
Hallo ihr :)

da die Winterpause sich dem Ende neigt, will auch ich nun endlich weiter machen.
Habe in den letzten Wochen versucht irgendwie auf dem Aktuellen Stand zu bleiben. Ist gar nicht so leicht bei eurem Tempo.

Nun muss ich jedoch eine Frage los werden. Kann ich einfach auf die neuen Versionen updaten, oder muss da dringend was beachtet werden?

Cuttys aktueller Stand:
ardumower-0-8-8
imu-0-3-6
Receiver-0-4
Sender-0-2 (wobei der ja bleiben kann)

Möchte zum einen auch gern die neue App nutzen und zum anderen hab ich noch immer das Problem mit dem Bluetoothmodul.
Muss ja jedes mal nach Verbindung den Code eingeben. Habe mir zwar inzwischen ein HC-05 zugelegt, aber dort ist es genau so :unsure:
Das Thema gab es ja hier schon mal.

Getestet hab ich es bisher nicht (außer alles zu deinstallieren und neu zu machen). Da es ja inzwischen auch irgendwie direkt über die aktuelle Firmware geht möchte ich es darüber versuchen, oder hab ich da was nicht verstanden?

danke
Gruß Stefan
 
Hallo Stefan,

du kannst einfach updaten - wenn Du die alte Receiver-Verdrahtung verwenden willst, musst Du im Receiver "USE_OLD_WIRING" auf 1 stellen

#define USE_OLD_WIRING 1

und im Ardumower-Code den Code für "old wiring" aktivieren:

ardumower:
// old wiring
case SEN_PERIM_LEFT: return(((double)analogRead(pinPerimeterLeft))/4.0); break;
case SEN_PERIM_RIGHT: return(((double)analogRead(pinPerimeterRight))/4.0); break;

Ich würde aber umstellen auf die neue Verdrathung (siehe Schaltbild), zukünftige Updates sind dann schneller eingespielt.

Über die serielle Konsole kann die Baudrate des HC-05 nun unkompliziert programmiert werden.

Falls irgendetwas nicht klappt, einfach hier fragen :)

Gruss,
Alexander
 
Hallo Alexander,

habe soweit alles um verkabelt. Update vom Mega und dem IMU ist gemacht.

Wollte nun noch den Receiver_Nano updaten, da kommt folgende Meldung:


Meldung.png


Was nu?

Gruß
Stefan


Ach halt, stopp, ups.

hatte die beiden Dateien irgendwie nicht mit in dem Ordner. Sind mir entwischt. Nun hat es geklappt!

SORRY!!!!

Gruß
Stefan
Attachment: https://forum.ardumower.de/data/media/kunena/attachments/949/Meldung.png/
 
Zuletzt bearbeitet von einem Moderator:
So, wollte Cutty grad testen, aber er will nicht.

Also, egal ob ich im Automatikmodus loslegen lasen will, oder ihm mit der App manuell fahren möchte, er piept nur.

Mähmotor geht an, Cutty fährt los und gleich drauf gehen alle Motoren aus und er piept gleichmäßig schnell.

Hatte alle Einstellungen von vor dem Update übernommen (zB. Motorströme für Fahren und Mähen).

Hab ich mal wieder was übersehen?
 
Hallo, ich noch mal

also habe jetzt noch einmal die Verkabelung durch gesehen, es scheint soweit richtig zu sein. Es hat sich ja zu vorher nur die Verdrahtung vom Nano zum Mega geändert, also genau wie beim IMU-Nano. Von daher sollte glaube alles ok sein.

Das Update habe ich für den Mega und die beiden Nanos (Schleifenempfänger und IMU)gemacht. Die Versionen sind von heute.
ardumower0.9.2.2
imu0.6.0.1
receiver0.6.0.1

Soweit sicher auch ok.

Jetzt ist es so, dass egal was ich mit Cutty anstelle, er jedes mal in einem schnellen Intervall anfängt zu piepen.
Egal ob ich zB. einen Kompasstest machen will, oder manuell fahren oder was auch immer machen will.

In der pfod-App zeigt er dann immer den State Err an. Kann aber nix finden warum.

Die Stromwerte der Motoren hatte ich bereits wieder angepasst (wie vor dem Update) da das ja bei der ersten Inbetriebnahme auch das Problem war.

Hab keine Ahnung mehr was das jetzt sein soll. Odometrie hab ich auch auf OFF gesetzt.

Gruß
Stefan
 
Hallo Stefan,

das piepen deutet auf einen Fehler hin - welcher Fehler es ist, kannst Du in der seriellen Konsole (19200 Baud, am Ardumower) oder per pfodApp einsehen ("Error counters"). Dort steht dann bei dem entsprechenden Fehler ein hoher Zählwert. Wenn kein Fehler auftritt, sieht es so aus:

Error counters
IMU comm: 0
IMU tilt: 0
Perimeter comm: 0
RTC comm: 0
RTC data: 0

Vermutl. tritt bei Dir ein Kommunikationsfehler (comm/data) zu einem Modul auf - oder das IMU meint, dass der Roboter auf dem Kopf steht (IMU tilt). Dieser Fehler muss zunächst behoben werden. Falls der Fehler "tilt" auftritt, müssen evtl. die IMU-Kalibrierungsdaten resettet werden. Dazu in der seriellen Konsole des IMU-Moduls den entsprechenden Punkt wählen ("reset calibration data").
Bei Kommunikationsfehlern (comm/data) hingegen ist darauf zu achten, dass die SDA/SCL Leitungen sehr kurz gehalten werden, da ansonsten Kommunikationsfehler auftreten. Das ist bei nur einem Modul weniger kritisch.

Gruss,
Alexander
 
Hallo Alexander,

danke erst mal. Werde es morgen noch einmal angehen.
Bei den Error-Werten stand tatsächlich was, konnte damit aber nicht wirklich was anfangen :-(

Ok, dann bis morgen.

Gruß
Stefan
 
AlexanderG schrieb:
Hallo Stefan,

das piepen deutet auf einen Fehler hin - welcher Fehler es ist, kannst Du in der seriellen Konsole (19200 Baud, am Ardumower) oder per pfodApp einsehen ("Error counters"). Dort steht dann bei dem entsprechenden Fehler ein hoher Zählwert. Wenn kein Fehler auftritt, sieht es so aus:

Error counters
IMU comm: 0
IMU tilt: 0
Perimeter comm: 0
RTC comm: 0
RTC data: 0

Vermutl. tritt bei Dir ein Kommunikationsfehler (comm/data) zu einem Modul auf - oder das IMU meint, dass der Roboter auf dem Kopf steht (IMU tilt). Dieser Fehler muss zunächst behoben werden. Falls der Fehler "tilt" auftritt, müssen evtl. die IMU-Kalibrierungsdaten resettet werden. Dazu in der seriellen Konsole des IMU-Moduls den entsprechenden Punkt wählen ("reset calibration data").
Bei Kommunikationsfehlern (comm/data) hingegen ist darauf zu achten, dass die SDA/SCL Leitungen sehr kurz gehalten werden, da ansonsten Kommunikationsfehler auftreten. Das ist bei nur einem Modul weniger kritisch.

Gruss,
Alexander

Hallo Alexander,

es schaut momentan so aus:
Gleich nach Einschalten von Cutty (Hauptschalter) und Verbindung mit pfodAp.

Error counters
IMU comm: 16
IMU tilt: 0
Perimeter comm: 0
RTC comm: 255 (zählt bis 255 hoch und bleibt dann so)
RTC data: 0

Habe ja momentan erst einmal zwei Nanos in Benutzung. Zum verkabeln habe ich zwei Stiftleisten auf ein Stück Leiterplattenmaterial gelötet. Von dort gehen zwei Kabel verdrillt zum Mega. An der "Hilfsverteilung" sind sie angelötet.
Die beiden Nanos gehen per Steckverbindung zu der "Hilfsverteilung". Kabel sind ebenfalls verdrillt.

Kabellängen
Hilfsverteilung - Mega 12 cm
IMU-Nano - Verteilung 3,5 cm
Schleifennano - Verteilung 2,0 cm

Wie empfindlich sind denn SDA/SCL Leitungen? Die beiden von der Verteilung zum Mega gehen erst direkt am IMU-Nano vorbei und dann kreuzen sie die 5V-Versorgungsleitung und führen dann unmittelbar am Mähmotor vorbei.

Die 5V-Leitung ist mit GND-Leitung ebenfalls verdrillt. Der Mähmotor sollte ja auch nicht stören, da der Fehler ja gleich nach dem Einschalten auftritt und der Motor da noch gar nicht läuft.

Wenn ich Cutty nun starten will, kommt gleich das Piepen, an den Werten ändert sich nix.

Gruß Stefan
 
Zuletzt bearbeitet von einem Moderator:
Hallo Stefan,

versuch mal das RTC/Timer-Modul in der Konfiguration deaktivieren (direkt im Code oder per pfodApp), da Du glaube ich keines verwendest? :)

char timerUse = 0; // use timer?

Gruss,
Alexander

UPDATE: ich sehe gerade, dass sich mal wieder ein Fehler eingeschlichen hat - falls kein RTC-Modul verwendet wird, bitte folgende Zeile in der Roboter-Config wie folgt auskommentieren:

int readSensor(char type){
...
// case SEN_RTC: readDS1307(datetime); break;
 
Hallo Alexander,

das war es. Habs aus kommentiert, nun läuft er. treten nun zwar andere Sachen auf, melde mich aber wenn ich es nicht raus bekomme.

Das "char timerUse = 0; // use timer?" stand bereits auf 0.

Gruß
Stefan
 
Also ich glaub es wird doch nix alleine :whistle:

Schreibe mal hier weiter, das es sich ja um die Umstellung von alter zu neuer Software handelt.

Momentanes Hauptproblem, er reagiert nicht auf die Schleife.
Also beim Empfänger-Nano blinkt die LED je nach Abstand zur Schleife. Auch in der pfodApp ist eine Änderung der Werte bei Schleifenannäherung bzw. überfahren erkennbar, nur es erfolgt keine Reaktion vom Cutty. Der fährt einfach weiter.

Die bei der alten Software ermittelten Werte, habe ich auch jetzt wieder eingetragen.
int perimeterTriggerAbove = 90
int perimeterTriggerTimeout = 40

Muss ich den Schleifen Sender auch updaten, sollte doch auch so gehen?

Gruß
Stefan
 
Hallo Stefan,

der Trigger-Wert (perimeterTriggerAbove) hat sich um den Faktor 4 geändert, da damals mit 10 Bit gearbeitet wurde (ergibt Wertebereich 0..1023) und nun mit 8 Bit (ergibt Wertebereich 0..255), d.h. Du musst den Trigger-Wert um Faktor 4 kleiner machen: 22 - dann sollte es wie damals gehen...

In der pfodApp kann man das übrings mit dem Slider in Echtzeit ausprobieren (Settings->Perimeter). Die Stärke des Signals kann man sich ebenfalls mit der pfodApp anschauen (Plot Perimeter). Der "Peak-Wert" dort ist ausschlaggebend. Einfach mal reinschauen ;-)
http://www.ardumower.de/images/ardumower_perimeter_spectrum_plot.jpg
Gruss,
Alexander
 
Hallo Alexander,

super danke, genau das war es wieder.
Hatte ja so was gelesen, war mir aber nicht sicher. Außer dem hatte ich es nicht genau verstanden :-(

Somit geht auch das und habs glaube begriffen :)

Gruß
Stefan
 
Hallo Alexander,
ich habe mal wieder ein kleines Problem. Der Timer funktioniert nicht wie er soll. Der Cutty startet nicht zu der eingestellten Uhrzeit aus der Ladestation, auch nicht bei "Set Current Time".
Ohne Ladestation läuft zur eingestellten Zeit los und fährt auch wieder in die Station.
Allerdings lässt sich der Mäher dann, wenn er im Timerbetrieb läuft, nicht manuell abschalten (nur über "use Timer No").
Ich habe die Soft 9.1.9 drauf. Die Version 9.2.2 läuft leider nicht. In der seriellen Konsole erscheint nur "Perimeter Comm error". :dry:

Vielen Dank im Voraus und Gruß Rolf
 
Oben