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

[fabqu]

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

[SlyD]

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

[fabqu]

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:

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

[o.g.1985]

Hi,

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

[SlyD]

> 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

[fabqu]

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! )

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!

[SlyD]

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

[SlyD]

Hab das mal kurz angeschaut.


Also im Slave (RP6Base) kannste erstmal das hier:

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

[fabqu]

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!

[fabqu]

Juhuuu!
Habe noch mal die TimeBetweenFrames runter auf 180 und es funzt einfach alles
Die Daten kommen mit nicht mal 1 Sek Verzögerung
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...


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