I2C-Problem bei laufenden Motoren?? (Oder anderes Kommunikationsproblem)

Hallo RP6ler,

ich habe seit einiger Zeit ein für mein Projekt ernstes Problem:
Ich lese in LabView die via BTM222 ankommenden Sensordaten aus. Und das sind mittlerweile nicht wenige:
Von der Base (Slave) kommt alles Übliche sowie zwei weitere Sharps und zwei Bumper hinten. Von der M32 (auch Slave) kommt Micro und Taster, von M128 kommt Zweitbatteriestand, Vier IR-Abstandssensoren, SRF02, zwei von der Snakevision und Temperatur sowei Luftfeuchtigkeit.

Mein Problem ist, dass sobald der RP6 fährt, der Fluss meiner Daten total ins stocken kommt. Und zwar nur von der M32 und der Base, das heißt ACS-und Bumperdaten vorne und hinten, Helligkeit, Mikro, Buttons, Geschwindigkeit, RC5-Empfang und Batterie werden nur noch alle ca. 3 bis 15 Sekunden (genauer gehts nicht, das kommt mal so und mal so) aktualisiert. Dass es an meinem LabView-Programm nicht liegen kann, nehme ich an, da die Daten der M128 wunderbar aktuell sind. Ebenso werden Befehle vom PC an den RP6 sofort umgesetzt, auch auf allen Boards (Servos, Motoren, Lichter, ACS an/aus, ... ).

Im Klartext: Befehle werden auf allen Boards IMMER umgesetzt, Sensoren kommen von Base und M32 nicht mehr an die M128, sobald die Motoren an sind.

Kann mir da bitte jemand helfen? Gibt es da eine Lösungsmöglichkeit? Kann es etwa sein, dass die Base bei angeschalteten Motoren mit der Motorregelung so sehr gefordert wird, dass sie die Register vernachlässigt?
Zur Anmerkung: Ich benutze nicht die standard-Interrupt-Einstellungen auf der M128, sondern die von FabianE. - kann es daran liegen?

Danke Euch allen!
Fabian

Hallo,

das kann viele Ursachen haben (sowohl auf dem Master als auch auf den Slaves) und ist allgemein schwer zu debuggen wenn man nur einen Forenbeitrag vor sich hat ;)

Läuft der I2C Bus mit 100kBit/s oder 400kBit/s? Mal umschalten.
Wieviele Daten fragst Du wie häufig ab?
Bytes / s ?
Natürlich entsteht noch Protokoll overhead (Start, Stop, pausen... ) also die 400kBit/s ist NICHT die Nutzdatenrate.

Ändert sich in Deinem Programm auf der M128 irgendwas wenn die Motoren laufen?
(werden mehr Daten abgefragt...?)

Klappt es wenn Du die Daten weniger häufig abfragst oder ein paar Daten weglässt?
Frag mal NUR die Base oder NUR die M32 ab.
Nutzt Du die Interrupt Signale oder fragst Du einfach IMMER ALLE Sensordaten ab?


Die Regelungsroutinen auf der Base benötigen natürlich zusätzliche Rechenleistung und es werden durch die Drehgeber Interrupt Events im MEGA32 erzeugt (je Flanke ein Interrupt - d.h. 625 je Radumdrehung und Encoder).
Die Regelungsroutinen werden standardmäßig alle 200ms aufgerufen.

Bitte auch bedenken das der MEGA32 auf der Base mit 8MHz läuft (weniger Energiebedarf) und nicht mit 16MHz wie auf dem RP6-M32 Modul.

MfG,
SlyD

Oha, viele Fragen, ich versuche sie mal zu beantworten:
Bus läuft, soweit ich weiß mit 100kBit/s. Wie kann ich ihn umstellen?
In der M128 ändert sich soweit nix. Der Fahrbefehl wird empfangen, decodiert und in veränderter Form ins Register für die Base geschrieben.
Ich kann mal versuchen, das Register zu kürzen, vielleicht läuft es dann besser.
Wenn ich die M32 auskommentiere, also nur die Base verwende, verändert sich auch nix.
Wenn ich das richtig sehe, werde die Daten stets ausgelesen, Bumper und ACS vorne legen aber Int0.

Soll ich einfach mal die Dateien hochladen? Ich glaube, ich kann nicht alle Fragen gut genug beantworten:

Zitat:

---

Läuft der I2C Bus mit 100kBit/s oder 400kBit/s? Mal umschalten.
Wieviele Daten fragst Du wie häufig ab?
Bytes / s ?
Natürlich entsteht noch Protokoll overhead (Start, Stop, pausen... ) also die 400kBit/s ist NICHT die Nutzdatenrate.

