search

ArduPilot / MissionPlanner

Mission Planner Ground Control Station for ArduPilot (c# .net)
http://ardupilot.org/planner/
GNU General Public License v3.0
1.81k stars 2.42k forks source link

Flight Data screen Vehicle position #995

Open lvale opened 9 years ago

lvale commented 9 years ago

While I was testing CopterRC11 I managed to save the TLog while I was checking a few things, and noticed that when AutoPan is enabled on the FlightData Map screen the vehicle position is varying widely not corresponding to where the vehicle might be.

The vehicle GPS might be reporting no sats or a very low number and the GPS position on screen changes a lot, from Africa to Europe in seconds.

I would suggest that the map vehicle position should only change with a reasonable vehicle position estimate (i.e. ignoring the 0 sats and 100 HDop) and only position the vehicle with at least a 2D Fix.

Link to both the bin and the TLOG (on the Tlog after about 10% this can be seen quite clearly)

https://drive.google.com/folderview?id=0BzRxu4IwHPYCQ1E4RHhDQ04tM0E&usp=sharing

lvale commented 9 years ago

I wasn't here. But MP says I was....

untitled

meee1 commented 9 years ago

that's what the autopilot was reporting at that point in time. I'm in two minds about leaving it like this.

lvale commented 9 years ago

Michael, The autopilot might be reporting that but as you can see it also reports NoFix, so I believe it should be ignored. I'll have a word with Randy to perhaps disabling sending lat+lon without GPS fix. That would sort the issue? Right?

lvale commented 9 years ago

I was looking at the code here: https://github.com/diydrones/ardupilot/blob/master/libraries/GCS_MAVLink/GCS_Common.cpp#L915

which I assume that is what you are using to plot position, and imho it doesn't make sense for this function to filter by gps fix type, as it is sending raw data, and the GCS should know how to handle that when it doesn't make sense :)

meee1 commented 9 years ago

you are making an assumption that gps is always the method of location. which i cannot make that assumption. the values you see will be partly INS driven, the question is should these bad gps values be making it into the INS solution?