Inaccurate Waypoint logging with toggle switch

Hi

I have an issue logging waypoints with the CH7 Toggle switch.

I am currently attempting to get the rover to follow a pre-recorded path.

The rows are 50 m long and about 1.5 m apart.

I have an EMLID Reach RS GPS (Set to GPS2 - GPS1 is disabled) and was able to attain RTK Fix during my run.

In manual mode, I recorded the GPS path via a ROS module that is monitoring the
global_position/global msgs (http://wiki.ros.org/mavros#mavros.2BAC8-Plugins.global_position). The path recorded is shown in blue in the image below.

While recording this run I also manually toggled the CH7 switch to record waypoints in ardurover (See yellow line).
The recorded waypoints done by ardurover looked very squiggly. It was not at all like the smooth path logged by my ROS module.

Of course when I tried to run in auto mode with the yellow recorded waypoints, my robot is swinging all over the place.

Waypoint file here : https://cloudstor.aarnet.edu.au/plus/s/vWRU1ardHZUvELz

Log file here (Large file - 200MB ) - https://cloudstor.aarnet.edu.au/plus/s/ElR7CfNWadRolrs
The path was recorded early in the log …there rest were my attempts at doing other things.

Hi Esa,

I think the accuracy issue is very likely related to the waypoint being stored or downloaded as 32bit floats instead of 32bit integers. If floats are used then the position can be off by up to 1m or so (it depends upon where you are in the world). I’ve done a quick review of the rover code and as far as I can tell it is internally using integers.

I suspect that QGC is downloading the waypoints as floats instead of using integers for some reason. ArduPilot supports providing the waypoints in floats (the old method) or integers (the new method) but it depends upon what the GCS asks for… or there could be a bug in ArduPilot of course.

To confirm that Rover is storing them internally correctly, you could use the mission planner to download the waypoints from the flight controller. Alternatively you could arm the vehicle, disarm and download the latest log and I think the mission commands are all written to the dataflash… I think… I need to confirm this last point.

The wild swinging could be a tuning issue…

I could be wrong of course but could you try downloading the mission from the flight controller using MP?

Hi @rmackay9 ,

I was using Mission planner for everything I do. I don’t use QGC.

What exactly do you mean by:

“to confirm that Rover is storing them internally correctly, you could use the mission planner to download the waypoints from the flight controller.”

I would assume the waypoint file I have attached above is exactly that?
I recorded the waypoints with the toggle switch, opened up mission planned, read the waypoints and saved them to the file.

I have no doubt my platform still needs to be tuned more properly. But I first need a good set of waypoints that are recorded properly.

Esa,

Ok, txs for the feedback. I think I’ve identified the problem as an issue in MP and raised an issue here. Not trying to pass the buck but I’m pretty convinced that internally Rover is storing the points accurately and the inaccuracy comes from how MP is saving the waypoints to file… at this final stage it’s throwing away some accuracy.

Although it’s horribly laborious, I think if you recreated the view above by manually copy-pasting the lat/lon coordinates from MP’s command list (on the Flight Plan screen) it would all line up much better. There will still be some differences but these will come from the difference between the GPS and the EKF’s position estimate I think.

Hi @rmackay9,

Thanks for checking that out. Can you please clarify if the Waypoints logging via CH7 toggle switch only use GPS rather than the estimated EKF pos?

Now that we think the problem is with Mission planner do you know for sure if Qgroundcontrol also has a similar issue?

Also can you please clarify what you mean by

“if you recreated the view above by manually copy-pasting the lat/lon coordinates from MP’s command list (on the Flight Plan screen) it would all line up much better”

I’m not quite sure what the workflow is for this .

  1. Open MP
  2. Click on Flight Plan Screen
  3. Load WP from File
  4. Observe the crooked waypoints on the screen .

Then …

Copy and paste the following lat/long (see image below) to where? Line it up with what?

44%20AM

Sorry just a little confused

Cheers
Esa

Esa,

A few answers:

  • The ch7 toggle uses the EKF’s estimated position, not the GPS.
  • i’m unsure if QGC has the same issue.
  • the work flow would be:
    i. open mp
    ii. click on flight plan screen
    iii. press the “Read WPs” button to download the waypoints recorded using ch7 switch to MP
    iv. take the lat/lon values from MP’s command list to re-create the ros-vs-planner.png.

For the last answer, I think the lines won’t be so squiggly. If the lines are squiggly then that implies the GPS is doing a better job of estimating the vehicle’s position than the EKF (which is using the GPS points as an input). That would probably mean that some other sensor is causing the EKF’s position estimate to be incorrect.

Hopefully that helps.

Ok …

Please note that

The blue line that I have in the ros-vs-planner.png is the Global_Position/Global msg (EKF global position - I’m assuming ) vs the waypoint log file that I have attached in the post above.

I did you test .

read the Mission waypoint from the rover and compared it to the waypoint file I used to generate the yellow line in the graph in my post.

There are differences in the numbers ! Line 1 in the text file corresponds to waypoint 1in MP.

Yup, so that confirms my thoughts and so it’s really up to Michael Oborne (or someone else happy to fix issues in MP). I’ve raised the issue here. This shouldn’t affect how the vehicle drives though.

Good to hear that the blue like is from the EKF, it’s a nice pretty straight line so seems like the EKF is working.

Update: it looks like Michael Oborne has fixed the issue so it should appear in the next beta version and eventually the official version. Thanks @meee1