-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Driving Timeout #126
Comments
At what distances does the error occure? Only small ones (< 1-2 cm)? Because that is the accuracy of our RTK... |
It occurred immediately after starting the automation, when the roboter tried to drive the first time, then the automation stopped. |
We tried to change the deadline from additional 2 to 5 (line 84 in navigation.py) deadline = rosys.time() + 5 This seemed to work, but we then set the value back to 2 and the robot again seemed to drive as it should. The error still occured but I logged the error instead of raising it to keep the automation running. So, no big insights as it seems. |
@rodja I saved some logs for this and the distances are indeed in the millimeter range.
for example Point(110.250, 88.245) to Point(110.256, 88.259) |
I hope that #130 will fix this issue. It only performs GNSS updates between when standing still. That means that we drive 100 % by odometry data. |
We figured out that the Driving Timeout occurs when the odometry heading is above 180 deg or under -180 deg. |
This should be fixed with #130. I guess it is already tested on real robots today. Can we close this @LukasBaecker? |
@rodja I would like to add a test for this case to make sure that the robot acts as expected when the heading is >180 or <-180. |
When running a weeding automation the robot sometimes stops and the navigation raises a 'Driving Timeout' error.
I got a log for this but sadly it misses the current position and yaw, but U5 had this problem yesterday and we can try to reproduce it this afternoon.
The text was updated successfully, but these errors were encountered: