Wheelie - Bus

[hoernchen]

Hier sollte das im Motorprüstand angefange Thema weitergeführt werden:

Danke für die Info.
Die regelmäßigen Kommunikationen sind dann:
1. Master aktiviert ESP (sagen wir mal 20µs)
2. ESP liefert 2 Achsen Acc + Gyro (1 Achse ist subobtimal, 3 wären am besten) je 2 Byte pro Sensor und Achse = 8 B (130µs)
3. Master rechnet (Zeit wie sie benötigt wird))
4. Master steuert beide Motortreiber je 2 Byte = 4 B (130µs)

Ohne Protokolloverhead und ohne Quittung 280µs + Berechnungszeit.
Mit Protokoll und Quittungsdaten dürfte es mehr sein, oder sehe ich da was falsch?

Hallo Thomas Scherer,

das kommt prinzipiell hin.

Gehen wir von 500kbit/s Übertragungsgeschwindigkeit aus, dann dauert 1bit 2µs.
Die max. 500kbit/s sind vom ESP-Cluster vorgegeben.
Eine komplette CAN-Nachricht mit 8byte dauert dann inkl. Intermissionzeit ( 3bit) 131bit * 2µs = 262µs.

Ohne fehlerhafte Nachrichten dauert es insgesamt sogar länger:
zu 1: Synchronisationsnachricht an das Cluster ( 8bytes = 262µs)
zu 2: Sensorwerte ( 1 Achse mit 8byte = 262µs)
zu 3: wie gehabt
zu 4: Sollwerte an Motorregler ( 2x 2byte = 160 + 160µs)

Ohne die Verzögerung im Motorregler und Rechenzeit des Masters sind es doch sogar 844µs...
Die Quittungsdaten sind nicht unbedingt notwendig, da die CAN-Nachricht entweder gültig ist, oder nochmal angefordert wird.

Grüße

hoernchen

[solarxt]

Wheelie-Bus bidirektional

[thomas scherer]

Wer ist da das Masterle und wer spielt den Salve?

@hörnchen:
Das hieße, wenn bei 100Hz Regeltakt noch Kommunikation mit einem Display-artigen Teil dazu kommt, dass dann etwas über 1ms von 10ms für Kommunikation verbraucht werden, stimmt das so?
Und die Latenz von der Größenänderung der Sensoren bis zum Motorkommando dürfte dann Pi x Daumen so um die 4..5ms betragen.
Wäre 1Mbaud keine Alternative?

[hoernchen]

Hallo Thomas

@hörnchen:
Das hieße, wenn bei 100Hz Regeltakt noch Kommunikation mit einem Display-artigen Teil dazu kommt, dass dann etwas über 1ms von 10ms für Kommunikation verbraucht werden, stimmt das so?

Exakt. Zu dem Wert von ~ 850µs kommt die die Nachrichtenlänge für das Display dazu, ohne noch die Wertermittlung im Master zu berücksichtigen. =1ms
Ist eine Regelung bei 100Hz noch effektiv?
Ich denke da an die maximal Eigenfrequenz des Systems.

Und die Latenz von der Größenänderung der Sensoren bis zum Motorkommando dürfte dann Pi x Daumen so um die 4..5ms betragen.
Wäre 1Mbaud keine Alternative?

Ja, 1Mbit/s sind auf jeden Fall eine Alternative.
Leider lässt mein ESP-Cluster keine zuverlässigen Synchronisationen/Messwertanfragen unter 20ms zu und kommuniziert ausschließlich auf 500kbit/s.

Im Moment ist die Latenz durch den internen ADU und die PWM (weit?) unterhalb der 844µs...wieviel habe ich gerade nicht zur Hand .

[thomas scherer]

Ich würde auch sagen, dass eine Regelfrequenz nach Eigentakt besser ist, da man dann keine unnütze Zeit hat. Außerden steigert ein höherer Takt ja virtuell die Auflösung der PWM (1 bit = verdoppelter Takt).

Bez. CAN-Bus, wenn der das nicht kann, wäre es dann nicht sinnvoller, das CAN wegzulassen und auf einen simpleren RS485-Bus zu setzen, denn da kann man ja locker auf 2Mbit/s gehen.

[hoernchen]

Außerden steigert ein höherer Takt ja virtuell die Auflösung der PWM (1 bit = verdoppelter Takt).

Das verstehe ich nicht ganz. Meinst du die Richtung...8bit...9, oder 10bit PWM?

Bez. CAN-Bus, wenn der das nicht kann, wäre es dann nicht sinnvoller, das CAN wegzulassen und auf einen simpleren RS485-Bus zu setzen, denn da kann man ja locker auf 2Mbit/s gehen.

Ich denke ich muss bezogen auf mein Wheelie ein wenig ausholen.
Am Anfang stand bei mir der Sensor, ich wollte einen fertigen, erprobten Sensor für die Lage/-änderung benutzen. Themen wie Referenzspannung, EMV, Bias, Haltbarkeit, Platinenadapterdesign etc. wollte ich mir ersparen.
..."automotive" ist das Stichwort gewesen. Die ESP-Cluster gibt es als analoge, als auch in CAN Version, fix und fertig, von einem namenhaften Hersteller.
Den analogen Bruder wollte ich nicht, um u.a. die Probleme mit nachgeschalteten ADUs zu vermeiden..also CAN..somit die festen 500kbits/s...
Die Entscheidung die Motorregler "intelligent" und CAN-fähig zu machen lag nahe, da sich mit 1 Master & 1 Slave ein CAN-Bus nicht wirklich lohnt. Deshalb wird bei mir wird die PWM für die Motoren vom kaskaden Regler auf der Motorreglerplatine und nicht direkt vom Master erzeugt.

