Menü
Aktuelles
Von:
Filter

Starke Spurabweichung (Drift) nach längerer Einschaltzeit

If we maybe have found a workaround can you please post exactly what I have to edit in which file.... I can't follow you guys. 😁
 
Thanks!

Okay would explain why the problem started randomly at 08/2022... in sunray 1.0.230 it wasn't in the code.
But when I read "(experimental, comment out to disable)" and see this enabled by default over multiple version... makes the software completly unusable over time... reported in the forum in multiple threads over and over.... how... I better don't ask... :censored:

But if this works, nice you guys have found the problem!

Maybe someone can reach out Alexander so he can take a closer look at that function and fix/remove it in future releases?
 
I think this can also help for the Alfred, because I have seen this the drift Problem more on the Alfred mower.
 
Just for info , on AGCM4 :
After 88 hours of mowing and station charging everything is OK (no drift or strange speed on restart from station)
I use the simple odometry code with asm("dsb"), and only rising interrupt
Code: 
void OdometryLeftISR(){             
  odomTicksLeft++; 
  asm("dsb");     
}

void OdometryRightISR(){           
  odomTicksRight++;
  asm("dsb");       
 
  #ifdef TEST_PIN_ODOMETRY
    testValue = !testValue;
    digitalWrite(pinKeyArea2, testValue); 
  #endif
}
 
Today, I had 2 watchdog resets on AGCM4, and I think, the reason is the rising interupt. Now I'm back on changing interupt. Tomorrow I will test, if stability without watchdog reset is back again.
 
I'm using ALFRED with the standard Software/Formware and posted in this thread already that I had observed this "drift" behavior, too. I have no intention to modify any code myself (that's why I bought ALFRED and not ARDUMOWER). However, this discussion and your obvious detection of "super_spike_elemimator" as root cause of the "drift" problem triggered various questions on my side:
  1. What is the "super_spike_elemimator" for, why was it put into code and with which release?
  2. Why does it cause the "drift" behavior when it's active?
  3. Is there a possibility to eliminate this bug for ALFRED or do I have to wait for an afficial new Sotware release?
Perhaps anyone of you experts could kindly answer my questions and shed some light for my simple mind on this topic (posts in German are of course OK).
Thanks very much in advance.
 
1 It is normaly used to avoid noise on the high frequency input on the odometry signal, but in this case it fail to work after long duration , certainly cause by the use of millis() inside an interrupt routine .
2 The odometry is used to compute the speed of the wheel , and for dock and undock , so error in odometry generate a bad control on the speed , stanley control generate the drift, also some docking issue and localisation under particular condition (sunray can detect a false slipping wheel).
3 For alfred the odometry come from the mower main board using SerialRobot and i did not have the code to give you the answer
 
Can confirm that the workaround with disable the spike function works!
Mowing the third day in a row without a reboot and still no drunken robot mode! :)

Hard to tell but I would say the robot lost a very little bit of precision to drive a straight line without this function.
Still okay but I feel it was better before, but no big deal.
 
First, @bernard thank you for the explanation. Made things a bit clearer for me.
However, I don't understand why this spike function was - obviously in some of the later releases - implemented at all. Any idea?

I may be wrong, but I thought that my Alfred followed the calculated paths more or less fine (regardless of the random, a few seconds lasting movement interrupts with beeps on the lawn). At least he found always his way into the docking station.
Now a few minutes ago, it just occured again (as described by me in my first post within this thread): Alfred couldn't dock! In various attempts he moved against the garage which triggered the bumper. He retreated and made several new approaches with same unsuccessful results until I sent a "stop" signal via Sunray.
Then I "rebooted" Alfred, "connected" again, and sent the "dock" signal (all via Sunray on my Windows PC). His docking was then immediately successful with no problems at all.

My analysis of this strange behavior: there is a counter or stack or buffer or something similar which "overruns" after a long online-time and which is reset (beside others, of course) by the "reboot". If this is the case, resetting just this counter each time the mower is charging should solve this problem, because time interval between 2 charging sessions is only 2 - 4 hours (depending on battery capacity, gras height and other environment / power consumption conditions).
Am I wrong?
 
I don't have Alfred robot ,so it's not possible for me to help in this case,
But if you want to be sure that it's odometry issue you need to send the AT+E command to force mower doing the 10 rev test after 1 min start and after 10 hours.
If you don't have the same exact 10 rev , there is something wrong in the odometry.

And i can't tell you how to do the 10 rev test with Alfred or send AT command to it.
 
Vielleicht sollten wir etwas differenzieren, wer z.B. mit Original Arudumower Brushless, oder Brushed Motoren unterwegs ist. Oder wer ganz andere Hardware benutzt. Lt. Alexander wurde die Zeile: #define SUPER_SPIKE_ELIMINATOR 1 das ist ein filter welcher odometrie-spikes für brushless-motortreiber von marotronics herausfiltert. Für die Brushed Motoren hat es wohl keine Funktion.
 
Wenn es natürlich bei dir eine Auswirkung hat, dann sollte das überprüft werden. Beim Alfred wird der AmRobotDriver.cpp nicht benutzt.
 
W1976 schrieb:
Wenn es natürlich bei dir eine Auswirkung hat, dann sollte das überprüft werden. Beim Alfred wird der AmRobotDriver.cpp nicht benutzt.
Zum Vergrößern anklicken....
Ich verstehe deine Ausführungen nicht, das Problem besteht seit über einem Jahr, du warst, wenn ich mich nicht täusche, auch von betroffen. Jetzt gibt es eine Lösung und mehrere Leute haben es erfolgreich getestet. Wie lange soll man vor dem Thema noch die Augen verschließen? Schnellsten umsetzen und das Thema ist vom Tisch, es müssen sich nicht noch mehr Leute damit abärgern!
 
EinEifnach, ich habe das Problem glaube bis jetzt nur am Alfred gesehen, beim Ardumower bin ich mir aktuell nicht sicher ob ich es schon mal gesehen habe. Mal sehen vielleicht kann ich es bald mal nachvollziehen.

Ab welcher Version trat das Problem genau auf?
 
W1976 schrieb:
EinEifnach, ich habe das Problem glaube bis jetzt nur am Alfred gesehen, beim Ardumower bin ich mir aktuell nicht sicher ob ich es schon mal gesehen habe. Mal sehen vielleicht kann ich es bald mal nachvollziehen.

Ab welcher Version trat das Problem genau auf?
Zum Vergrößern anklicken....
The issue is certainly only present when millis() have a very high value and on AGCM4 or teensy because certainly millis() timer have different management than the DUE one,
So people without charging station or resetting frequently mower never see this issue.

On alfred it's diffrent , i suppose the Odometry is manage by the main PCB of the platform, and we don't have the code .Or a simple Serial comm issue can do the same drift if Sunray don't receive the odo value in time.

To understand more ,take a look at:
arduino.stackexchange.com

Using millis() and micros() inside an interrupt routine

The documentation for attachInterrupt() says: ... millis() relies on interrupts to count, so it will never increment inside an ISR. Since delay() requires interrupts to work, it will not work if
arduino.stackexchange.com arduino.stackexchange.com

So it's more stable to change the code of interrupt routine odometry and remove the call of millis() ;)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben