Auch wenn ich meine Smartphone App nicht mit dem Nibo verbinden will, bekomme ich die Verbindung mit dem PC und Teraterm mit einem Bluetooth Stick hin.

Wie das im Grundsatz funktioniert steht ja hier: Nibo Serial Protocol

Es gelingt mir auch über request set 3, 15 alle LEDs zu setzen und mit 3, 0 wieder zu löschen. Aber ich möchte ja den Burger fahren. Der Quellcode des Terminalprogramms ist leider überhaupt nicht dokumentiert. Dass es ein Parser ist und das drum herum habe ich soweit verstanden. Ich habe diese Register:

0: [r ] BOT ID
1: [r ] Version
2: [r ] Supply Voltage [mV]
3: [rw] LEDs
4: [r ] Sense
6: [rw] Motor Mode
7: [rw] Motor PWM L
8: [rw] Motor PWM R
9: [rw] Motor PID L
10: [rw] Motor PID R
13: [r ] Odometry L
14: [r ] Odometry R
16: [r ] Line C
17: [r ] Line L
18: [r ] Line R

Wie ich die Register 6,7,8,9 setze um den Burger in Bewegung zu bekommen ist mir nicht klar. Die App scheint ja die Lagesensoren in Fahrbefehle umzuwandeln soviel konnte ich ja auf dem Video erkennen. Ich kann im Code aber nicht erkennen wie ich die Register ansteuere.

Wie NSPREG_MOTMODE den Burger in Bewegung bringt. Hat da einer eine Idee?

Gruss Boson

Hallo Boson,

habe das Niboburger - Terminalprogramm getestet. Der Niboburger hat sich auch nicht bewegt.
Werde heute im Terminalprogramm einige Debugzeilen einfügen, damit ich das Programm
besser verstehe. Beim Nibo2 hatte es fehlerfrei funktioniert, aber das ist schon einige Jahre her.
lg Georg

Hi Georg,

die Erklärung in NIBO Wiki ist falsch! Dort steht:

"Beispiel: PID links (Register 3) auf 20 Ticks/sec, rechts (Register 4) auf 25 Ticks/sec und den Motor Mode (Register 5) auf 3 setzen"
Das wäre der Befehl: request set 3, 20 set 4, 25 set 5, 3

Nur ist PID gar nicht Register 3 und 4 sondern 9 und 10 und Motormode ist Register 6 man könnte also glauben wenn der Befehl so lautet:
request set 9, 20 set 10, 20 set 6, 3 fährt der Burger - tut er aber nicht, um ihn zum fahren zu bekommen bedarf es aber der PWM Register!
Tatsächlich fährt der Burger vorwärts mit
request set 8,20 set 7,20 set 6,3
los und mit request set 6,0 stopt er! mit
request set 8,-20 set 7,-20 set 6,3[/b] fährt er rückwärts


alles hängt wohl in dieser Switch in main.c

switch (nsp_registers[NSPREG_MOTMODE]) {
case 0: motpid_stop(1); break;
case 1: motpid_stop(0); break;
case 2: motpwm_setLeft (nsp_registers[NSPREG_MOTL]);
motpwm_setRight(nsp_registers[NSPREG_MOTR]); break;
case 3: motpid_setSpeed(nsp_registers[NSPREG_MOTL], nsp_registers[NSPREG_MOTR]); break;
}

Das genaue Zusammenspiel zwischen Motor_PWM und Motor_PID ist mir noch nicht ganz klar, wie gesagt im Text ist ja nichts kommentiert. Quick and dirty!

Aber ich bekomme das noch raus. Würde mich freuen wenn du deine Ergebisse mir mitteilst. Ich werde meine posten.

Gruß Boson

Hi Boson,

für den Niboburger gilt in der Dokumentation die Beschreibung vom Nibobee mit nur 18 Registern.
Im Programm ist ein Fehler: Die Variable mode wurde global und lokal in update() definiert.
Ändere in der Funktion update() die Zeilen 77 - 79

uint8_t mode = nsp_registers[NSPREG_MOTMODE);
if (mode != oldmode){
if (mode==2){

in

uint8_t mode_lokal = nsp_registers[NSPREG_MOTMODE);
if (mode_lokal != oldmode){
if (mode_lokal==2){

um. Jetzt sollte das Programm funktionieren.
Bei der Gelegenheit ist mit aufgefallenm dass Register 4 Semsors nicht programmiert ist,
der Niboburger erkennt zur Zeit beim Fahren keine Hindernisse.

lg Georg

Tatsächlich haben die auch über die Hilfe ausgegeben Register kaum was mit der Wirklichkeit zu tun.

In der file niboprot_reg.h sieht man deutlich den Unterschied zwischen Wunsch und Wirklichkeit "prot" steht hier vermutlich nur für "Prototype" was ja legitim ist aber nicht ganz fair den Programmieren gegenüber, dass man einfach keine Lust mehr hatte weiter zu machen.

Zuerst die tatsächlichen Register, die durchgestrichenen werden im Code nicht abgefragt (Register 9) oder sind mit einem "TODOO" gekennzeichnet:

NSPREG_BOTID = 0,
NSPREG_VERSION = 1,
NSPREG_VSUPPLY = 2,
NSPREG_LEDS = 3,
NSPREG_SENS = 4,
NSPREG_MOTMODE = 6,
NSPREG_MOTL = 7,
NSPREG_MOTR = 8,
NSPREG_MOTSPEED = 9,
NSPREG_ODOL = 13,
NSPREG_ODOR = 14,
NSPREG_LINEC = 16,
NSPREG_LINEL = 17,
NSPREG_LINER = 18,

Nun die Hilfe, sie sugeriert mann könne PWM und PID getrennt von einander setzen und auch die Geschwindigkeit. Das war wohl mal die Idee, wurde aber so nicht umgesetzt:

" 1: Version\n"\
" 2: Supply Voltage [mV]\n"\
" 3: LEDs\n"\
" 4: Sensors\n"\
" 6: Motor Mode \n"\
" 7: Motor PWM L \n"\
" 8: Motor PWM R \n"\
" 9: Motor PID L \n"\
"10: Motor PID R \n"\
"13: Odometry L \n"\
"14: Odometry R \n"\
"16: Line C\n"\
"17: Line L\n"\
"18: Line R\n"\

Im Grunde wird zur Motorsteuerung im Programm nur mit dem Register NSPREG_MOTMODE und NSPREG_MOTL bzw. NSPREG_MOTR gearbeitet. Ist MOTMODE auf 0,1,2 steht der Burger bzw. hält an. Über die Register 7 und 8 wird die Geschwindigkeit gesetzt, dabei ist es egal welcher MOTMODE gerade eingestellt ist. Nur wenn der der MOTMODE 3 gesetzt wird, wird die Routine motpid_setSpeed aufgerufen und der Burger setzt sich mit der zuvor in Register 7 und 8 eingestellten Geschwindigleiten in Bewegung. Dabei ist es egal ob bei Setzen der MOTMODE 0,1,2 aktive ist. In Motmode 2 wird motpwm_setLeft bzw. motpwm_setRight aufgerufen. Ich konnte jedoch keinen Unterschied zwischen MOTMODE 0,1,2 ausmachen. In MOTMODE = 2 werden jedoch diese Zeilen durchlaufen.

if (mode==2) {
motpid_release(); // Der PID Regler gibt die Kontrolle über das PWM Signal wieder frei. Die PWM-Werte werden nicht verändert!
} else {
motpid_init();
}

Da man jedoch MOTMODE wieder auf 3 setzen muss, um loszufahren war das wohl mal ein Versuch, der nicht ganz klar ist. Wie es scheint fährt der Burger immer mit PID - wenn er fährt.

Fazit: Das Programm / Protokoll ist eine gute Vorlage, wenn auch total unkommentiert und fehlerhaft, um eine Bluetoothverbindung einzubinden, einen Parser aufzubauen und den Burger zumindest teilweise vom PC (Die Handy App sehe ich als reine Spielrei) zu steuern und Daten zurückzu bekommen. Wenn man sie sinnvoll mit anderen Programmen kombinieren würde - Hindernis ausweichen z.B. Damit könnte man eine Teilautome Variante schaffen, in der ein PC z.B. als "Großer Bruder" vom Burger Daten erhält und je nach Informationen Befehle (Aufgaben) an den Burger sendet. Dazu müßte zunächst mal die Sensoren Erfassung ausprogrammiert werden. Außerdem ist dann ein Programm auf dem PC nötig, dass die übergeortnete Rolle übernimmt. Hierfür gibt es noch keine Vorlage.

Wenn ihr andere Erkenntnisse habt laßt es mich wissen.

Gruß Boson

Hi Georg,

Deine Änderungen haben Auswirkungen. Allerding nicht ganz wie gewünscht. Beim Losfahren macht er jetzt zunächt eine Kurve. Augenscheinlich hast du eine lokale Varible eingeführt, aber zu welchem Zweck? Am Ende bricht die Bluetooth Verbindung zusammen!Vermutlich sind aber meine Akkus alle Ich Teste nochmal nach aber erklär die lokale Variable doch mal.

Gruß Boson