Als Alternative einen ähnlich robusten und sogar schnelleren Bus hierfür zu verwenden ist definitiv von Vorteil, wenn es die Hardware/Sensoren/Debugtools etc. schon gibt, oder man diese schnell und günstig aufbauen kann. CAN kann teuer werden...

[kritias]

Hallo hoernchen,

Du schreibst:

Leider lässt mein ESP-Cluster keine zuverlässigen Synchronisationen/Messwertanfragen unter 20ms zu und kommuniziert ausschließlich auf 500kbit/s.

Bist du dir da sicher, daß 50Hz ausreichen? Ich habe die Erfahrung gemacht, daß vor allem die Qualität des Filters mit der Frequenz steigt.

[thomas scherer]

Das verstehe ich nicht ganz. Meinst du die Richtung...8bit...9, oder 10bit PWM?

Genau. Ganz im Sinne von Oversampling.
Bei einem trägen System, bei dem die Abtast bzw. Steuerungsfrequenz hoch genug ist (und 100Hz wären das bei einem Wheelie), wirkt sich die Verdoppelung der Steuerfrequenz z.B. auf 200Hz in etwa so aus, wie ein zusätzliches Bit der PWM. Statt 8 bit bei 100Hz wären das dann bei 200Hz äqivalent 9bit etc. pp.

Deine Überlegung kann ich nachvollziehen. Allein hat der Startpunkt mit seinen Vorteilen dann aber auch deutliche Nachteile - nicht nur bei den Kosten - als Folge. Wenn Du nicht schon viel investiert hast, würde ich mir das noch einmal überlegen, ob eine simplere Technik nicht deutlich flexibler und zudem leistungsfähiger wäre. Es gibt ja neben analogen Sensoren auch welche mit digitalen Ausgängen. Da ein Controller dran und ein RS485-Chip und schon hast Du ein universales Sensormodul, das sehr schnell und sehr stabil ist und in ein schnelles Bus-System passt.
Aber wenn Du schon viele Teile gekauft hast, macht das keinen Sinn mehr.

[hoernchen]

@Kritias: Ehrlich gesagt noch nicht...ich kann aber bei dem Seriensensor davon ausgehen, dass Ausreißer im Beschleunigungsmessteil wesentlich geringer ausfallen womit der Filter dann aggressiver ausfallen kann. Wenn ich es richtig erinnere, ist dieses "Sensorproblem" leider sehr dominant in der aktuellen Version. Die agressivere Filtereigenschaft ist leider nur eine noch nicht bestätigte Vermutung, da ich noch nicht so weit mit dem Gesamtkunstwerk bin.

Genau. Ganz im Sinne von Oversampling.
Bei einem trägen System, bei dem die Abtast- bzw. Steuerungsfrequenz hoch genug ist (und 100Hz wären das bei einem Wheelie), wirkt sich die Verdoppelung der Steuerfrequenz z.B. auf 200Hz in etwa so aus, wie ein zusätzliches Bit der PWM. Statt 8 bit bei 100Hz wären das dann bei 200Hz äqivalent 9bit etc. pp.

So passt es für mein Verständnis.
Wenn ich es nicht durcheinander bringe, ist die Ansteuerung der Endstufen im Moment 8bit bei 100Hz. {WOF200} Das funktioniert doch Schienbeinschonend. Die jetzige "Standardhardware/-konfig" mit dem MEGA32 ist PWM-technisch am Limit (direkter Systemtakt an TCNT). Somit wäre ein Oversampling garnicht drin, oder nur mit Halbierung des "timer0-Wertes"?

Deine Überlegung kann ich nachvollziehen. Allein hat der Startpunkt mit seinen Vorteilen dann aber auch deutliche Nachteile - nicht nur bei den Kosten - als Folge. [..] Es gibt ja neben analogen Sensoren auch welche mit digitalen Ausgängen. Da ein Controller dran und ein RS485-Chip und schon hast Du ein universales Sensormodul, das sehr schnell und sehr stabil ist und in ein schnelles Bus-System passt.

Das hast du vollkommen Recht. Teilweise ist die Hardware nicht unbedingt im Standardrepertoire eines Elektronikers. Für ein einfaches debugging und simulieren von Master und Slaves reicht aber auch ein USB2CAN Adapter + Software. Die Idee mit dem RS485er Bus finde ich interessant, jedoch fällt u.a. dann die Möglichkeit weg, das System später einzeln per CAN-Bus & Booter zu updaten.
Mich würde interessieren, was "noch" gegen einen CAN-Bus spricht. Ich hoffe ja, dass ich bei meiner Planung nichts Wesentliches übersehen habe.

[thomas scherer]

Wenn die PWM_frequenz bei > 20kHz liegt ist sie massiv höher als die Ansteuerfrequenz von 100Hz. Da ist also noch durchaus Luft für Oversampling drin. Damit kriegt man dann 9 bit oder gar 10 bit Auflösung, ohne dass die PWM die bei dem Tempo möglichen 8bit verlässt.

Die Firmware kann man bei AVRs auch seriell updaten (per Bootloader). Ich habe das mit XMEGAs schon über RS485 gemacht. Funktioniert.