Hi BirgerT

Ich hab' bislang noch keine Probleme mit dem set_TargetRel und set_TargetAbs gehabt, habe es aber bislang nur im test_01.c ausprobiert; ich habe Dein Programm bislang noch nicht testen können.
Mit dem Sekundenschlaf - das könnte u.a. ein Problem sein, das auftritt, wenn Displayausgaben gemacht werden oder wenn irgendwie Interrupts zuschlagen...Das Blöde ist, daß man dieses Verhalten auch nicht sonderlich gut debuggen kann; problematisch weil zeitraubend sind Displayausgaben.

Egon

Hallo BirgerT,

mit dem Programm test_01.c von Egon habe ich experimentiert.
copro_setSpeed habe ich durch erfolgreich durch copro_setTargetAbs,
bzw. copro_setTargetRel ersetzt.
Nachdem ich zusätzlich die Abfragen mit copro_ticks_l / copro_ticks_r durch
copro_target_distance ersetzt hatte, bewegte sich der Nibo nicht mehr.

Georg

Inzwischen klappt eine Programmversion mit copro_target_distance!!!

Hi Georg und Egon,
vielen Dank für Eure Hinweise, zur Zeit habe ich echt die Lust verloren..
Habe letztes Wochenende mal versucht mit set Target eine Kurvenfahrt (Kreisbogen)hinzubekommen:also mit setTarget kann man nur geradeaus fahren oder drehen..
nächster Versuch:das scheint das KillerKommando zu sein, macht nur Knack und alles duster..?! Bei Euch auch??
Das mit dem Sekundenschlaf meine ich auch gesehen zu haben; es liegt augenscheinlich daran, dass der Motorregler (PID) etwas länger braucht noch den letzten fehlenden Tick für copro_target_distance auszuregeln.
Weiterhin musste ich feststellen, dass zwischen einem Commando an den copro und dem copro_update() eine längere Pause erforderlich ist. Wie Ihr ja wisst ist der copro der SPI Master, der alle 10ms dem MainBrain (Mega128) die aktuellen Copro Werte überträgt - werden in einen Buffer geschrieben - und als Antwort die neuen Befehle gesendet bekommt. Erst bei einem copro_update werden die Werte aus dem SPI rx Buffer in die entsprechenden Variablen kopiert.
Wenn man also dem Copro ein setTarget angibt und das copro_update zu schnell kommt, werden die Werte von vor dem neuen Kommando geholt.
In der Mainloop also erst Kommando an copro aufrufen, Displayausgaben sorgen für Wartezeit und dann erst das copro_update aufrufen.

Hallo BirgerT,

als Anlage sende ich Dir ein von mir geändertes Programm von Egon NIBO2_Test_01.c .
copro_setSpeed ist durch copro_setTargetRel ersetzt.
Egons Abfrage der Endpositionen ist durch copro_target_distance==0 ersetzt.

Das Programm funktioniert.
Nur ist mir unbegreiflich, dass 120 Ticks vorwärts nicht -120 Ticks rückwärts entsprechen. copro_setTargetRel verursacht irgendwie Fehler.

Georg

Hi Georg, echt nett von Dir, mir zu helfen..
habe mir das Programm bis jetzt nur angesehen und ich denke mal, dass der Fehler vorwärts != rückwärts daran liegt, dass das copro_update() zu früh nach einem set_TargetRel() aufgerufen wird. Versuch's doch mal mit'nem delay(20) vor dem copro_update(), oder mit 3 o. 4 Zeilen Displayausgabe: Target links rechts, Ticks links rechts, Speed links rechts und target distance.

Ich bin eigentlich auch schon weiter: Habe ein Array (Tabelle) mit command, speed, paramL und paramR drin; das Tourprogramm liest beim Start ein Kommando mit parametern und in einem switch(cmd) werden dann die copro funktionen mit den Parametern aufgerufen.

Würde als nächstes beigehen, dass der Nibo den Sensoren folgt, so dass man messen kann wieviel Ticks für eine Volldrehung oder eine bestimmte Strecke nötig sind. Die Angaben aus der Lib kann ich jetzt nicht mehr nehmen, weil ich jetzt mit Lego Technik Reifen einen super Grip habe, allerdings auch eine breitere Spur.
[url=http://http://www.roboter.cc/index.php?option=com_kunena&func=view&catid=3&id=656&limit=6&limitstart=6&Itemid=20#1339][/url]

Und schon probiert, was passiert wenn setTarget mit speed == 0 aufgerufen wird?

Hallo

Ich habe damals das test_01.c geschrieben, um damit das Fahrverhalten in Zusammenarbeit mit meinen XBEE-Modulen zu testen, gemäß Programm soll der NIBO 120 Ticks vorwärts machen und nach 2sek wieder diese 120 Ticks zurück machen; dies macht er auch (mit einer Wiederholgenauigkeit von ca 1-2%), d.h. er macht ca 121-122 Ticks und fährt da rückwärts bis er ca -1 ...-2 Ticks gemacht hat.

Mit einem delay zu arbeiten -das ist aber nur "ein Pflaster draufkleben", das gleiche gilt für Displayausgaben.

Wenn Ihr genaue Messungen machen wollt geht das nicht über's Display, da solltet Ihr die zu messenden Daten an den PC schicken (XBEE etc), denn nur da kann man sauber auswerten, was der Kerl wirklich macht.

Ich lasse mir bei meinen Fahrversuchen u.a. anzeigen Motorströme, Ticks (li/re), Ubatt, Zeit für Zyklusdurchlauf, Speed(li/re), Fahrkommando, Abstandssensoren, Boden/Liniensenoren (per XBEE auf'n PC), dann Auswertung per Excel; das Schöne daran ist, daß man das dann auch grafisch darstellen und auswerten kann- und ich steuere den NIBO auch per PC (Vorgabe neuer Sollwerte oder Fahrkommandos etc).

Egon