Menü
Aktuelles
Von:
Filter

Brauche Hilfe bei mapCRC Berechnung (CaSSAndRA)

EinEinfach

EinEinfach

Well-known member
Hallo zusammen,

ich würde gerne die hochgeladene Karte aus CaSSAndRA heraus abgleichen bevor der Mähvorgang gestartet werden soll. Hierzu wollte ich das mapCRC in CaSSAndRA nachrechnen lassen und mit dem mapCRC was die SunrayFW meldet abgleichen, bei der Übereinstimmung soll dann CaSSAndRA erst den GO an den Mäher senden.

Ich komme mit der Sunray FW mapCRC nicht weiter, wenn ich den Code richtig interprätiere, dann läuft die Berechnung relativ einfach:
Perimeter Punkte in cm + Exclusion Punkte in cm + Mähwege in cm + Dockpoints in cm = mapCRC. Wenn ich das in CaSSAndRA nachrechne komme ich nicht auf das Ergebnis. Was übersehe ich?

Hier ein Beispiel was die Sunray FW an mapCRC schickt und was ich in CaSSAndRA hierzu berechne:
Sunray FW:
# 16:20:32.168 -> perimeterCRC: -126266
# 16:20:32.168 -> exclusionsCRC: -141459
# 16:20:32.168 -> dockPointsCRC: -7314
# 16:20:32.168 -> mowPointsCRC: -23340
# 16:20:32.168 -> map dump - mapCRC=-298379
CaSSAndRA:
# 16:20:32.168 -> perimeterCRC: -126276.0
# 16:20:32.168 -> exclusionsCRC: -141458.0
# 16:20:32.168 -> dockPointsCRC: -7314.0
# 16:20:32.168 -> mowPointsCRC: -23344.0
# 16:20:32.168 -> map dump - mapCRC=-298392.0

Grüße
Alexander
 
Hallo,

ich schätze das sind Rundungsfehler die durch unterschiedliche Datentypen bzw. Umwandlung entstehen (die Firmware arbeitet ja bei Punkten mit Umwandlung von Fliesskomma in Festkomma und wieder zurück so dass weniger RAM beansprucht wird...)

Ich würde das mit einer Toleranz lösen (so wie in der Sunray App):
var diff = app.map.crc - stateCRC;
app.map.showNotSyncWarning = (Math.abs(diff) > 200);

Gruss,
Alexander
 
Zuletzt bearbeitet:
AlexanderG schrieb:
ich schätze das sind Rundungsfehler die durch unterschiedliche Datentypen bzw. Umwandlung entstehen (die Firmware arbeitet ja bei Punkten mit Umwandlung von Fliesskomma in Festkomma und wieder zurück so dass weniger RAM beansprucht wird...)
Zum Vergrößern anklicken....
Danke für die Erklärung. Ich habe mir bzgl. Map-CRC auch schon die Zähne ausgebissen. Was hältst du von folgendem Verbesserungsvorschlag?
Map-CRC wird bei der Berechnung der Karte von der App bestimmt und als Teil des Karten-Datensatzes mit abgespeichert und an den Mäher übertragen. Dann braucht der Mäher die CRC gar nicht selbst berechnen, sondern nur die erhaltene und im Mäher abgespeicherte CRC rückmelden. Abweichungen gibt es dann auch nicht mehr.
 
Am Übertragungsprotokoll sollte man m.E. so wenig wie möglich ändern weil dann vorhandene Software und Firmware nicht mehr läuft. Es sind inzwischen 49 Varianten der Firmware im Umlauf (bzw. Forks) und ein Dutzend verschiedene Apps dafür (einige nur Closed-Source entwickelt etc.)... Einfach so mal das Protokoll ändern geht nicht mehr denke ich. Erweitern ginge natürlich. Die Toleranz oben ist erstmal ausreichend bis zum nächsten größeren Protokoll-Wechsel denke ich (womit dann alle Software inkompatibel wird).
 
Zuletzt bearbeitet:
Das wäre aus meiner Sicht kein Problem. Wenn Map-CRC von welcher App auch immer gesendet wird, dann wird diese vom Mäher gespeichert. Wenn nicht, dann wird sie vom Mäher berechnet und gespeichert. Dann bleibt das ganze Rückwärtskompatibel.
 
Und wenn man verschiedene Software (Apps, Automatisierung etc.) gleichzeitig bzw. im Wechsel einsetzt welche leicht unterschiedliche Datentypen verwenden (double, float, ...) und zu leicht unterschiedlichen Berechnungen kommen - dann sagt mal die eine oder andere Software "nicht synchronisiert". Um die Toleranz wird man nicht herumkommen...Oder man findet eine elegantere CRC-Berechnungsmethode wo keine Toleranzen entstehen...
 
Zuletzt bearbeitet:
AlexanderG schrieb:
Oder man findet eine elegantere CRC-Berechnungsmethode wo keine Toleranzen entstehen...
Zum Vergrößern anklicken....
das war ja genau mein Vorschlag. Der CRC wird einmalig berechnet, von wem und mit welcher Toleranz auch immer und zum Datensatz hinzugefügt und danach nicht mehr hinterfragt oder gegengerechnet. Das ist dann quasi der Name des Datensatzes, den man nur noch vergleichen braucht. Ist der Name, den der Mäher mit dem Datensatz bekommen hat und regelmäßig sendet gleich dem Datensatznamen (CRC) , der der geladenen Map beigefügt ist, dann ist alles prima. Wenn nicht wird eine Wahrnung ausgegeben. Alte APPs behalten ihre Toleranz, das macht ja nichts. Und wenn eine alte App keinen Namen sendet, dann wird auf dem Mäher die CRC halt wieder berechnet. Das ist aber nur ein Übergangsthema.
 
Ich meinte eigentl. eher wenn man wie einige verschiedene Software (MQTT, Apps) verwendet welche in Zukunft dann ihre CRC senden, denkt mal die eine oder andere App "nicht synchronisiert" obwohl es identische Karten sind... das muss doch alles irgendwie eleganter gehen...(eine identisch Berechnungsmethode für alle Apps). Der Roboter teilt einem ja die berechnete CRC für eine übertragene Karte mit, die kann sich eine App ja speichern bei seinen eigenen Karten und so eine Zuordnung herstellen (appMapCRC, robotMapCRC) und wenn sich eine der beiden CRC ändert ist auf einer Seite (Roboter/App) eine andere Karte vorhanden ...
 
Zuletzt bearbeitet:
...eine CRC ist doch dafür da, um zu prüfen, ob eine Übertragung komplett korrekt ist.
Also muss man doch in System A eine Checksumme berechnen, und diese in System B auch nachrechnen und dann vergleichen. Es muss also zwongend in beiden Systemen gerechnet werden!?
 
Warum? Wenn das gesendete zurück gesendet wird, dann muss die Übertragung doch komplett gewesen sein. Voraussetzung ist natürlich, dass man davon ausgeht, dass System A richtig rechnet. Bin nicht sicher ob das ausreicht. Aber das ist die Idee von @Silberstreifen.
 
In diesem Fall dient die CRC eher nur zur Erkennung einer Karte. Der Übertragungsweg wird mit getrennten CRCs gesichert (pro Nachricht). Der Roboter liefert die CRC für eine übertragene Karte und diese könnte die App sich speichern um zukünftig zu überprüfen ob diese Karte/dieser Upload bereits erfolgt ist...
 
Wir bennen es einfach um in UUID ;-) - Bitte berücksichtigen dass wir auch noch das Bluetooth BLE Protokoll haben, d.h. alles wurde dafür ausgelegt in wenigen Bytes ausgetauscht zu werden (32 Bytes pro Nachricht). Eine Zahl ist kurz, diese gängigen 32 Zeichen UUIDs sind zu lang...
 
Ich hatte das so verstanden das BLE nur für die ersteinrichtung nicht für den Dauerbetrieb gedacht ist. Mein Vorschalg ist auch mehr als Ergänzung zu sehen, da dort keine Toleranzen durch Berechnungen benötigt werden.
 
AlexanderG schrieb:
Ok, ich hab eine Compiler-Option in config.h eingebaut (#define LINUX_BLE) welche man auskommentieren kann um BLE unter Linux zu deaktivieren...
Zum Vergrößern anklicken....
Hi Alexander .
Not the good tread ,but i don't know where to post this ?

Into map.h The class point , you have define the px and py as short (certainly to limit memory allocation size)
Code: 
// a point on the map
class Point
{
  public:
    short px; // cm
    short py; // cm       
    Point();

And when we upload a map into the AGCM4 the conversion from float to short generate sometime a rounding error (1 point each 300 or 400) is changed:
Sunray app send x=15.84 and AGCM4 receive 15.84 but change and save the value to 15.85 .
It's only 1 cm error ,but the result is a difference between the 2 MAP CRC (the one compute by raspberry Pi and the AGCM4 one)

Changing definition to float can help to solve this in my case and can secure the transmission of the map.
Code: 
// a point on the map
class Point
{
  public:
    float px; // cm
    float py; // cm       
    Point();
    Point(float ax, float ay); // meter
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben