NIBO2 - Test Bodensensoren

[Hero_123]

Hallo Achim

Ich habe ein neues Thema bezgl Bodensensoren aufgemacht, denn dieses Thema hat ja mit dem initializer2.hex nicht so viel zu tun...

Beim Test der Bodensensoren (die 2 vorderen Sensoren) habe ich festgestellt, daß der Nibo noch bis zu 4 cm weiter fährt nach dem Erkennen des "Absturzes" -> 4cm, da würde er auf jeden Fall abstürzen (2,4 cm sind das maximale ohne Absturz)

Mein Programm ist ganz einfach gehalten; in einer while-schleife wird:

copro_setSpeed(tspeed_l, tspeed_r);
copro_update();
if ((value_fl<0x20)||(value_fr<0x20)) {
leds_set_status(2,4);
copro_stop();}

(das sind nur prinzipielle Codeschnipsel!) Die Sollwertvorgabe tspeed_l = 40 Ticks (14cm/s), ki = 15, kp = 20, kd = 10.
Ich wollte auch die Zeit messen, die vergeht, bis der NIBO steht (vom Auslösen des copro_stop() bis copro_speed_l = 0, wollte das über einen interruptgesteuerten Timer/Zähler ISR(TIMER2_COMP_vect) machen, aber der Befehl copro_stop() schaltet die Interruptbehandlung aus (cli() und sei())..und somit geht mein Zähler nicht - es wäre schon interessant, die Zeit zu messen, die der Nibo braucht um zum stehen zu kommen..

ich werde mal checken, ob der Nibo mit dem Befehl copro_setPWM() schneller zum Stillstand kommt, denn ich befürchte, daß er noch weiter fahren würde,wenn der Speedsetpoint größer wäre (z.B. statt 40 Ticks 80 Ticks, wobei die Frage ist - kann er diese Geschwindigkeit überhaupt fahren...

Hero_123

[Achim S.]

Hallo Hero
bin am staunen. So habe ich die Sache noch nicht gesehen. Bin aber noch nicht so weit gekommen. Dein Codeschnipzel sieht ganz gut aus. Bin gespannt auf den Rest. Wenn der Abstand nur 2,4 cm betragen darf ist ja ein Absturz möglich. Komisch. Gerade die Sensoren sollen das doch verhindern.
So wie das aussieht bist du doch in C ganz gut.
Achim

[Hero_123]

Hallo Achim

wg Programmieren in C - bin noch ein Fledgling...zum Test der Bodensensoren - bin der Meinung, der Programmteil mit dem Check der Bodensensoren ("Absturzverhinderung") muß in einem EIGENSTÄNDIGEN Programmteil - Stichwort THREAD - laufen - also "parallel" zum normalen Programm, sodaß bei Absturzerkennung der copro_stop() sofort zum Beenden des Fahrens des NIBO führt - derzeit ist es ja ein sequentielles Abarbeiten und kein paralleles...werde versuchen, mich schlau zu machen, ob eine thread-programmierung beim atmega 128 möglich ist und es eine entsprechende library dafür gibt - und WIE man sie einsetzen kann...

Hero_123

[Hero_123]

Hi Achim

Test Bodensensoren - habe in einer while - Schleife NUR die Bodensoren eingelesen und gecheckt, ob der eingelesene Wert zum Absturz führen würde:
.
.
while(1){
floor_update();
if ((value_fl<0x20)||(value_fr<0x20)) {
leds_set_status(2,4);
copro_stop();}
.
.

und dennoch fährt der NIBO noch ca 4 cm weiter (bei 40Ticks/s)...ist die Anzahl der Ticks 20/s, dann fährt er nur bis knapp zur Mitte der Teflonauflage...habe auch eine avr-thread lib gefunden, bin aber nicht sicher ob man damit den NIBO früher stoppen kann... anzunehmen ist, daß er NOCH weiter fährt, wenn die Anzahl der Ticks z.B 60/s oder 80/s ist... denke, man kann diese Absturzerkennung nicht sicher nutzen...muß noch checken, was passiert, wenn man den NIBO mittels copro_setPWM() zum stoppen bringt

wie weit bist Du mit Deinen Untersuchungen?

Hero_123

[Achim S.]

Hallo Hero
bin noch nicht so weit gekommen wie ich wollte. Kämpfe immer noch mit meinem Rechner. Erläuft zwar aber einiges gefält noch nicht. Durch den Datenverlust musste ich auch erst die Teile vom Magazin zusammensuchen und baue gerade ein neues Teil. Dazu treibe ich mich im Moment viel im Netz rum um einiges zu suchen.
Bis bald Achim

[Thomas$]

probier mal nur mit dem stop befehl
ob der eine so lange verzögerung hat
bzw mal andere geschwindigkeiten

[Hero_123]

Hallo

es kommt darauf an, welche Fkt in der while-schleife aufgerufen werden - wenn KEINE Grafikausgaben erfolgen, stoppt der NIBO bei 40 Ticks gerade noch rechtzeitig (ca 3mm vor Teflon-Rand -> kein Absturz), bei 60 Ticks fährt er ca 3 - 5mm über den Teflon-Rand hinaus -> Absturz.
Ich hatte bei meinen ersten Versuchen mir immer die Drehzahl, Batt-spg und die Bodensensoren am Grafikdisplay anzeigen lassen, diese Anzeigen verursachen eine Verzögerung -> NIBO fährt weiter als gewünscht...
bei den 40Ticks hat er bei mir immer gerade noch rechtzeitig gestoppt (Ubatt = 10V), wenn keine Anzeige erfolgte
die Fkt copro_setPWM(0,0) führt auch nicht zu einem früheren Stopp.
Fazit: 40 Ticks, keine Grafikausgaben - bei mir kein Absturz.

habe mal mein c-file mit angehängt - alles mit NiboLib 2.7

Hero_123

[Lisbeth2010]

Hat sich Dein Problem erledigt? Ich habe zwar nur den "ausgestorbenen" NIBO (1), aber an den Bodensensoren hat sich ja nichts geändert. Innerhalb der while(1)-Schleife wird ja nur einmal ein Motorenbefehl abgesetzt. Wenn der "Abgrund" erkannt wird, sollte ja sofort angehalten werden. Allerdings scheint es so zu sein, dass erst noch ein Schleifendurchlauf gemacht wird. Leider antwortet der Hersteller auf solche Fragen nicht.
Lisbeth

[Hero_123]

Hallo

Nein, das Problem besteht (leider) immer noch; wie Du schon richtig bemerkst, sollte der NIBO nach dem Befehl copro_stop() unverzüglich anhalten (was er nicht macht); es ist schon vorgekommen, daß er ÜBERHAUPT nicht stoppt, obwohl er hätte stoppen müssen...ich habe dann aufgegeben, um ehrlich zu sein.
Ich hatte auch den Hersteller diesbezüglich schon angeschrieben, aber leider keine Antwort erhalten; generell ist es schwer, eine Antwort zu erhalten.

naja, ist schade, denn der NIBO ist eigentlich ganz nett. Es scheint auch keine große User-Community zu geben, sodaß man sich bei Problemen austauschen könnte.

Der Hersteller hat nun ein Forum geschaffen (www.roboter.cc/), da kann man vielleicht/hoffentlich mal Fragen platzieren und hoffentlich(!!) verwertbare (!!) Antworten erhalten.

mfg

Hero_123

[workwind]

Hast Du schon mal versucht eine negative Geschwindigkeit zu setzen um der Trägheit entgegenzuwirken?

[Hero_123]

Hi workwind

nein, habe ich (noch) nicht. Um ehrlich zu sein - auf den Gedanken bin ich noch nicht gekommen; kann ich mal testen -> also anstatt den Befehl copro_stop() bei "Absturzerkennung" den Befehl copro_setSpeed(-20, -20) anwenden...der NIBO wird in diesem Fall dennoch ein Stück weiter fahren, denn der Integrator muß m.E. erst von positiv nach negativ integrieren, müßte er aber relativ schnell machen (kommt natürlich auf die Einstellungen des Reglers an - ki, kp, kd).

Wie schon weiter oben erwähnt, bin ich der Meinung, bei copro_stop() müßte der NIBO2 unverzüglich stoppen, da m.E. die Motorbrücken hw-mäßig spannungsfrei geschaltet werden müßten -> damit ein sofortiger Stopp, denn bei meinem NIBO2 ist kein Nachlauf der Räder, die lassen sich nicht ohne Kraftaufwand drehen....

Ich habe den Eindruck, daß manchmal dieser Befehl nicht abgearbeitet wird, ich muß mir erst noch eine Methode überlegen, wie ich dies sicher nachweisen kann.

mfg

Hero_123

[Lisbeth2010]

Hallo, ich habe eine Lösung für den Nibo (1), aber sie sollte relativ einfach auf den Nibo 2 adaptiert werden können. Sie benutzt den Timer2, der HOFFENTLICH (s. mangelhafte Dokumentation!!)verwendet werden kann. Wie kann man hier Code posten?
Lisbeth

[Lisbeth2010]

Hallo, ich habe eine Lösung für den Nibo (1), aber sie sollte relativ einfach auf den Nibo 2 adaptiert werden können. Sie benutzt den Timer2, der HOFFENTLICH (s. mangelhafte Dokumentation!!)verwendet werden kann. Wie kann man hier Code posten?
Lisbeth


/* Linie einfachst. Erstmal Bodensensoren */

#include <avr/interrupt.h>

#include <nibo/niboconfig.h>
#include <nibo/iodefs.h>

#include <nibo/bot.h>
#include <nibo/i2cmaster.h>
#include <nibo/leds.h>
#include <nibo/delay.h>
#include <nibo/motco.h>
#include <nibo/irco.h>
#include <nibo/floor.h>
#include <nibo/adc.h>

#include "utiliw.h"

#define WHILE_1_TIME_GRID 20
uint8_t counter_1ms;
uint8_t speed_left = 40; // Ticks/Sekunde
uint8_t speed_right = 40; // Ticks/Sekunde


// ------------------------------------------------------------
// ---------- init timer2 -------------------------------------
// ------------------------------------------------------------

void init_timer2(void) {
TCCR2 = 0x00; // normal port operation
TCNT2 = 0x83; // set count value (131)
}

// ------------------------------------------------------------
// ---------- start timer2 ------------------------------------
// ------------------------------------------------------------

void start_timer2(void) {
cli(); // disable global interrupts
counter_1ms = 0;
TCCR2 |= 0x05; // CS02 = 1; CS01 = 0; CS00 = 1 -> clk/128
TIMSK |= (1<<TOIE2); //0x01; // enable timer overflow interrupt
sei(); // enable global interrupts
}

// ------------------------------------------------------------
// ---------- stop timer2 -------------------------------------
// ------------------------------------------------------------

void stop_timer2(void) {
cli(); // disable global interrupts
TCCR2 &= ~0x05; // stop timer
TIMSK &= ~(1<<TOIE2);//0x01; // disable timer overflow interrupt
sei(); // enable global interrupts
}

// ------------------------------------------------------------
// ---------- timer2 ISR --------------------------------------
// ------------------------------------------------------------

ISR(TIMER2_OVF_vect) { // timer2 overflow

// reload counter value high byte; 0x83 corresponds to 1ms
// clk/128 entspricht 125 kHz entspricht 8 us
TCNT2 = 0x83; // 131 bis 256 also 125 mal 8 us
counter_1ms++;

if (counter_1ms >= WHILE_1_TIME_GRID) {
stop_timer2(); // Zeitdauer unbekannt, deshalb stoppen
// Bodensensoren messen
floor_measure_iw();
//zahlausgabe(floor_mw[2]); // da kein Display!

if (floor_mw[2] < 32) { // schwarz = 0, weiß = 1023
motco_stop();
motco_update();
leds_set_status(LEDS_RED,0);
} else {
leds_set_status(LEDS_GREEN,0);
// delta_motco ms nach vorn fahren
motco_setSpeed(speed_left,speed_right);
motco_update(); // jetzt fährt er erst los!
} // end if floor
counter_1ms = 0;
start_timer2(); // alles abgearbeitet
} // end if counter
} // end ISR


/* die main */
int main() {

sei();
bot_init();
i2c_init();
leds_init();
floor_init();
init_timer2();

delay(2000); // damit er nicht gleich losrast!

motco_setSpeedParameters(5,4,6); // Empfehlung vom "Chef"

start_timer2();

while (1) {
// tu was
delay(10000);
}
return 0;
}

[Lisbeth2010]

Hoffentlich verständlich! Wenn nicht: FRAGEN!
Lisbethh

[Hero_123]

Hi Lisbeth2010

Den Code kann man problemlos auf den NIBO2 portieren, Timer2 und Timer0 sind soweit ich gesehen habe, frei. Außerdem ist er sehr gut kommentiert - eine Seltenheit!!

In Deiner ISR fragst Du alle 20ms (+xms wg Einlesen Bodensensoren) ab, ob "Absturzgefahr" besteht, wenn ja, soll der NIBO stehen bleiben,wenn nein, soll er weiterfahren; d.h. bei Dir läuft die stop-routine in einer ISR.

Bei mir läuft bzw lief sie in der "normalen" while-schleife. Mein Problem ist ja, daß er NACH dem Befehl copro_stop() (beim NIBO1 ist das ja der Befehl motco_stop()) NOCH einige cm weiterfährt, abhängig von der Geschwindigkeit (ist manchmal ÜBERHAUPT nicht stehen geblieben). Ich habe derzeit leider wenig Zeit, das mit der ISR bei mir testen, aber ich befürchte, daß die ISR mein Problem auch nicht löst...werde es aber noch testen und Dir Bescheid geben!

Stoppt bei Dir Dein NIBO1 UNVERZÜGLICH, wenn motco_stop() aufgerufen wird oder fährt er auch noch etwas weiter (ein paar cm)?

mfg

Hero_123

[Achim S.]

Hallo
Du hast es so gewollt. Fragen !
Hab da wohl bei einigen Sachen in der Schule gefehlt. Was ist ISP ? Wie viel Timer hat der Nibo? und was ist TCCR und TIMSK? Danke

[Lisbeth2010]

@Hero_123: Ja, der Nibo stoppt unverzüglich, d.h. innerhalb von 20 ms. In der "normalen" while-Schleife kann sonst was passieren, auch wenn es nur ein delay von 20 s ist (zum Beispiel). Die Motorregelung wird alle 10 ms aktualisiert. Es wäre schön, wenn Du mal einen Test durchführen könntest!
@Achim S.: Deine Fragen beantwortet das Datenblatt des ATmega128 (das Gehirn) und das avrgcc Tutorial. ISR = Interrupt Service Routine. Der Nibo hat 4 Timer. Timer 1 wird für die PWM der "Headlights" verwendet. Hier kann man sehr schön das "Dimmen" der LEDs testen.
Viele Grüße
Lisbeth

[Hero_123]

Hi Lisbeth2010

Ich habe es soeben nochmal mit meinem NIBO2 probiert:

- die Bodensensoren nochmal neu kalibriert gemäß Tutorial
- meine timer2 ISR entsprechend Deinem Vorschlag modifiziert

Fazit: bei 40 Ticks fährt der NIBO2 trotz geänderter ISR immer zu weit (stoppt ca 3mm vor ENDE des Teflon-Randes) -> Verhalten wie gehabt (siehe hier weiter oben), der Aufruf in der ISR bringt (zumindest bei mir) leider nicht den gewünschten Erfolg...

wenn er bei Dir innerhalb der 20ms stoppt = STEHT (20ms = Strecke von ca 3mm bei 40 Ticks, da 40 Ticks = 14cm/sek), dann verhält sich bei Dir die Reglung der Motoren anders als bei mir; ich habe ja den Atmega88 als Mot-Regler...

naja, ich kann dann eben die "Absturzerkennung" nicht verwenden. Dumm ist auch, daß ich den Atmega88 (der die Mot-Regelung macht) nicht programmieren kann, da keine ISP Schnittstelle auf dem Bord dafür vorhanden ist.

mfg

Hero_123

[Lisbeth2010]

Hallo,
ich hab nochmal einiges probiert:
Der AD-Wert des rechten Bodensensors unterscheidet sich signifikant von den Werten der anderen. Da das der 1.Wert ist (0!) wird dieser Wert nicht korrekt gemessen (hatte ich schon mal, muß allerdings die Lösung suchen). Versuch es mal nur mit dem linken (1!) Sensor oder aber auch mal testweise mit den Liniensensoren.
Jetzt habe ich aber mal eine Frage: wenn der Raddurchmesser 35 mm ist, dann sollte doch 1 Umdrehung = 20 Ticks = 100 mm sein, oder?
Grüße
Lisbeth

[oberallgeier]

Hallo Hero_123,


... Dumm ... Atmega88 ... nicht programmieren kann, da keine ISP Schnittstelle ...Das macht ja eigentlich nix. Dafür gibt es zum Beispiel diese Lösung, die ich bei kleinen THT-Controllern habe (klick hier). (https://www.roboternetz.de/phpBB2/viewtopic.php?t=54300)

........http://oberallgeier.ob.funpic.de/PCR80_2145.jpg....http://oberallgeier.ob.funpic.de/ISP-aufsteck_2146.jpg........http://oberallgeier.ob.funpic.de/isp_clp.jpg
........Hier ist das Zielsystem(chen) - ...... - und hier - ...... - aufgeklippte ISP-Anschlüsse

Viel Erfolg.

[elektrolutz]

Hallo Lisbeth2010,

Umfang = Durchmesser * Pi
Bei dir also U = 35mm * 3,14 = 110mm.

Hast du andere Räder auf deinem Nibo2?
Bei meinem Nibo2 ist bei originalen Reifen D = 44mm => U = 138mm.
Oder meinst du den Nibobee mit D = 37mm => U = 116mm?

[Lisbeth2010]

Hallo Elektrolutz,
ich habe doch den "ausgestorbenen" Nibo (1). Der hat einen Radurchmesser von 35 mm. Ich frag nur deshalb, weil 123_Hero 40 Ticks pro Sekunde mit 14 cm/s angibt. Wenn aber 20 Ticks eine Umdrehung sind, dann sind 40 Ticks/s = 2*138mm/s = 27.6 cm/s bei Nibo 2 und nicht 14 cm/s oder nicht?
Was weiß man über den "Bremsweg"?
Viele Grüße
Lisbeth2010

[Lisbeth2010]

Hallo, zum Thema Thead: man kann als BS mal freeRTOS einsetzen. Hab ich mal vor ein paar Jahren beim Asuro gesehen, der den ATmega8 verwendet. Hab ich aber für den Nibo (noch) nicht ausprobiert. Wär aber eigentlich ganz interessant... :!:
Viele Grüße
Lisbeth2010

[Hero_123]

Hi

@oberallgeier

danke für die Info, ich habe aber 2 Probleme
-die ISP des Atmega88 ist nicht zugänglich (da müßte ich an der Plantine und der SW rumbasteln, wobei die SW nicht das ganz große Problem sein dürfte)
- ich bin - was das Löten und Basteln mit SMDs angeht - ein "blutiger Anfänger" (und habe derzeit nicht mal die Lötausrüstung dafür und muß mir auch eine entsprechende Lupenausrüstung zulegen)

aber deine Lösung sieht sehr interessant aus




@ Lisbeth2010

in der Doku der nibolib steht ( bei copro_setSpeed(...):

- 40 Ticks entsprechen 1 Radumdrehung
- 29 Ticks/s fahren (= 10cm/s) -> bei 40 Ticks/s = 13, 8cm/s(= ca 14cm/s)

wenn er somit mit 20 Ticks/s macht -> fährt er ca 7cm/s

nb - habe den Raddruchmesser auch gemessen und daraus den Umfang ermittelt - Vertrauen ist gut, Kontrolle ist besser ;)

Ich habe nicht geschrieben, daß 20 Ticks 1 Radumdrehung sind; klar ist nur, daß 40 Ticks = 1 Radumdrehung = ca 14cm (genau 13,8 cm, aber die 2mm habe ich mir geschenkt)

Bremsweg - man muß nach erkennen des Absturzes
- noch die zurückgelegten Ticks (per odometriedaten) einlesen (zählen), die der Nibo macht, bis er steht, diese speichern und dann anzeigen (Display oder per UART an den PC senden)...
- die Zeit messen, die vergeht von "Absturzerkennung" bis Stillstand (die Ticks ändern sich nicht mehr)
-> dann weiß man, wie weit er noch gefahren ist und wann er zum Stllstand gekommen ist (so müßte es gehen..)
wobei der zurückgelegte Bremsweg (zumindest nach meinen Messungen) von der Anfangsgeschwindigkeit abhängt - wie im realen Leben!!!! Je schneller, desto mehr Bremsweg!!O:)

hast Du den "Bremsweg" deines NIBO1 mal gemessen?

mfg

Hero_123

[Hero_123]

Hi Lisbeth2010

Thema thread - habe mir mal die AVR-Threads library 1.3 von Dean Ferreyra runtergeladen und installiert, bin jedoch noch nicht zum Testen gekommen, da zuwenig Zeit

ein anderes BS wie z.B. freeRTOS - ich habe da mal ne Abhandlung gelesen, da wird davon abgeraten, da zuviel Speicher für diese Prozesse benutzt wird (s. u.a. die Bachelorarbeit von P. Teske "Entwicklung einer Bibliothek als Basis für die Programmierung und Steuerung des c'bot", S/30)

Du scheinst ja c-mässig "sehr gut drauf" zu sein ;)

mfg

Hero_123

[elektrolutz]

Hallo zusammen,

was ist denn nun richtig????
In der Doku der NiboLib 2.8 steht, wie schon oben zitiert: "40 Ticks entsprechen 1 Radumdrehung"
Unter http://www.nibo-roboter.de/wiki/Motorcontroller-Firmware
liest man: "...ein Tick ist 1/20 einer kompletten Radumdrehung."


Welche Werte sind denn zu "uint8_t copro_setSpeedParameters ( int8_t kp, int8_t ki, int8_t kd )" eingesetzt? Hat denn schon mal jemand die Regler optimiert? Da die Motore sicherlich einer gewissen Fertigungsstreuung unterliegen und die selbst zusammengelötete Getriebelagerungen auch "kleinen" Streuungen unterliegen, darf man nicht voraussetzten, das die Regler werksseitig auf idealen Werten stehen - das dürft bei jedem Nibo2 anders sein. Je nach Bodenbeschaffenheit kaben die Räder Schlupf und das Gleitpad unterschiedliche Bremswirkung.


Grundsätzlich bekannt ist, dass die Printanweisungen unter C "ZEIT" kosten, siehe Erkenntnis, dass ohne Grafik-Befehle der Bremsweg kürzer ist. (Beim Fahren das ist Displayablesen doch nicht wirklich erforderlich, oder? Mögliche Anwendung: Werte nur bei gedrückter linker Taste zur Anzeige bringen.)


Die Motorregelung läuft auf dem CoProz um nicht vom Programm auf dem Hauptproz zeitlich gestört zu werden. Da macht es wenig Sinn ein wichtiges STOP-Signal im langsamen Programmteil zu ermittel, um es dann irgendwann zum Motorregler weiterzureichen. Da die Bodensensoren direkt an den Hauptproz angeschlossen sind, kann der CoProz diese nicht direkt abfragen und ist auf Signale vom Hauptprozessor angewiesen. Um möglichst kurze Reaktionszeiten zu erreichen bleibt also nur die Einbettung in eine Interrupt-Routine.

[Lisbeth2010]

Hallo,
der elektrolutz hat ja so recht!
Frage 1: Hat jemand das Problem mit dem 1. (nullten) AD-Wert auch?
Frage 2: Die Clock-Division beim Timer 2 ist zumindest in der Simulation des ATmega128 falsch. weiß da jemand was darüber oder sollte ich mal in anderen Foren suchen?
Frage 3: Hat jemand ein Beispiel für das Auslesen der Ticks, die in der ISR noch gemessen werden?
Sonst noch: ja, der Nibo (1) hat andere Räder als der Nibo 2 und offensichtlich auch andere Ticks pro Umdrehung.
Liebe Grüße
Lisbeth

[oberallgeier]

Hallo Lisbeth.

... Frage 1: Hat jemand das Problem mit dem 1. (nullten) AD-Wert auch ...Die schlechten Nachrichten zuerst. Ich habe keine Erfahrung mit den Nibo´s, einige mit dem Nibobee aber keine mit dem mega128. Es wird schlechter: in den Datenblättern der A VR-Controller (die ich gelesen hatte) steht meist etwas über mangelhafte Vertrauenswürdigkeit des ersten Messwertes einer Wandlung.
22. Analog Comparator
• Bit 6 – ACBG: Analog Comparator Bandgap Select
When this bit is set ... certain time for the voltage to stabilize. If not stabilized, the first conversion may give a wrong value. See ...Und diese Warnung steht bei mehreren Bedingungen. Eine übliche Verfahrensweise, die ich in diesem Forum gelernt habe: ersten Messwert (grundsätzlich) wegwerfen.

Die gute Nachricht: ich messe öfters mit dem ADC. Mit recht gutem Erfolg, z.B. bei schnellen Wandlungen in einer Balancier-Regelung. (https://www.roboternetz.de/phpBB2/viewtopic.php?p=446953#446953)

[Lisbeth2010]

Hi Jo,
in einem anderen Projekt haben wir eine bestimmte Zeit nach Setzen des channels gewartet(ungefähr 10 µs). Dann paßt's. Ich probier das morgen mal aus.
Danke für die Antwort.
Lisbeth2010

[oberallgeier]

... in einem anderen Projekt haben wir ... gewartet(ungefähr 10 µs) ...Ungefähr ist nicht dasselbe wie ungefähr-lich *ggg*.
[/size]mel, im gleichen doc wie oben,]23.4 Prescaling and Conversion Timing
... A normal conversion takes 13 ADC clock cycles. The first conversion after the ADC is switched on (ADEN in ADCSRA is set) takes 25 ADC clock cycles in order to initialize the analog circuitry.
When the bandgap reference voltage is used as input to the ADC, it will take a certain time for the voltage to stabilize. If not stabilized, the first value read after the first conversion may be wrong ...Da kein vernünftiger Hardwarebauer das Rad jedes Mal neu erfindet, dürfte das auch für Deine(n) Controller passen.

Nachtrag: ! ADC clock cycles !

[Lisbeth2010]

Hi Jo, bei 16MHz sind 25 clock cycles 1.5625 µs, richtig? 10 µs sind also in jedem Fall auf der sicheren Seite. Gewartet haben wir über den Timer 1, der hochgezählt wurde und bei ich weiß nicht mehr genau, aber so um 10 µs eine Variable auf "TRUE" gesetzt hat. Ich probier's trotzdem mal aus!
Lisbeth2010

[Lisbeth2010]

Das steht im Sourcefile des Nibo/adc.c:
// Warten bis konvertierung beendet, das sollte 25 ADC-Zyklen dauern,
// also 1/4608 s
while ( (ADCSRA & _BV(ADSC)) != 0) {
__asm volatile("nop");
}

Funktioniert aber nicht! Sonst würde der erste Wert ja nicht falsch sein.
@Jo:Was soll ich mit dem Link?
Grüße Lisbeth2010

[Achim S.]

Hallo Lisbeth
Leider ist das mit den Erklärungen so beim Nibo. Viele Sachen probieren wir aus. Ab und zu kommen ein paar Infos. In anderen Foren läuft es besser. Auch der Kollege vom Asuo ist hier fast ständig vertreten. (Siehe Randleiste - Mitglieder). Bei einer Frage habe ich nicht schlecht gestaunt. Die Antwort war ohne Probleme wieder auf meinem Rechner und gut erklärt. Das Gefälle zwischen den Usern ist recht gross. Ich selber zähle mich auch zu den Anfängern. Vielleicht komme ich mal auf eine höhere Stufe. Es ist nur Schade um den Nibo. Ist so ein recht netter kleiner Kerl. In ihm steckt noch viel drin. Ist scheint nun an uns zu sein, was draus zu machen. Die Hardware haben wir. Jede Verbesserung der Software bringt uns Vorteile. Wenn der Hersteller meint, sich in Schweigen zu Hüllen, dann muss er auch mit diesen Seiten und den Meinungen fertig werden. Du hast ja auf seinen Seiten auch ganz schön losgelegt. Lasse mich überraschen wie es weiter geht. Viele User verfolgen diese Diskussion recht Neugierig. Es werden sich aber nur wenige dazu äussern. An Hand der mails die ich bekomme, kann ich das gut verfolgen. Kan dich nur bitten beim Nibo zu bleiben und uns zu helfen. Ich kann den Usen meine ganzen Programme zur Verfügung stellen. Sind extra geschrieben für Anfänger und Fortgeschrittene. Bisher habe ich alle so aus dem Bereich Test. Alle haben reichlich Kommentare und sind gedacht selber was draus zu machen. Werde demnächst eine Liste ins Netz stellen. Kurze mail und das Prg kommt als Worddatei.Hoffe weiter auf deine Unterstützung und Hilfe. Lass uns gemeinsam was draus machen. Habe noch einige Ideen.
Achim S.

[Achim S.]

Hallo Lisbeth
Deine Kommentare sind von der anderen Seite verschwunden.

[oberallgeier]

... Was soll ich mit dem Link ...Allenfalls das Video ansehen. Ich erzähle nicht gerne "Erfolg gehabt" ohne dies halbwegs glaubhaft dokumentieren zu können. Warum ansehen? Um zu sehen, dass der ADC schnell und genau laufen kann; sonst könnte er die Balance-Regelung nicht ingang halten. Er kann das.


... Lisbeth ... Kommentare sind von der anderen Seite verschwunden.Uuups! Verschunden ist gut. Elektronische Datenverarbeitung ist das - man verarbeitet Informationen zu einer Elektronenwolke. Anders ausgedrückt: manche finden Kritik gut - solange es pures Lob ist.

[Hero_123]

Hi

@elektrolutz - wie willste denn sauber (!) einen Regler optimieren, der auf einem Atmega88 läuft, auf den man keinen direkten Zugriff hat? Außerdem kannste nur ki, kp, kd einstellen.. sinnvoll wäre es, wenn man den Atmega88 DIREKT programmieren könnte

Der Nachteil des Reglers ist auch, daß er für BEIDE Motoren gilt....

und ob der zyklische Programmteil langsam ist - das hängt vom Code ab. Klar ist, das der check/Aufruf der copro_stop() fkt in einer ISR mehr bringt - aber der copro_stop() stoppt auch alle anderen ISR... (da cli() und sei()) und dann tut man sich doch etwas schwer, wenn man da noch Zeiten per ISR/Timer messen will ;)

mfg

Hero_123

[Hero_123]

@Lisbeth2010

Hast Du nun mal den Bremsweg deines Nibo gemessen oder nicht??

@elektrolutz

wie stehts mit dem Bremsweg deines NIBO2??

Hero_123

[elektrolutz]

Hallo Hero_123,

richtig, einzige Möglichkeit ist, ein wenig mit ki, kp und kd herumzuspielen und optisch zu erfassen, ob es besser oder schlechter wird. (Wenn überhaupt erkennbar.) Zudem habe ich keine Ahnung, welche Default-Werte eingesetzt sind - habe allerdings auch noch nicht übermäßig viel danach gesucht.
Grundsätzlich müsste man erst einmal prüfen, ob und welche Wirkungen man durch Spielen mit den Parametern erzielen kann. Sind dabei überhaupt Unterschiede zwischen beiden Antrieben erkennbar?
- Wenn ja, dann müsst man bei "workwind" eine entsprechende Änderung beantragen [-o< .
- Wenn nein, dann kann es so bleiben.

Dass copro_stop auch die anderen ISR stoppt hatte ich jetzt nicht im Auge, aber zumindest könnte man, wie von workwind vorgeschlagen, in einer ISR den/die Regler auf "BRUTAL" stellen und entgegengesetzt beschleunigen. Ist sicher nicht die edelste Lösung, dürfte aber von Elektronik und Mechanik verkraftet werden.

Ob die Bodensensoren tatsächlich als Absturzsicherung vorgesehen sind, kann ich nicht erkennen, in der Anleitung steht nur, dass die Sensoren Abgründe erkennen können - und das funktioniert. :-#

Spass bei Seite, ich denke, man sollte die gesammelten Erkenntnisse gut begründet zusammenfassen und workwind dazu ansprechen. Nur so lebt das Produkt weiter und Fehler sowie nicht bedachte Eigenschaften können verbessert werden. Die nächste Lib mit FW kommt bestimmt.

[oberallgeier]

Hallo nibo-Freaks,

vielleicht helfen ein paar Anregungen von meinen einigermassen gelösten Regelungsfragen, die aber nicht den NIBO mit egal welchem Index betreffen.

Hardware: einfach aufgebaute Hardware, Antrieb mit zwei Kleinstgetriebemotoren, eigener Umbau (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=437282#437282) aus billigsten Ser vos, etwa 180 tics pro Radumdrehung (2 Ticks pro Motorumdrehung), Raddurchmesser 24 mm, gesamter Aufbau hier gezeigt. (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=432909#432909) Regelung und alle sonstigen Funktionen mit einem einzigen Controller mega168/m328p mit 20 MHz.

Die von mir aufgebaute und mittels Sprungantwort (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=463986#463986) bzw. den daraus abgeleiteten Kennwerten dimensionierten Regelroutinen (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=451800#451800) (je eine Routine pro Motor) laufen recht schnell (https://www.roboternetz.de/phpBB2/download.php?id=15412) . Das ist durch Integer-Werte bei ziemlich geringer CPU-Auslastung, ca. 5%, gut zu schaffen. Die einzelnen Regleranteile habe ich in 100-Werte-langen Messschrieben nach Testfahrten ausgegeben und mir als Diagramm (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=457587#457587) angesehen. Da kann man gut Überschwinger oder sonstige Eigenschaften erkennen - und natürlich auch Auswirkung von Parameteränderungen. Viele Testfahrten, viele Diagramme, viele fruchtlose Änderungen aber immer wieder mal ein Fortschritt. Als Rumspielerei konnte ich das nicht bezeichnen, da muss man schon ein paar Notizen mit Bleistift und Papier und immer wieder mal eine modifizierte Parameterberechnung mitführen.

Natürlich habe ich auch Bremsmanöver nach verschiedenen Verfahren (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=465839#465839) vermessen. Einfaches, gestuftes Gaswegnehmen, abrupte Wegnahme der Motorversorgung - und als Powerbremse mit bester Bremswirkung: Gegengas (macht man mit jedem größeren Motorboot genauso). Die Diagramme sind über den eben genannten Link erreichbar.

Damit habe ich eine relativ gute Reproduzierbarkeit meines R3D01/MiniD0 erreicht. Es ist schon ein wenig Arbeit reinzustecken, bis es so läuft. Für meinem Nibobee habe ich so eine Regelung nicht gebaut. Da ist soviel Bibliothekszeug drin, das ich erst mühselig entsprechend meinen Ansprüchen übersichtlich aufbereiten müsste - die Arbeit habe ich mir nicht gemacht.

[Lisbeth2010]

Hallo alle zusammen!
Bremsweg ermitteln: Hat jemand einen Hinweis, wie man à la ASURO eine Messfahrt durchführen kann: Auslesen während der Fahrt gespeicherter Daten nach Abschluß der Fahrt in ein Terminalprogramm? Stichwort UART.
Danke!
@oberallgeier: Ich bin - wie 123_Hero auch - kein Löter und Bastler, sondern mehr für Software mit bestehender Hardware.
@elektrolutz: Wie und wo fasst man die gesammelten Erkenntnisse am besten zusammen?
Lisbeth
(Übrigens kann ich keine Entfernung von mir geschriebener Beträge finden! Will dem auch nicht weiter nachgehen.)

[oberallgeier]

... bin - wie 123_Hero auch - kein Löter und Bastler ... mehr für Software mit bestehender Hardware ...Genauso sehe ich das. Ich hatte angenommen, dass bestehende Lösungen ein Hinweis für eure gesuchten Lösungen sein könnten.

[elektrolutz]

Hallo oberallgeier,

Chapeau!
Habe erstmal nur die von dir angegebenen Punkte gelesen, werde aber den Thread mal in Ruhe ab Seite 1 lesen.


... Für meinem Nibobee habe ich so eine Regelung nicht gebaut. Da ist soviel Bibliothekszeug drin, ... Genau das ist der Punkt:
Grundsätzlich sind die Nibos so vorbereitet, dass sie eigentlich einen sehr einfachen Einstieg bieten sollen. Leider ist dazu die Doku noch nicht wirklich fertig und stellt den Einsteiger recht schnell vor große Hürden. (Die große Frage für den Programmierer: Was mache ich zuerst - die Doku oder das nächste Update :-k )
Für etwas fortgeschrittene Anwender sind die Libs dann wieder etwas zu unflexibel, vielleicht auch nur, weil Libs / FWs zu schwach beschrieben sind, bzw. der Funktionsumfang nicht komplett offengelegt ist, oder ergänzungswürdig ist.
Um eigene Libs / FWs zu schreiben muss man dann Experte oder Profi sein.
(Das soll keine negative Kritik sein, das ist meine Einschätzung aus meinem Erwartungs-/Betrachtungswinkel.)

Hier aber erst einmal mein persönlicher Status:
Ich selbst komme aus der hardwarenahen Programmierung für Industrieanwendungen. Hardwarenah bedeutet hierbei die Nutzung vorgefertigter Libs zu eingesetzten Komponenten. C kenne ich aus der Programmierung von Visualisierungen, aber ohne besonders zeitkritische Funktionsanforderung.

Meine Nibos sind meine ersten Kontakte mit der prozessornahen Programmierung, bin da im Frühjahr 2010 recht blauäugig herangegangen. (Ziel war es, die Nibos im Bereich der Ausbildung einzusetzen: erster Kontakt mit Elektronik und Löten, erster Kontakt mit Programmierung.)
Seit dem grabe ich mich durch die Libs, Studio4 mit seinen "Configuration Options" und die umfangreichen Datenblätter der Prozessoren. Das ist spannend, aber auch sehr zeitintensiv. Bin somit grundsätzlich im Thema, bei der programmtechnischen Umsetzung aber sicherlich noch Anfänger.

Da die Prozessoren beim Nibo2 in SMD-Ausführung verbaut sind, ist zumindest der Zugriff auf den ATmega88 (ohne nicht ganz ungefährliche Lötarbeiten) nur über den I²C-Flaschenhals möglich.

[elektrolutz]

Hallo Lisbeth2010,

da workwind nun ein eigenes Forum aktiviert hat, stellt sich die Frage, wie weit und umfangreich er hier noch aktiv sein möchte und ob er auch die Zeit hat, zwei Foren zu betreuen.

Das ist zwar leider kompliziert, aber es wäre nicht schön, hier in diesem Forum Mitglieder abzuwerben, andererseits habe ich aber auch Verständnis, wenn workwind sein eigenes Forum bevorzugt. Ich hoffe, dass sich dazu ein brauchbarer Kompromiss finden wird.

Grundsätzlich wurde das Thema hier geboren, also gehört auch hier die Zusammenfassung hin.
Wenn eine Antwort von workwind ausbleibt, dann sollten wir ersteinmal zweigleisig fahren und die Einverständnis von workwind abfragen, seine Antworten hier zittieren zu dürfen.

[Lisbeth2010]

Hallo!
Frage: Warum hat workwind Zeit ein eigenes Forum zu erstellen, zu betreuen usw., aber offensichtlich keine Zeit, die einzigen aktiven User (so ca. 5-10) mit ein paar Zusatzinformationen zu füttern?
Ich bin gerade noch damit beschäftigt, mehr Infos zu den Bodensensoren und deren Einsatz zu sammeln (absorbieren), deshalb bitte ich um ein wenig Geduld, bis ich wieder etwas "emittieren" kann.
Mein persönlicher Status: Physiker und technischer Informatiker mit Kenntnis des Atmel Prozessors AT90CAN128 und stolzer Besitzer eines ASUROs (selbst gelötet!!!), der allerdings für mein derzeitiges Projekt etwas zu schwach ist.
Noch etwas: Danke für die bisherigen Inputs!
Lisbeth2010

[Hero_123]

Hi

@oberallgeier - starker tobak, Donnerwetter! Muß ich in Ruhe "verdauen" - wie hast Du denn die Plots hinbekommen (mit welchem Programm aufgezeichnet/ausgewertet)?

@Lisbeth2010 - gemäß Deinem letzen Beitrag hast Du den ASURO - somit erübrigt sich mein penetrantes Fragen nach dem Bremsweg

@elektrolutz -die Bodensensoren SIND für die Erkennung eines Abgrundes - und dienen somit der Absturzerkennung. IMHO ist die Fkt copro_stop() bzw deren Übermittelung perI²C nicht ok, denn es ist bei mir mehrmals vorgekommen, daß der NIBO2 NICHT gestoppt hat, obwohl die Bedingung dafür vorhanden war - habe dies auch dem Hersteller gemeldet. Außerdem hatte ich mal irgendwo gelesen, daß die Übermittlung per I²C nur alle 10ms läuft - das ist aber nix für eine schnelle Regelung btw...und wenn ich die ISR mit dem Aufruf von copro_stop() alle 20ms tätige....
Hast DU jetzt schon mal den Bremsweg gemessen?

die einzig saubere Möglichkeit, das hinzubekommen ist:
- die Regelung läuft auf dem programmierbaren (per ISP) Atmega88
- es wird jeder Motor EINZELN geregelt
- der Atmega88 liest die Bodensensoren SELBST ein

->das alles GEHT DERZEIT NICHT => damit ist für mich das Thema erledigt

zum Thema "eigenes Forum" - da muß ich Lisbeth2010 recht geben...

mfg

Hero_123

[oberallgeier]

... Chapeau! ...Merci, de rien.
... wie hast Du denn die Plots hinbekommen (mit welchem Programm aufgezeichnet/ausgewertet ...Danke für die Anerkennung, es freut mich, dass es euch gefällt, hoffentlich nutzt es etwas, da ich ja keine Coprozessortechnik habe. Aber so bekommt ihr vermutlich einen Einblick über Reaktionsgeschwindigkeit bzw. Strecke-je-Tick, über die Regelungswirksamkeit insbes. beim Bremsen, verschiedene Bremsmöglichkeiten und so.

Auswertung und Darstellung: Aufzeichnung zeitgetreu in entsprechend große Felder, nach Ablauf des Testlaufs bzw. der Messung Übertragung per UART ans Terminal. Auswertung mit dem vermutlich weltweit meistgenutzten Simulatons- und Auswerteprogramm für technische Vorgänge - Excel. Vorgehensweise ist hier ausführlicher beschrieben. (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=527790#527790)


... es wird jeder Motor EINZELN geregelt ...Ganz meine Meinung. Damit das nicht zu sehr den normalen Programmablauf beeinflusst, läuft bei mir die Regelung der beiden Motoren zeitlich versetzt - mal der eine, mal der andere (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=437897#437897) - siehe erstes Codefenster im Link. Übrigens regelt der asuro AFAIK nur einen "gemittelten" Motor und "schummelt" durch einen offset die Unterschiede rein.

Reg elungstechnik war für mich ziemlich mühselig. Ne vierLoch in der Klausur - vor vielen Jahren - deutet ja auf keine allzugroße Liebe hin. Aber wenns mal sein muss, dann muss man eben. Übrigens gibt es bei mir noch ungelöste Details - aber eher Nachkommastellen - die mir Kopfzerbrechen machen und deren Lösungsversuch ich schiebe und schiebe und schiebe. Stichwort dazu z.B. lückenlose und drehrichtungstreue Tickbilanzierung, damit Entfernung- und Richtungsrechnung genauer werden und fast nur noch der Räderschlupf als Fehlerquelle bleibt.

[elektrolutz]

Hallo zusammen,

bin gerade mal die Belegung des CoProz laut Schaltplan durchgegangen.
Der ist bis zum letzten Pin ausgereizt.
Leider sind die etwas zeitunkritischeren 5 Abstandsensoren auf den CoProz verdrahtet und die zeitkritischen Absturzsensoren liegen auf dem HauptProz. Hier möchte ich als einigermaßen erfahrener Löter aber nicht herumbrutzeln.
Mit recht überschaubarem Lötaufwand könnte man aber die Absturzsensoren fühlerartig mit schmalen Adapterplatinen in Fahrtrichtung vor den Nibo2 verlegen. Den im ungünstigsten Fall nur 20mm kurzen Bremsweg (3 Löcher auf der Odo-Scheibe - Mitte Sensoren bis Mitte Gleitpad) könnte man so recht einfach mindestens verdoppeln.

@Hero_123,
meine Anmerkung zu den Bodensensoren als Absturzsicherung war mit etwas Sarkasmus gespickt. O:)

Mit dem Bremsentest tüftel ich derzeit noch ein wenig herun. Habe beobachtet, dass die Erkennung eines Abgrundes durch die Sensoren durch einige Faktoren drastisch unterschiedlich ausfällt. Offensichtlich beeinflusst das Umgebungslicht die Erkennung der Sensoren nicht unerheblich, auch scheinen fremde IR-Quellen die Sensoren zu stören. Größtes Problem ist aber die plausible Erkennung einer Tischkannte, bei einer rechtwinklig geschnittenen Holzplatte (ca. 15mm stark) wird der Abgrund erst richtig erkannt, wenn der jeweilige Sensor schon ca. 5-10mm über den Rand hinaus ragt - bedeutet, der zulässige Bremsweg verkürzt sich um diese 5-10mm. Bei meiner realen Tischkannte am Arbeitstisch ist die Kannte abgerundet, ab Beginn der Abrundung ragt der Sensor zur sicheren Erkennung bis zu 15mm hinaus - der Bremsweg bis Mitte Gleitpad dann im ungünstigsten Fall nur noch 5mm.
Diese Werte habe ich durch händisches Verschieben meines Nibo2 ermittelt.
Simuliere ich den Abgrund durch eine schwarze Fläche verhält sich die Sensorerkennung nicht vergleichbar zu einer Tischkannte und reagiert zudem auf matte und glänzende Oberflächen sehr unterschiedlich.
So suche ich erst mal nach einer Lösung, den tatsächlichen Bremsweg als Wegstrecke mit einem Messstab nachmessen zu können.

Ich suche also nach einer Lösung, den Sichtbereich der Sensoren zu begrenzen und gleichzeitig die Einwirkungen fremder Lichtquellen abzuschotten, ohne dabei die Bodenfreiheit zu stark einzuschränken. Muss mal schauen, was ich aus schwarzen Pinselborsten machen kann.

[Hero_123]

Hi elektrolutz

Bodensensoren beim NIBO2 - der Einfluß des Streulichtes/Umgebungslichtes ist klar, da die Sensoren ja nicht abgeschirmt sind (da weist der Hersteller aber irgendwo in seiner Doku drauf hin). Abschirmung - gute Idee. Sensoren weiter nach vorne zu verlagern -> Ändern der HW (naja!!) -> Abstandserkennung muß darauf angepasst werden (ist sw-technisch kein Problem)
Sinnvollerweise müßten sowohl Boden- als auch Abstandssensoren beim Atmega88 eingelesen und verarbeitet werden. Regelung müßte auch geändert werden, ebenso ISP für den Atmega88-> FAZIT es muß ein NIBO3 her ;)

mfg

Hero_123

[workwind]

Ich könnte eine Funktion zum "aktiven" Bremsen in den COPRO bzw. MOTCO Code einbauen: Der Strom würde solange in entgegengesetzter Richtung fliessen, bis die Ticks von der Odometrie das erste mal in die andere Richtung gezählt würden. Danach würde der jeweilige Motor direkt abgestellt werden. Damit sollte der Roboter nahezu direkt anhalten...

[elektrolutz]

Hallo workwind,

das hört sich sehr gut an.
Das wäre dann ein neuer Befehl, der aus einer Interrupt-Routine aufgerufen werden kann und die Interrupt-Verarbeitung nicht abschaltet!

[Hero_123]

Hi

Funktion zum "aktiven Bremsen" - sie muß NICHT ZWINGEND (!!) in einer timergesteuerten ISR aufgerufen werden, es reicht doch schon, wenn der Aufruf DIREKT nach Erkennen des Absturzes geschieht! Die ISR ist doch NUR EIN PFLASTER!!!

Interrupt-Verarbeitung - bei (derzeit) nahezu allen Fkt des copro wird die Interruptbehandlung während der Befehlsausführung abgeschaltet...


@workwind - entspricht dein Vorschlag des "aktiven Bremsens" nicht in etwa dem, daß man beim Erkennen des Absturzes negative Drehzahl als neuen Sollwert vorgeben soll?

mfg

Hero_123

[Achim S.]

Hallo
hätte da auch noch einen Vorschlag zu machen. Das mit dem negativen lauf finde ich richtig gut. Falls ein neuer Befehl verwendet wird ist es vielleicht besser diesen zu teilen. Wenn ich aus anderen Gründen das zählen der Ticks nich verwende, muss trotzdem ein stoppen erfolgen. Dazu könnte ich bei auslösen des stoppens eine bestimmte Zeitspanne, vielleicht 5 mS negativen strom geben. Man kann auch diese Zeit einstellbar machen, so von... bis. Man könnte dei Rückgabe der Ticks nach Stop auch als Wert zurückgeben. Damit könnte eine Längenmessung nach Stop erfolgen. Es währe auch nicht schlecht mal ein bisschen besser Beispiel oder Kommentare zu geben. Wenn die Befehle immer komplexer werden, dann beherschen nur noch wenige den genauen Programmablauf. Eigentlich soll der Nibo 2 doch was für Anfänger und Könner wein.
Achim

[oberallgeier]

Das hatte ich in diesem Thread bereits angeregt:
... - und als Powerbremse mit bester Bremswirkung: Gegengas ... Die Diagramme sind über den eben genannten Link erreichbar ...

... "aktiven" Bremsen ... Strom ... entgegengesetzter Richtung ... sollte der Roboter nahezu direkt anhalten ...Nein. Oder ganz präzise: jedenfalls nicht bei mir.

... Vorschlag des "aktiven Bremsens" nicht in etwa dem, daß man beim Erkennen des Absturzes negative Drehzahl als neuen Sollwert vorgeben soll ...Das kommt auf die Regelung an. Also darauf, wie die Regelung im Einzelnen aufgebaut ist. Aber eine gute Regelung sollte ja nicht brutal und abrupt reagieren, wie das mit der von mir vorgeschlagenen Schubumkehr der Fall ist von der jetzt auch workwind spricht.

[Lisbeth2010]

Hallo @All,
kann mir jemand bei der Verwendung der copro (motco) Funktionen helfen? copro_setTargetAbs(l,r,s) oder motco_setPosition(l,r,s).

Ich habe ein freeRTOS Beispiel für den Nibo. Läßt 2 LEDs in 2 verschiedenen Tasks mit unterschiedlicher Dauer blinken. Ist das vielleicht auch für andere User interessant?
Kann unter AVR Studio 4 auch in der Simulation laufen. Da sieht man dann auf PORTE mal schwarze und mal weiße Kästchen.

Mit den anderen Themen bin ich noch nicht weitergekommen, bleibe aber dran.

Lisbeth2010

[Achim S.]

Hallo Lisbeth
Komme mit deiner Frage nicht so klar. Du gibst den Befehle

copro_setTargetAbs(l,r,s) oder motco_setPosition(l,r,s).

an. Habe in meine Befehlsliste gesehen und im Internet nachgeschaut, da stehen die aber nicht drin. Sind mir nicht bekannt oder habe sie bisher übersehen.
An deinem Prg habe ich auf jeden Fall Interesse. Kannst es mir direkt mailen oder reinstellen.
Achim

[Lisbeth2010]

Hallo Achim S.,
schau mal hier:
http://nibo.svn.sourceforge.net/viewvc/nibo/trunk/src/
Viele Grüße
Lisbeth2010

[elektrolutz]

Hallo Lisbeth2010,

hier die Befehlsbeschreibung entsprechend Lib2.8:

uint8_t copro_setTargetAbs ( int16_t left, int16_t right, uint16_t speed )

Zielposition für Räder setzen. Die Werte werden in Ticks angegeben. 40 Ticks entsprechen einer Radumdrehung.

Parameter:
left absoluter Sollwert für linkes Rad
right absoluter Sollwert für rechets Rad
speed Wert für maximale Geschwindigkeit

Wird benutzt von nibocc::Copro::set_target_abs().

Wo ist das Problem? Für "left" und "right" werden die gewünschen Zielwerte eingegeben und für "speed" die max. Geschwindigkeit. "Absolut" bedeutet, dass die Räder ihr Ziel von der derzeit aktuellen Zählerposition aus anfahren. Ist das Ziel kleiner der aktuellen Position, dann fährt das Rad also rückwärts.

Beim "...Rel..."-Befehl erfolgt die Positionierung um den angegebenen Wert bezogen auf die aktuelle Position.

Ob die Funktion beim Nibo1 "Abs" oder "Rel" ist, leider keine Ahnung. Müsste man ausprobieren, beim Nibo1 müsste dann aber vor dem Befehl noch eine entsprechende Bearbeitung des Zählers erfolgen, die bei Programmübertragung auf den Nibo2 entfallen sollte.

Das mit dem freeRTOS schaue ich mir mal an.

[Lisbeth2010]

freeRTOS: ziemlich viele Dateien. Wie kann man das am Besten "posten"?
Viele Grüße
Lisbeth2010

[Hero_123]

@Lisbeth2010

bin doch etwas erstaunt - die Verwendung der Befehle steht doch in den doc-files der jeweiligen lib... "wer des Lesens mächtig..." ;)

freeRTOS - da sind wohl nicht nur die files, sondern doch etwas MEHR nötig
- eine Installationsbeschreibung
- eine Beschreibung der Befehle
- eine Einbindung in die NIBOLIB
- usw....

- oder bist Du da anderer Meinung?

woher hast du das freeRTOS (weblink etc)?

poste doch mal deinen Code!

mfg

Hero_123

[Lisbeth2010]

Hallo!
Lesen kann ich, was soll das also?

Hier mal ein Video:

http://www.youtube.com/watch?v=SjmQ5mHueG8

1. Durchdrehen
2. Stoppen an einem Isolierband

Falls es jemand interessiert, der Code

/* Laufstall 04.12.2010 - IW
Boden: Fliese hellgrau
Umrandung: schwarzes Isolierband 15 mm breit
nur innerhalb der Umrandung rumfahren
*/

#include <avr/interrupt.h>

#include <nibo/niboconfig.h>
#include <nibo/iodefs.h>

#include <nibo/bot.h>
#include <nibo/i2cmaster.h>
#include <nibo/leds.h>
#include <nibo/delay.h>
#include <nibo/motco.h>
#include <nibo/irco.h>
#include <nibo/floor.h>
#include <nibo/adc.h>

/* eigene Funktion Zahlausgabe binär 0..63 */
int16_t wert;
void zahlausgabe(int16_t wert) {
if ((wert - 32) > 0) {
leds_set_status(LEDS_GREEN, 5);
wert = wert - 32;
} else {
leds_set_status(LEDS_OFF, 5);
}
if ((wert - 16) > 0) {
leds_set_status(LEDS_GREEN, 4);
wert = wert - 16;
} else {
leds_set_status(LEDS_OFF, 4);
}
if ((wert - 8) > 0) {
leds_set_status(LEDS_GREEN,3);
wert = wert - 8;
} else {
leds_set_status(LEDS_OFF,3);
}
if ((wert - 4)> 0) {
leds_set_status(LEDS_GREEN,2);
wert = wert - 4;
} else {
leds_set_status(LEDS_OFF,2);
}
if ((wert - 2)> 0) {
leds_set_status(LEDS_GREEN,1);
wert = wert - 2;
} else {
leds_set_status(LEDS_OFF,1);
}
if ((wert - 1)> 0) {
leds_set_status(LEDS_GREEN,0);
} else {
leds_set_status(LEDS_OFF,0);
}
} // end Zahlausgabe

/* eigene Funktion floor_measure() 2x wg. erster AD-Wandlung */
int16_t floor_mw[4];
void floor_measure_iw() {
floor_enable_ir();
floor_mw[0] = 1023-adc_read(0); // Bodensensor von oben in Fahrtrichtung rechts
floor_mw[1] = 1023-adc_read(1); // Bodensensor von oben in Fahrtrichtung links
floor_mw[2] = 1023-adc_read(2); // Liniensensor von oben in Fahrtrichtung links
floor_mw[3] = 1023-adc_read(3); // Liniensensor von oben in Fahrtrichtung rechts
//nochmal, wir haben ja Zeit...
floor_mw[0] = 1023-adc_read(0); // Bodensensor von oben in Fahrtrichtung rechts
floor_mw[1] = 1023-adc_read(1); // Bodensensor von oben in Fahrtrichtung links
floor_mw[2] = 1023-adc_read(2); // Liniensensor von oben in Fahrtrichtung links
floor_mw[3] = 1023-adc_read(3); // Liniensensor von oben in Fahrtrichtung rechts
floor_disable_ir();
}

/*-----------*/
/* Laufstall */
/*-----------*/

uint8_t speed_left = 100; // Ticks/Sekunde Testwert
uint8_t speed_right = 100; // Ticks/Sekunde Testwert

uint16_t floor_left;
uint16_t floor_right;

void laufstall() {
floor_left = floor_mw[1]/16;
floor_right = floor_mw[0]/16;
//zahlausgabe(floor_right); // da kein Display! keine negativen Werte!
// floor_left auf gelb: 7, auf schwarz: 0, auf Fliese 6, auf Fuge 3
// floor_right auf gelb: 8, auf schwarz: 0, auf Fliese 6, auf Fuge 3
if ((floor_left < 2) || (floor_right < 2)) { //ABGRUND: STOP
leds_set_status(LEDS_ORANGE,0);
leds_set_status(LEDS_ORANGE,5);
motco_stop();
motco_update();
delay(1000);
motco_setSpeed(-50, -50);
motco_update();
delay(1000);
motco_stop();
motco_update();
} else {
leds_set_status(LEDS_GREEN,0);
leds_set_status(LEDS_GREEN,5);
motco_setSpeed(speed_left,speed_right);
motco_update();
}
} // end laufstall


#define WHILE_1_TIME_GRID 10
uint8_t counter_2ms;

// ------------------------------------------------------------
// ---------- init timer2 -------------------------------------
// ------------------------------------------------------------

void init_timer2(void) {
TCCR2 = 0x00; // normal port operation
TCNT2 = 0x83; // set count value (131)
}

// ------------------------------------------------------------
// ---------- start timer2 ------------------------------------
// ------------------------------------------------------------

void start_timer2(void) {
cli(); // disable global interrupts
counter_2ms = 0;
// Datenblatt falsch!! S. 106 Table 56
TCCR2 |= 0x04; // CS02 = 1; CS01 = 0; CS00 = 1 -> clk/256
TIMSK |= (1<<TOIE2); //0x01; // enable timer overflow interrupt
sei(); // enable global interrupts
}

// ------------------------------------------------------------
// ---------- stop timer2 -------------------------------------
// ------------------------------------------------------------

void stop_timer2(void) {
cli(); // disable global interrupts
TCCR2 &= ~0x05; // stop timer
TIMSK &= ~(1<<TOIE2); // disable timer overflow interrupt
sei(); // enable global interrupts
}

// ------------------------------------------------------------
// ---------- timer2 ISR --------------------------------------
// ------------------------------------------------------------

ISR(TIMER2_OVF_vect) { // timer2 overflow

// reload counter value high byte; 0x83 corresponds to 1ms
// clk/128 entspricht 125 kHz entspricht 8 us
// Datenblatt falsch! clk/256 = 0x04 0 => 2ms
TCNT2 = 0x83; // 131 bis 256 also 125 mal 16 us
counter_2ms++;

if (counter_2ms >= WHILE_1_TIME_GRID) {
stop_timer2(); // Zeitdauer unbekannt, deshalb stoppen
// Bodensensoren messen (2 mal)
floor_measure_iw(); // schwarz = 0, weiß = 1023 bzw. 63=1023/16 Integer!
laufstall();
counter_2ms = 0;
start_timer2(); // alles abgearbeitet
} // end if counter
} // end ISR


/* die main */
int main() {

sei();
bot_init();
i2c_init();
leds_init();
floor_init();
init_timer2();

leds_set_status(LEDS_GREEN,5);
delay(2000); // damit er nicht gleich losrast!
leds_set_status(LEDS_OFF,5);

motco_setSpeedParameters(5,4,6); // Empfehlung vom "Chef"

start_timer2();

while (1) {
// tu was.. oder nix
delay(10000);
}
return 0;
}



Viele Grüße Lisbeth2010

[Lisbeth2010]

Hallo nochmal,
wenn ich

//motco_setSpeed(-50, -50);
motco_setPosition(-20,-20, 20);

das Auskommentierte durch ...setPosition... ersetze, fährt Nibo eben nicht!!! rückwärts. Das war die Frage nach dem "Befehl".

Grüß Dich, workwind!

Die Lisbeth2010

[workwind]

Hallo Lisbeth2010,

Du rufst aus dem Interrupt-Context die delay() Funktion auf! Da es sich um einen Timer-IRQ handelt, kann während des delays ein weiterer IRQ ausgelöst werden - das gibt Chaos auf dem Stack....
Es ist sicherer im Timer-IRQ nur ein Flag zu setzen, und in der main-Funktion auf dieses Flag zu warten um von dort die laufstall() Funktion aufzurufen.
Das Flag muss dabei volatile definiert werden, da ansonsten der Optimizer die Zugriffe aus der main Funktion auf die Variable wegoptimiert.

Interrupt-Programmierung hat so seine Tücken!




volatile uint8_t timer_flag;

...

ISR(TIMER2_OVF_vect) { // timer2 overflow
...
counter_2ms++;
if (counter_2ms >= WHILE_1_TIME_GRID) {
timer_flag = 1;
counter_2ms = 0;
}
}

...

int main() {
...

while (1) {
if (timer_flag) {
floor_measure_iw();
laufstall();
timer_flag=0;
}
}
}

[Lisbeth2010]

Hast Du gesehen, dass ich den Timer AUSSCHALTE?
Die Lisbeth2010

[Lisbeth2010]

Ach ja, hier noch der freeRTOS Link:
http://elk.informatik.fh-augsburg.de/da/zba-1/Dokumentation/lucinkiewicz_thesis.pdf
Die Lisbeth2010

[workwind]

motco_setPosition hängt von den aktuellen Odometriewerten ab. Du solltest motco_resetOdometry(0, 0) vorher aufrufen, damit motco_setPosition(-20,-20, 20) die Räder rechts und links um 20 Ticks zurückgedreht.

[Lisbeth2010]

//motco_setSpeed(-50, -50);
motco_resetOdometry(0, 0);
motco_setPosition(-20, -20, 20);
motco_update();

... geht auch nicht!
Die Lisbeth2010

[Lisbeth2010]

Gegenprobe:
motco_setSpeed(-50, -50);
//motco_resetOdometry(0, 0);
//motco_setPosition(-20, -20, 20);
motco_update();
...geht!
Die Lisbeth2010

[workwind]

Geht denn Folgendes?
motco_resetOdometry(20, 20);
motco_setPosition(0, 0, 20);

[Lisbeth2010]

motco_resetOdometry(20, 20);
motco_setPosition(0, 0, 20);
//motco_setSpeed(-50, -50);
//motco_resetOdometry(0, 0);
//motco_setPosition(-20, -20, 20);
motco_update();

... geht auch nicht!

[workwind]

"... geht auch nicht!" heisst er zuckt nicht einmal - oder bewegt er sich so wie er nicht soll?

[Lisbeth2010]

Zuck nicht mal!

[Hero_123]

@Lisbeth2010

Dein "laufstall" - interessantes Programm.....hmhm....ja - aber warum alles in der timer-ISR?

der link zu freeRTOS..hm, ja...

freeRTOS - wolltest Du nicht den code posten, wo LEDS mittels freeRTOS unterschiedlich blinken? Einige User interessiert dieser Code bestimmt

mfg

Hero_123

[workwind]

Hallo Lisbeth2010,
Ich habe den Fehler im Motco Code gefunden, Du bekommst in Kürze einen neuen Initializer um die Motco Firmware zu updaten...

[Lisbeth2010]

@workwind: Habe keine Erfahrung im Updaten der Firmware. Bitte Instruktionen für Nibo ohne Index!
@Hero_123:
"aber warum alles in der timer-ISR?" damit das Stoppen am Abgrund = Isolierband" funktioniert!!!!
"Einige User interessiert dieser Code bestimmt" nun ja,fix und fertige SW ist ja immer "interessant". Ich mach das hier hobbymäßig!! Ich hab auch nur die Information aus dem Link gehabt und einen Nibo!
Also nicht drängeln und nörgeln!
Die Lisbeth2010

[Lisbeth2010]

Hier mal ein Screenshot der eingebundenen freeRTOS Dateien.
Und hier der Code der main.c, die hier freeRTOSminimal.c heißt. Das Programm hält an einer schwarzen Linie (Isolierband) an und fährt zurück. Der 2. Task schaltet nur eine LED. Als Zugabe: Binäre Ausgabe einer Zahl zwischen 0 und 63.
Danke auch an cypax.net, der das so oder ähnlich schon mal für den ASURO gemacht hat.
Das hex-File hat 31 kByte.


/* FUNKTIONIERT!!! 09.12.2010 IW*/

#include <avr/interrupt.h>

#include "FreeRTOS.h"
#include "task.h"

#include <nibo/niboconfig.h>
#include <nibo/iodefs.h>

#include <nibo/bot.h>
#include <nibo/i2cmaster.h>

#include <nibo/leds.h>
#include <nibo/delay.h>
#include <nibo/floor.h>
#include <nibo/adc.h>
#include <nibo/motco.h>

int y = 1;

// a struct to pass parameters to tasks
typedef struct LED_PARAMETERS {
unsigned int LED; //the LED the task should use
unsigned int FlashRate; //the rate at which the LED should flash
} xLEDParameters;

//a simple function to set DDR-registers and initial state of the LEDs
void Init(void);

//this function starts two tasks
void StartLEDFlashTasks(unsigned char uxPriority);

//1st task
void TASK1(void *pvParameters);

//2nd task
void TASK2(void *pvParameters);

// Binäre Ausgabe auf LED
void zahlausgabe(int16_t wert);

// Bodensensoren messen
void floor_measure_iw();

// anhalten an Isolierband
void laufstall(void);

int main(void) {
Init();

bot_init();
i2c_init();
leds_init();
floor_init();

StartLEDFlashTasks (1);
// Start Scheduler
vTaskStartScheduler();
return 0;
}

void vApplicationIdleHook(void) {
y++;
}

//A simple function to set DDR-registers and initial state of the LEDs
void Init(void) {
// Set port E direction to outputs. (LED RED Nibo)
DDRE = 0xFC;
PORTE &= ~((1<<PE7) || (1<<PE6)); // aus (Startbedingung)
}

void StartLEDFlashTasks(unsigned char uxPriority){
//pointer to struct to pass task parameters
xLEDParameters *pxLEDParameters;
//FlashRate for 1st task
const unsigned int FlashRate1 = 2000/portTICK_RATE_MS;
//FlashRate for 2nd task
const unsigned int FlashRate2 = 4000/portTICK_RATE_MS;

// Create and complete the structure used to pass parameters to the next Created task.
pxLEDParameters = (xLEDParameters *) pvPortMalloc(sizeof(xLEDParameters));
pxLEDParameters->LED = (1<<PE7); //1st task will use LED on pin PE7
pxLEDParameters->FlashRate = FlashRate1;
// Create the task.
xTaskCreate(TASK1, (signed char *) "TASK1", configMINIMAL_STACK_SIZE, (void *) pxLEDParameters, uxPriority, (xTaskHandle *) NULL );

// Create and complete the structure used to pass parameters to the next Created task.
pxLEDParameters = (xLEDParameters *) pvPortMalloc( sizeof( xLEDParameters ) );
pxLEDParameters->LED = (1<<PE6); //2nd task will use LED on pin PE6
pxLEDParameters->FlashRate = FlashRate2;
// Create the task.
xTaskCreate(TASK2, (signed char *) "TASK2", configMINIMAL_STACK_SIZE, (void *) pxLEDParameters, uxPriority, (xTaskHandle *) NULL );
}

void TASK2(void* pvParameters) {
xLEDParameters *pxParameters;
pxParameters = (xLEDParameters *) pvParameters;
while(1) {
PORTE = PORTE | (pxParameters->LED);
vTaskDelay(pxParameters->FlashRate/2);
PORTE = PORTE & ~(pxParameters->LED);
vTaskDelay(pxParameters->FlashRate/2);
}
}

void TASK1(void* pvParameters) {
xLEDParameters *pxParameters;
pxParameters = (xLEDParameters *) pvParameters;

while(1){
floor_measure_iw(); // schwarz = 0, weiß = 1023 bzw. 63=1023/16 Integer!
laufstall();
}
}

/* eigene Funktion Zahlausgabe binär 0..63 */
int16_t wert;
void zahlausgabe(int16_t wert) {
if ((wert - 32) > 0) {
leds_set_status(LEDS_GREEN, 5);
wert = wert - 32;
} else {
leds_set_status(LEDS_OFF, 5);
}
if ((wert - 16) > 0) {
leds_set_status(LEDS_GREEN, 4);
wert = wert - 16;
} else {
leds_set_status(LEDS_OFF, 4);
}
if ((wert - 8) > 0) {
leds_set_status(LEDS_GREEN,3);
wert = wert - 8;
} else {
leds_set_status(LEDS_OFF,3);
}
if ((wert - 4)> 0) {
leds_set_status(LEDS_GREEN,2);
wert = wert - 4;
} else {
leds_set_status(LEDS_OFF,2);
}
if ((wert - 2)> 0) {
leds_set_status(LEDS_GREEN,1);
wert = wert - 2;
} else {
leds_set_status(LEDS_OFF,1);
}
if ((wert - 1)> 0) {
leds_set_status(LEDS_GREEN,0);
} else {
leds_set_status(LEDS_OFF,0);
}
} // end Zahlausgabe

/* eigene Funktion floor_measure() 2x wg. erster AD-Wandlung */
int16_t floor_mw[4];
void floor_measure_iw() {
floor_enable_ir();
floor_mw[0] = 1023-adc_read(0); // Bodensensor von oben in Fahrtrichtung rechts
floor_mw[1] = 1023-adc_read(1); // Bodensensor von oben in Fahrtrichtung links
floor_mw[2] = 1023-adc_read(2); // Liniensensor von oben in Fahrtrichtung links
floor_mw[3] = 1023-adc_read(3); // Liniensensor von oben in Fahrtrichtung rechts
//nochmal, wir haben ja Zeit...
floor_mw[0] = 1023-adc_read(0); // Bodensensor von oben in Fahrtrichtung rechts
floor_mw[1] = 1023-adc_read(1); // Bodensensor von oben in Fahrtrichtung links
floor_mw[2] = 1023-adc_read(2); // Liniensensor von oben in Fahrtrichtung links
floor_mw[3] = 1023-adc_read(3); // Liniensensor von oben in Fahrtrichtung rechts
floor_disable_ir();
}

/*-----------*/
/* Laufstall */
/*-----------*/

uint8_t speed_left = 20; // Ticks/Sekunde Testwert
uint8_t speed_right = 20; // Ticks/Sekunde Testwert
uint16_t taskdelay = 2000;
uint16_t floor_left;
uint16_t floor_right;

void laufstall() {
floor_left = floor_mw[1]/16;
floor_right = floor_mw[0]/16;
//zahlausgabe(floor_right); // da kein Display! keine negativen Werte!
// floor_left auf gelb: 7, auf schwarz: 0, auf Fliese 6, auf Fuge 3
// floor_right auf gelb: 8, auf schwarz: 0, auf Fliese 6, auf Fuge 3
if ((floor_left < 2) || (floor_right < 2)) { //ABGRUND: STOP und zurück
leds_set_status(LEDS_ORANGE,0);
leds_set_status(LEDS_ORANGE,5);
motco_stop();
motco_update();
vTaskDelay(taskdelay);
motco_setSpeed(-speed_left/2, -speed_right/2);
motco_update();
vTaskDelay(taskdelay);
motco_stop();
motco_update();
} else {
leds_set_status(LEDS_GREEN,0);
leds_set_status(LEDS_GREEN,5);
motco_setSpeed(speed_left, speed_right);
motco_update();
}
} // end laufstall

Für Nibo2 muß motco durch copro ersetzt werden.
Die Lisbeth2010

[Hero_123]

@Lisbeth2010


damit das Stoppen am Abgrund = Isolierband" funktioniert!!!! - beim ersten c-File war in der main nur das delay(10000) -> da ist IMHO keine ISR nötig


"Einige User interessiert dieser Code bestimmt"
Du hattest selbst am 07.12 Code bezgl freeRTOS und den LEDS angeboten


Also nicht drängeln und nörgeln! ne, haste recht, das rentiert sich nicht :(


nun ja,fix und fertige SW ist ja immer "interessant". - naja, unter "fix und fertige SW" versteht jeder was anderes - und Deinen Code kann man eh nur nutzen, wenn man das dafür passende freeRTOS installiert hat - also was solls...

[Lisbeth2010]

und Deinen Code kann man eh nur nutzen, wenn man das dafür passende freeRTOS installiert hat - also was solls...
Was meinst Du damit?
Die Lisbeth2010

[Lisbeth2010]

Hab eben erst nochmal Deine Antworten richtig gelesen:
Zu Punkt 1: [Sarkasmus an] Nö, das wäre auch IMHO nicht nötig gewesen. Solle "nur" zeigen, daß unabhängig von dem Interrupt irgendetwas passieren kann. [Sarkasmus aus].
Zu Punkt 4: freeRTOS ist für alle da: Kernel UNABHÄNGIG vom Professor .. 'tschuldigung: Prozessor.
Nix für ungut sagt die Lisbeth2010
@workwind: Updates???

[workwind]

Bin noch bei motco_stopImmediate() ....

[Hero_123]

@Lisbeth2010

Zu Punkt 4: freeRTOS ist für alle da: Kernel UNABHÄNGIG vom Professor .. 'tschuldigung: Prozessor. - hast also doch Probleme mit dem Lesen, habe NIE in Frage gestellt, ob freeRTOS für alle da ist

und wegen "drängeln und nörgeln" ->
@workwind: Updates???

denke, damit sollten wir es belassen, s'wird langsam kindisch, und für einen"flamewar" sollten wir beide das Forum nicht nutzen

vielleicht bekommst Du ja doch noch das, was du willst....

[workwind]

Update:
http://sourceforge.net/projects/nibo/files/nibo/nibolib-2.9-20101210/

* neue Firmware für den COPRO
* aktives Bremsen mit copro_stopImmediate()
* Verbesserungen für den Nibo 1

Infos zum Software Update für den COPRO:
http://www.nibo-roboter.de/wiki/Initializer2_Software

[Hero_123]

Hallo

Achtung - neueste NiboLib V2.9 -> es gibt im directory "...src/examples2/stop_immediate_test" das main.c-file => da fehlt:

#include<spi.h>

mfg

Hero_123

[Uli_s]

Hallo,

nach langer Pause ich mal wieder :-& .

Heute mal die neue Lib 2.9 aufgespielt und einige Programme aus Examples probiert. Led1, Led3, Obstacle2 haben funktioniert, Line2 net so ganz, lag aber am farblich diffusen Untergrund (Laminat).

Nun gut, denke ich, alles updaten und neu kalibrieren. Copro upgedatet mit der neuen initializer2.hex nach Anleitung in Bauanleitung.

Bodensensoren neu kalibriert (Schwarz=schwarz; weiß=helles Laminat).

Hat für die Linienfolgerprgramme nix gebracht - eher schlechter. Aber seitdem läuft Motor links vorwärts nur Vollgas, rückwärts mit vorgegebener Drehzahl. In allen meinen schönen Progrämmchen!!

Zurückinstallation auf Lib2.7 und Copro neu initialsieren und Sensoren kalibrieren brachten keine Abhilfe.

Hat die initializer2.hex (Stand 10.12.2010) meinen Copro verbogen? Hat jemand eine Erklärung, warum der linke Motor nur Vollgas vorwärts fährt, rückwarts aber mit der vorgegebenen Drehzahl?

Gruß
Uli

[workwind]

Ich vermute das die IR-LED auf der Odometriesensorplatine nicht mehr korrekt ausgerichtet ist, die Software sollte da nichts verändern.

[Uli_s]

Bingo!!

Zerlegt, gereinigt, Ausrichtung geprüft (war nix verbogen), zusammengebaut.

Lag wohl an der Verschmutzung.

Danke.

Gruß
Uli