Menü
Aktuelles
Von:
Filter

GPS jumps to invalid when starting to mow

Hartmut schrieb:
1. The Ublox is operated with 2.7 to 3.6 volts. But my board only delivers 3.1 volts at the GPS connector. That means that everything ages, the capacitors and the voltage regulators too. The same goes for the contacts. So my Vref is not 3.3V. If you increase Vref to 3.35V because of the voltage display, then only interference can be transmitted. So let the motors run and measure the supply voltage on the GPS and the reference voltage on the GPS. Then set your Vref in Config.h and test.

I decided to solder an ELKO of 68V and 100 μF directly to the F9P power connection . You can use an Ozi to measure whether there is any interference on the power line and then solder another 5 nF in parallel.

2. Yesterday I tested the Sunary https://github.com/ShadedSelf/Sunray-CE/tree/main/sunray . The version shows exactly the same behavior, Mow on Fix gone , etc. Then I downloaded the new 318 and the problem with the missing fix was gone.

However, I keep getting GPS Invalid for a short time and then a fix immediately. I'm 99% sure it's a software problem because I use two rovers and it happens to both of them more or less often. It's either a timer problem or an interrupt or Vref, etc.

3. To test, take a very old version and check whether this disappearing FIX has disappeared. Or try increasing the clock speed of the M4 to see if it improves, especially the BUS.
Zum Vergrößern anklicken....
Hi Harmut,

Would you be able to provide any pictures/diagrams on how you implemented this? I’ve had this problem for some time now.
 
Ich habe keine Bilder gemacht. Der Kondensator sitzt direkt an der Stromversorgung des GPS von unten angelötet.
Die GPSstörungen kommen von Sunary, die eventuell mit 2 delay dem Prozessor anhalten. Sunary unterbricht den RX TX Datenstrom. Dann kommt Invalied.
Abhilfe schaft, den Prozessor auf die erste Übertaktungsstufe zu setzen und den Bustakt auf den halben Prozessortakt. Dann fährt er 1h.
Das stellts du in der Arduino ID ein.
Das wahre Problem kann nur Alexander finden.
 
How do you implement this in the arduino? I’d like to try the capacitor and modifying the code. Are you able to provide any information around how you changed things?
 
I think the issue is software bug and certainly not power supply.


Can someone try to reproduce by this way:


You need one area with a path to station and station not locate inside the mowing area:
If you put the mower outside of mowing area and near path to station.
Read this log from bottom to top
10:03:34 GPS jump: 7.60
10:03:31 rebooting GPS receiver...
10:03:31 ==> changeOp:GpsRebootRecovery(initiatedByOperator 0)->Dock
10:03:31 ERROR: no path
10:03:31 pathfinder: no path
10:03:31 .finish nodes=101 duration=2
10:03:31 starting path-finder
Zum Vergrößern anklicken....
When you click on home : path-finder can't find a path and reboot GPS ,so the invalid appear , but rebooting is fast and again it's float and fix.

The same issue can appear on start if the station location recording dot don't match perfectly with the real location of mower (when mower is into dock the firmware adjust is location).
 
FIX_MOW_INVALID_FIX_Problem gefunden M4
Das Problem wird von den neueren SAM Bordtreibern verursacht. Zu sehen an Warnmeldungen und Compelierungsfehlern in der Arduino IDE.
Mit den Boardversionen Arduino SAM 1.6.7 und Adafruit SAM 1.7.5 läuft alle wie gewohnt.
1720086379533.png
Ob noch andere Versionen höher funktionieren habe ich nicht weiter probiert. Fall Ihr noch eine funktionierende höhere Versionskombination findet, dann bitte hier mal Posten.
 
Hartmut schrieb:
FIX_MOW_INVALID_FIX_Problem gefunden M4
Das Problem wird von den neueren SAM Bordtreibern verursacht. Zu sehen an Warnmeldungen und Compelierungsfehlern in der Arduino IDE.
Mit den Boardversionen Arduino SAM 1.6.7 und Adafruit SAM 1.7.5 läuft alle wie gewohnt.
Anhang anzeigen 7501
Ob noch andere Versionen höher funktionieren habe ich nicht weiter probiert. Fall Ihr noch eine funktionierende höhere Versionskombination findet, dann bitte hier mal Posten.
Zum Vergrößern anklicken....
Not sure ,because i have the same issue on Teensy.
Here the location of issue in the code

Take a look into robot.cpp
In the main loop : gps.run(); is call on each loop ,so at high frequancy
And into gps.run (at the end of ublox.cpp UBLOX::run)
You can see that if the code don't go to this part for less than 1 second a solutionTimeout is trigger and solution = SOL_INVALID;

