New firmware not flying straight

Since we have updated from Cube black 3.6.7 all subsequent versions do not fly straight lines anymore.

This has been tested on multiple flights (over 20)

We won’t go back to 3.6.7 because of the IMU failover not working.

We are flying a Cube Black (old version not affected by SB_0000002)

One notable change is we are using a Here 2 GPS because we can’t get the Here 1 anywhere anymore… which is super annoying. I hate changing hardware for this very reason.

Attached is a screen shot of logged vehicle paths. One is the onboard Pixhawk cube gps. This path shows that the drone THINKS it is exactly flying on the required waypoint path and it looks good (but it’s not)

The other track shows the path as recorded by an independent onboard GPS. You can see that the Pix “thinks” it’s flying straight but in fact it is not. The arcs in the paths are enough to cause serious issues with photo overlap.

The problem never existed on 100+ flights before 3.6.8

Compare%20pix%20recored%20path%20to%20independent%20gps%20path%202

Any thoughts?

Here is a screen shot of the actual path, as you can see it flies in an arc from waypoint to waypoint this results in very poor photo overlap.

Here is what the Pix Cube “thinks” it did, they tracks look straight but they are not in reality.
This is the path flown directly from PIX onobard log. It almost looks too perfect like I screen grabbed the flight plan… but I did not if you get close there are slight deviations and the corners of course are round etc.

I would go through your entire compass setup and also perform the motor compass compensation, make sure your only using the external compass and not the internal one as well

Follow this whole page though

http://ardupilot.org/copter/docs/common-compass-setup-advanced.html

Re-calibrating your compass as @MadRC described might be just what you need and that may resolve the issue. Try that first since it is little to no cost.

Otherwise, we need to isolate is which device is ‘correct’. Unfortunately, your experimental design outlined here does not accomplish that. If the two paths matched precisely, we could assume that each path verified the other. However, due to the fact that the two paths do not match, we can assume that one is correct and the other is deviating from actual.
How and Why do you trust your standalone GPS device?
What if it is the incorrect one and the Here2 is actually correct?

You would need to test a third GPS device in order to isolate the issue here.
Do you have a third, different GPS tracking device you could try? The results could verify either the Here2 or your standalone as “correct”.

Assuming your measured path is correct - some deviation from the planned route is to be expected. How much is tolerable is the question. What is the scale of your mapping area?

Is your track of what the Here2 “thinks” actually the recorded KML/KMZ? or is that your planned route from your GCS?

What is the max deviation between planned vs measured? If that is within the stated horizontal positional accuracy of ±2.5m (±2.0m w/ SBAS) [datasheet here Section 1.3, Page 6: https://www.u-blox.com/sites/default/files/NEO-M8_DataSheet_%28UBX-13003366%29.pdf] , then you might need to look into RTK solutions in order to achieve a higher measurement precision.

Thanks for your thoughtful response… please see my response below.

Re-calibrating your compass as @MadRC described might be just what you need and that may resolve the issue. Try that first since it is little to no cost.

I have gone over that page linked… there is not much to do but set it up correctly and I have done so… this exact design has been done before, using all three compasss (yes only one is used for nav) no issues no need for compass MOT etc as the compass is far from electrical interference.

Otherwise, we need to isolate is which device is ‘correct’. Unfortunately, your experimental design outlined here does not accomplish that. If the two paths matched precisely, we could assume that each path verified the other. However, due to the fact that the two paths do not match, we can assume that one is correct and the other is deviating from actual.
How and Why do you trust your standalone GPS device?

the stand along GPS device is a post processed corrected position. 100% accurate as we use that to verify our point cloud data and camera stations are all well within spec. So we know that the secondary GPS is correct, that much I can guarantee.

What if it is the incorrect one and the Here2 is actually correct?

See above.

You would need to test a third GPS device in order to isolate the issue here.
Do you have a third, different GPS tracking device you could try? The results could verify either the Here2 or your standalone as “correct”.

See above

Assuming your measured path is correct - some deviation from the planned route is to be expected. How much is tolerable is the question. What is the scale of your mapping area?

Deviation is acceptable but this is pretty bad. Also we have never seen this behavior before, we have been flying our payload and survey missions for years. You can also see that the behavior is repeating row after row. I have a feeling some sort of IMU filtering was sacrificed when the IMU switching issue was resolved. The IMU is used in navigation for positional estimation and I think it’s estimating position wrong.

Is your track of what the Here2 “thinks” actually the recorded KML/KMZ? or is that your planned route from your GCS?

That track is the Here2 exported KMZ recorded onboard the drone, then clamped to grade in google earth.

What is the max deviation between planned vs measured? If that is within the stated horizontal positional accuracy of ±2.5m (±2.0m w/ SBAS) [datasheet here Section 1.3, Page 6: https://www.u-blox.com/sites/default/files/NEO-M8_DataSheet_(UBX-13003366).pdf] , then you might need to look into RTK solutions in order to achieve a higher measurement precision.

difference between planned and measured by here2 is very little… it thinks that it is flying correctly. However post processed positional data is way off (again never seen this before).

Yes I understand that post processed can be a few meters off. However we have never seen this before and as you can see it’s a regular pattern. If it was just the difference between post process and non post processd data then it would deviate somewhat equally around the path.

finally I also created a non post processed path from the survey payload which showed the same deviated path.

I think that the Pix thinks it’s on course however it is not. Hence why the planned path matches the Pix hawk logs. The pix hawk is not trying to correct course because the pix thinks its on course.

So that being said there is no point in adjusting any variable to make it follow the course more aggressively. The drone thinks it’s doing a good job.

Finally we have done some 1.2km strips now and the arced paths are still there but the arc just becomes longer so it is less noticeable.

Any other thoughts appreciated.

My intuition is still telling me that neither path (Here2 nor the standalone) has been verified. That being said, I dont mean to knock your assumptions that the standalone is correct. I am trying to read into your issue through internet posts and obviously I am not knowledgeable on your hardware setup and its history of repeatability.

Regardless… lets take the standalone GPS to be correct - the actual path flown. That would imply that the Cube’s position and/or attitude estimate is incorrect. Can you give us any details about the site? obviously it is some sort of excavation site, but is it possible this site has anomolous magnetic properties? I would encourage you to re-consider compass calibration.

Edit: there is also a way point lead-in angle parameter. Basically it would attempt to make the waypoint turn more smooth or even tangent. I cant seem to remember what it was called. Maybe 3.6.9 either reset your custom value or defaulted to something different?

Edit2: Check some simple stuff: are you sure Compass Declination is correct for the site?

My intuition is still telling me that neither path (Here2 nor the standalone) has been verified. That being said, I dont mean to knock your assumptions that the standalone is correct. I am trying to read into your issue through internet posts and obviously I am not knowledgeable on your hardware setup and its history of repeatability.

No worries! I too would be skeptical if someone claimed one was correct without proof. I will explain a bit of why I trust the corrected positions.

We have our own onboard survey payload which logs position. These positions are tied to camera stations (where a photo is taken) we post process these positions to a base station. After that we send this to agisoft photo scan. In there we get a good idea of positional accuracy which is then verified by checking our ground control to the actual point cloud. If those two line up then the camera station positions must have been correct. Of course we also can rely on the history behind our firmware onboard etc. But this is why I am confident in the secondary GPS information. Just to be sure we also logged the uncorrected positions and they do not line up with the Pix gps track. The survey payload uncorrected positions follow along arcs just like the corrected positions. Hope this helps you understand where I am coming from as to why I am looking at the pix being the issue.

The only thing that has changed on these drones (we have three of them all doing the same thing) is new FW above 3.6.7 and the new Here2 gps.

Regardless… lets take the standalone GPS to be correct - the actual path flown. That would imply that the Cube’s position and/or attitude estimate is incorrect. Can you give us any details about the site? obviously it is some sort of excavation site, but is it possible this site has anomolous magnetic properties? I would encourage you to re-consider compass calibration.

Thanks we have done this and seen the issue over about 5+ different sites and 20 flights so I must conclude it is not site specific.

RE compass calibration we do a calibration on “default” perhaps we should use the more strict one. As for compass MOT if that was the isssue I would expect some TBE or that the drone would not follow properly at all. It seems quite happy with itself in position hold etc. I do agree though I a not ruleing out the compass.

Edit: there is also a way point lead-in angle parameter. Basically it would attempt to make the waypoint turn more smooth or even tangent. I cant seem to remember what it was called. Maybe 3.6.9 either reset your custom value or defaulted to something different?

I can check this. I have all logs and flights saved. I use a program called beyond compare which find differences between text files for you. Its fantastic. Needle in a hay stack type stuff is easily solved.

Edit2: Check some simple stuff: are you sure Compass Declination is correct for the site?

I will check the mag dec for that site and compare. Pix has always been so good at getting correct mag decs I just assumed it was correct.

Thanks again for the discussion