---

___EDIT:
Vielleicht sollte ich noch erwähnen, dass es mal besser, mal schlechter geht. Hin und wieder treten überhaupt keine Probleme auf.
_____
___EDIT2:
Wo kann ich denn die Int-Leitungen wieder auf standard zurücksetzen? Nur in der M128 oder muss ich das in allen drei Controllern machen?
Habe gerade gesehen, dass die Meisten Sensoren nur etwas schlechter als vorher reagieren, aber die schlimmsten Probleme liegen in den vorderen Bumpern und dem vorderen ACS - also genau den beiden Sensoren, die via Interrupt abgefragt werden.

Grüße

Hi,

Zitat:

---

Vielleicht sollte ich noch erwähnen, dass es mal besser, mal schlechter geht. Hin und wieder treten überhaupt keine Probleme auf.

---

Wenn ich das lese würde ich Tippen das es was mit der Spannung zu tun hat, kurze spannungseinbrüche.

Wieviel Akku Power hast du noch wenn es fehler gibt und wenn alles funzt?
Haben die Motoren einen Seberaten Akku, als die M32 und M128?

Denn es kann sein das bei Hoher Motorlast oder bei Richtungsänderungen zu Fehlfunktionne bei den Hirnen kommen !

Edit:
Kannst du mal die Akku Daten loggen, denn das kann den fehler eingrenzen ?
Mal messen wieviel beim M32 ( Base ), M32 ( Erw ) M128 ankommt.

MFG Oliver G

> Soll ich einfach mal die Dateien hochladen? Ich glaube, ich kann nicht alle Fragen gut genug beantworten:

Wird wohl nicht anders gehen nur ob ich Zeit habe 1000 Zeilen Code en Detail durchzugehen ist eine andere Sache ;)
(nur Du weisst wo Du rumgebastelt hast und die Stellen solltest Du dann auch dick und fett markieren)

Du hast allerdings auch noch nicht gesagt mit welcher Rate / Interval Du die Sensoren abfragst.


Was Oliver sagt kann auch durchaus ein Problem sein.

MEGA32 8MHz
+ MEGA32 16MHz
+ MEGA128 14.x MHz
+ Display? (Hintergrundbeleuchtung!)
+ 2x SRF02
+ 4x GP2Dxxx? (die ziehen recht viel)
+ paar andere Sensoren und weitere Elektronik
+ x ?

Dann noch + 2 Motoren...

Da kommt schon einiges zusammen und man sollte gute Akkus verwenden.
Hast ja auch schon ein zweites Akkupack drauf?
Was davon ist an welchem Akku dran?

Steck sonst probehalber mal die US und IR Sensoren ab und ggf. auch das Display.

(das schon recht komplexe System erstmal wieder aufs minimum reduzieren - nur M128 und Base am besten.
Wenn das läuft kannste den Rest wieder zuschalten)

MfG,
SlyD

Jo, werd ich mal so machen. Ich verwende gerade ein 9V- Netzgerät. Das war aber nur ein recht billiges, ich werde morgen mal in der Uni mit einem guten rangehen und es damit testen. Wenn es nicht klappt, wird alles runtergeschmissen, was geht (2 Sharps, Servos, LCD, ACS vorne können ruck-zuck via Jumper abgesteckt werden) .
Wie kann ich denn die Abfragerate rausfinden?

@SlyD: Wenn du erlaubst, dann lade ich die Dateien mal für Dich hoch. Die einzig wichtigen Dinge sind, denke ich, die Register in den Slaves (sind in den Mains) und das .cc-File "PCConnection"
Ich habe eigentlich nicht allzuviel rumgebastelt an den Programmen vom FabianE.
- Register in Base verlängert um zwei Sharps (ADC0 und 1) und zwei Bumper sowie um RC5-Code und -Toggle
- M32: ich glaub gar nix
- M128: Register auslesen dementsprechend angepasst, alle 8 ADCs werden gelesen, alle von mir zusätzlich angebrachten Sensoren (2 Sharps, 2 Bumper, 1 SRF02, 2 Sensoren vom Snakevision, 4 Sensoren vom 2D-IR-Abstandssensor, 1 Luftfeuchtigkeitssensor, 1 Batteriesensor) werden zusätzlich an die Serielle ausgegeben, ebenso RC5-Codes.

STOP: Dateien zu groß (war ja klar! )

Zitat:

---

Die maximale Dateigröße für diesen Dateityp beträgt 488,3 KB. Deine Datei ist 877,5 KB groß.

---

Bist du bei der Dropbox? Dann könnt ich sie dir darüber schicken. Oder pn mit eMail oder wie es für dich am günstigsten ist!

Grüße und Danke für die Hilfe!

Du hast eine PN.

Aber ob ich Dir dabei helfen kann weiss ich nicht - der Code stammt ja von FabianE und nicht von mir...


> Wie kann ich denn die Abfragerate rausfinden?

Na die sollte ja irgendwo festgelegt sein darüber wie oft eben anfragen gestartet werden.
Muss ich mir den Code mal ansehen - scheinbar hast Du selbst die Funktionsweise ja nicht so ganz vollständig nachvollzogen ;)

Hab das mal kurz angeschaut.


Also im Slave (RP6Base) kannste erstmal das hier:

Zitat:

---

Zeile 489...
if(getStopwatch1() >= 1000)
{
SerialHeartBeat();
StartErrorFrame();
writeString_P("RP6 Remotrol ist mit dem Slave-Controller verbunden!\n");
writeString_P("Das Kabel muss an den Master-Controller angeklemmt werden!\n");
EndErrorFrame();
setStopwatch1(0);
}

---

rauswerfen spart schonmal etwas Rechenzeit (die UART Ausgabe ist ja blockierend und die Baudrate ist standardmäßig nur 38.4kBit/s also dauert das länger als man denkt sowas auszugeben - könnte man natürlich auf 500kBit/s erhöhen).
Ist ja nix an der seriellen Schnittstelle angeschlossen also dürfte das überflüssig sein.

Dann mal schauen obs was bringt in RP6CCLib.cc
Zeile 841:
// I2C Modul initialisieren:
I2C_Init(I2C_100kHz);

in 400kHz zu ändern.

Bei viel Datenverkehr auf dem Bus ist das sinnvoll.


Dann in M128_PCConnection.cc
Zeile 725:
timeBetweenFrames = 240;

mal probehalber auf 1000 oder 2000 erhöhen.

Die SRF02 im Code deaktivieren und auch alles andere was nicht benötigt wird.


Dazu dann noch die Hardwaregeschichten die oben schon vorgeschlagen wurden.

Dann schrittweise wieder zuschalten und testen.

MfG,
SlyD

Das ist doch schon mal einiges.
Ich verwende jetzt 2 Netzgeräte:
Ein gutes für Base, M32 und M128. Ein nicht ganz so gutes für BTM222, Snake, Kamera, 2D-IR, 2 Sharps, LED-Scheinwerfer, Servos -> Damit kann man denke ich die Stromschwankungen ausgrenzen!?!???
Das gute Netzgerät zeigt mir einen Stromverbrauch von 250mA an bei 5cm-Motorgeschwindigkeit (Geschwindigkeitsparameter liegt bei 20 von 200) und 160mA ohne Motoren. Kann das so stimmen?

-> Habe in der Base rausgestrichen, was du sagtest.
-> Habe die Rate auf 400kHz erhöht.
Danach ging es schon besser. Die meisten Sorgen machen ACS vorne (ACS hinten mit den beiden Sharps geht einwandfrei), der RC5-Empfang, die Motordrehzahlen. Die Lichtwerte kommen mit geringer Verzögerung (so 2 Sekunden etwa) - solange die Motoren laufen. Ohne Motoren geht alles wunderbar.
Mit Motoren haben die anderen Sensoren (Mikro und Snakevision, 2D-IR-Sensor und SRF02) eine ganz leichte Verzögerung gegenüber ohne Motoren.

-> Habe dann die Framerate erhöht auf verschiedene Werte (1000, 300, 100, 2000, ...) mit folgendem "Erfolg":
Bei geringeren Werte als die 240 kommen die Sensorwerte, die vorher auch gut kamen, schneller an (klar!) und bei zu hohen war einfach zu viel Zeit zwischen den Frames, das kann auch nicht die Lösung sein.

EDIT:
Habe gerade noch was verändert: ObstacleLeft bzw -Right werden nun IMMER gesendet, nicht nur, wenn der alte Obstacle-Wert nicht mehr dem neuen entspricht. Und siehe da: Es geht besser, zwar auch mit mehr als 1 Sek Verzögerung, aber es kommt immerhin immer (irgendwann) ein Wert!

Juhuuu!
Habe noch mal die TimeBetweenFrames runter auf 180 und es funzt einfach alles :cool:
Die Daten kommen mit nicht mal 1 Sek Verzögerung :p
Ergo: Ein Problem ist, dass die M128 manchmal wohl das "ObjektLinks!" überlaufen hat und es nicht gesendet hat. Man muss also Obstacles immer senden lassen.

Super, danke Euch!
Danke Dir SlyD fürs "Korrekturlesen" der Programme.
Ich hoffe, wenn meine drei Profs das Projekt morgen begutachten, geht auch noch alles... :rolleyes:


-> RC5-Code-Empfang geht aber immer noch nicht. Auch wenn ich die RC5_Data immer senden lasse...

Freut mich :)

Es gibt sicher noch viel weiteres Optimierungspotential.
Dazu müsste man aber den Code mal etwas detaillierter auseinanderpflücken...

Ok!
Traust du mir sowas zu? :D
Ich bin in Sachen Programmieren ja ned so der Über-Horst... Ich bin immer noch am Lernen, was das angeht.

Vielleicht kann ich ja mit dem FabianE. mal was dazu machen.


Hier mal ein Foto von dem Ungetüm:
Man erkenn die Kamera mit SRF02, den 2D-IR-Sensor und hinten das SnakeVision.
Verbaut sind gerade 5 Platinen.

Soso. Also mit zwei Netzgeräten klappt das ganze um einiges besser, aber auch da gibts gerne mal Probleme.
Aber ich schalte jetzt alle "schlimmen" Verbraucher wie IR-LEDs, Scheinwerfer, Snake, Kamera &CO automatisiert an, wenn es das Programm erfordert (z.B. Rückwärtsfahrt) und ab, wenn nicht.
Das hilft.

Habe mittlerweile die Vermutung, dass es gar nicht so sehr an der Stromversorgung von außen scheitert, sondern am 5V-Regler der Base.
Nehmen wir an, Motoren, Scheinwerfer und ACS vorne läuft. Dazu kommen vielleicht drei/vier Status-LEDs, drei ATmega, die anderen Sensoren (Licht, Motorstrom und Drehzahl, Mikro und Temperatur, LCD).
Dann kommt da doch einiges zusammen, was der 5V-Regler erst nachliefern muss.
Ich überlege, den Motorstrom noch auf den Zweitakku zu legen mit einem eigenen 5V-Regler und Stromunterstützung durch einen Transistor.
Die brauchen - nehme ich an - 5V und nicht die Batteriespannung, oder?

Grüße

Hallo fabqu,

die Motoren benötigen die Batteriespannung, aber wenn dein Zusatzakku 7,2V kannst du die Spannung ja vor dem 5V-Regler abgreifen.

Gruß Thomas

@fabqu
Erst mal muss ich sagen dein Teil schaut super aus !! :p

Du kannst dir auch einiges einsparen wenn du den Spannungsregler der Cam austauschst, kleines schwarzes längliches gummiteil !
Denn die Cam kann kannst du auch mit 3,3 bis 4,9 V ich glaub 5,0 würde auch noch gehn betreiben ( Hab es mal ohne Spannungsregler an 3,3V dran gehabt, aber bei 4,9V geht es auf jeden fall ) wie es sich aber auf die reichweite auswirkt weiss ich noch nicht!
Aber ich hab die erfahrung gemacht dass man mit Spannungsregler nicht unter 7,5V kommen sollte, denn ab da hab ich dann kein Bild mehr! Auf den Datenblatt 9 -12V also verbrät das teil viel leistung!
Ach ja sei beim abschneiden des Gummi sehr vorsichtig ( wegen den Fingern und der Platine ) und wenn das teil weg ist mach nicht den fehler wie ich mehr als 4,9V drauf zu geben so hab ich schon mal eine Cam gekillt.
vergiss auch nicht eine schutzdiode ( -0,7V an der Diode 1N4002 ) dran zu machen ( verpolungsschutz ) es sei denn es kann dir nicht passieren.

Auf diesen Bild kannst du Spannungsregler sehn ( Links die kleine Platine ) -> http://www.meinkleinerzoo.eu/MeinRP6/Bilder/Innenansicht1a.jpg
diesen Spannungsregler hab ich nur noch drin bis ich einen andern hab. Da ich über ein labornetzgerät den Strom bekomme ist das zZ noch egal aber wenn ich ihn über Akkus aufen lass ist der regler weg!
Wenn du es wilst mach ich mal ein bessers bild des Spannungsreglers.



Was ich noch wissen wollte ist, dass Programm auf den Bot mit dem du die "SRF02" ansprichst in "C" oder in "Bascom" geschrieben ?
Denn ich finde keine beispiele für C.

PS: Für die Uhrzeit könnt ihr die Fehler behalten. ;)

MFG Oliver G

Danke dir!
Ich arbeite momentan auch noch mit Netzgeräten, daher ists mir momentan noch egal.
Aber wenn ich auf Akkus umrüste, werd ich das mal angehen.

Zum SRF02:
Ich geb dir mal die beiden Libs, die ich dafür da hab.
Eine für die M32 (.c) und eine für die M128 (.cc)

Grüße