So a lot of thing can generate a new INVALID (all part of code locate in the robot main loop that take a total of more than 1 seconds),I2C/SDcard etc....

In my case i can reproduce the issue each time path-finder take too long time to compute a path , for example if i start mowing from outside of a mowing area.

Code: 
void UBLOX::run()
{
    if (millis() > solutionTimeout){
    //CONSOLE.println("UBLOX::solutionTimeout");
    solution = SOL_INVALID;
    solutionTimeout = millis() + 1000;
    solutionAvail = true;
  }

    // read a byte from the serial port     
  if (!_bus->available()) return;
  while (_bus->available()) {       
    byte data = _bus->read();       
        parse(data);
#ifdef GPS_DUMP
    if (data == 0xB5) CONSOLE.println("\n");
    CONSOLE.print(data, HEX);
    CONSOLE.print(",");   
#endif
 
Nice finding. Just make a config.h define for the 1000ms constant. On a large map, pathfinder may trigger this invalid Everytime there is an obstacle →mow off → mow on... You don't even see this short invalid in the app
 
On the other hand... If we want to get rid of constants and defines, we could maybe add the cycle time to the condition to step in: if (millis() > solutionTimeout + cycle time) ....
But I don't know, if the cycle time would get updatet before. So basically, it would be necessary to not calculate the cycle time at the start of code, but at the end of everything. Sunray algo starts: make a millis() save.. sunray went trough: make a nother millis() record an calc the delta and write it to the cycle time.alsi, the ublox routine needs to be one of the first things to schedule in code
 
Für diesen Fall habe ich bei mir eine keepAlive-Funktion in der robot.cpp eingefügt. Mit der Funktion werden alle Zykluszeit-relevanten Umfänge wie IMU oder GPS aufgerufen. Der Pathfinder ruft die keepAlive-Funktion dann in jeder 10ten Iterationsschleife auf. Damit ist der Spuk dann vorbei.
 
I have fork your version and try to add the feature need to work on Robomow,so i can test the mow speed adjustment , but need work to add INA226 / BTS7960 clean support. I also need many var that i can adjust OTA to setup correctly each part.

For the issue invalid.

To debug :
you need to check the duration of each individual part in the code and add a flag in console when it's append.
Here example into azuritber to check the pfod serial read process :
Code: 
//for debug only
unsigned long StartReadAt;
unsigned long EndReadAt;
unsigned long ReadDuration;

Code: 
  StartReadAt = millis();
  rc.readSerial();// readserial function into pfod.cpp
  EndReadAt = millis();
  ReadDuration = EndReadAt - StartReadAt;
  if ( ReadDuration > 200) {
    ShowMessage("Warning Serial read duration > 200 ms : ");
    ShowMessageln(ReadDuration);
  }
 
Cant we just delete that code altogether?
It sets the solution to invalid if the loop time of the firmware is > 1 second. Why? Is that useful in some way?
 
Actually, you can just rearrange the code to read the new data before checking and that might fix it:

Code: 
  // read a byte from the serial port  
  while (_bus->available()) {    
    byte data = _bus->read();    
    parse(data);

#ifdef GPS_DUMP
    if (data == 0xB5) CONSOLE.println("\n");
    CONSOLE.print(data, HEX);
    CONSOLE.print(",");   
#endif
  }
     
  // make sure data is fresh
  if (millis() > solutionTimeout){
    //CONSOLE.println("UBLOX::solutionTimeout");
    solution = SOL_INVALID;
    solutionTimeout = millis() + 1000;
    solutionAvail = true;
  }
 
Zuletzt bearbeitet:
WhatATest schrieb:
Actually, you can just rearrange the code to read the new data before checking and that might fix it:

Code: 
  // read a byte from the serial port
  while (_bus->available()) {  
    byte data = _bus->read();  
    parse(data);

#ifdef GPS_DUMP
    if (data == 0xB5) CONSOLE.println("\n");
    CONSOLE.print(data, HEX);
    CONSOLE.print(","); 
#endif
  }
   
  // make sure data is fresh
  if (millis() > solutionTimeout){
    //CONSOLE.println("UBLOX::solutionTimeout");
    solution = SOL_INVALID;
    solutionTimeout = millis() + 1000;
    solutionAvail = true;
  }
Zum Vergrößern anklicken....
Why not i test this solution: solutiontimeout is also reset inside // UBX-NAV-RELPOSNED.

In all case i don't really understand this feature and why only in the GPS part. ????
If GPS freeze ,normaly watchdog stop the robot, else there is a solution in the ublox message ????

Unfortunatly don't solve the gps invalid when start at bad location.
 
Zuletzt bearbeitet:
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben