A bug in AC3.1 inertial navigation code?

There may be a mistake in calculation of inertial navigation.

This issue I've posted on ardupilot.com forum on APM:Copter>>3.1, but so far there is still no replies, so I post it again here with the hope that someone can give me an explanation.
In AP_InertialNav::correct_with_baro() because of the delay of 150 ms from baro we should calculate error using historical estimates about 15 samples ago (exactly the delay then is something between 140 and 149 ms). With the cyclic buffer of 15 samples it means the oldest sample or the sample at the _head index.
However, I read in the code that hist_position_base_z = _hist_position_estimate_z.peek(14).
In AP_Buffer.cpp there is j = _head+position; here position =14. For simplicity we can imagine that if _head = 0 then j =14 and in the end it returns _buff[14], that is the latest sample not the oldest one. The same issue can be seen with correct_with_GPS().
Can anyone in the development team give an explanation?

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –

Replies

  • In that commit I don't see the fix for correct_with_baro(). In the commit we've checked if buffer if buffer is full then get the delayed sample at the front, otherwise get the current sample. If the buffer is not full it's true that we can't get the delay, but we don't know either that between the sample at the front and the current sample which one is closer to the point of sensor reading. So IMHO we don't need to check that buffer is full or not, just take the sample at the front.

    Another issue is that when we discard the samples because dt is big then we need to reset position_error. With GPS there is no problem because there is a clearing position error if GPS updates stop arriving in 300ms but for baro there no such a reset.

  • Hi, this bug has been fixed since this commit was made:

    https://github.com/diydrones/ardupilot/commit/e23135faa1fab89822c56...

  • IMO for the cyclic buffer with the number of samples = size = 15, the delay is 15 samples, so if now we get the baro data, it means that the inertial calculation for that data was 15 samples ago, or it should be at the beginning of the buffer, the sample at index _head. But as I've showed in the concrete example, instead of returning the sample at the _head (_buff[0]), the sample at the tail is returned (_buff[14]). The same miscalculation can be seen in GPS delay compensation.

  • Developer

    Hmm, really?  I heard a similar report (perhaps the opposite) in AC3.0.1 from neurocopter and we fixed it for AC3.1.

    Of course it's possible that it was correct for AC3.0.1, neurocopter was wrong and I agreed with him and made it incorrect but I did look at it pretty closely at that time and tried feeding in a particular value to make sure that the delayed value was what was coming out.

  • It seems that no one wants to reply. May I ask from Randy, an expert in this field in my view, that what does he think about this issue, am I right or wrong?

  • There's still no replies at all. I'd like to know at least the viewpoint from anyone in the development team. I don't know the 3rd order complementary filter algorithm and highly appreciate if anyone can provide the link to that algorithm description.

This reply was deleted.

Activity

DIY Drones via Twitter
RT @chr1sa: After more than a year of only virtual races, @DIYRobocars returns to the newly renovated @circuitlaunch on May 22 for the resu…
yesterday
DIY Robocars via Twitter
RT @DAVGtech: And now available with LiDAR 🔥 https://twitter.com/Heavy02011/status/1381137016381964293
yesterday
DIY Robocars via Twitter
RT @Heavy02011: #VirtualRaceLeague: @DIYRobocars Race #9 - #ParkingLotNerds #thunderhillracetrack, CA Join us for the next race April 24th,…
yesterday
DIY Robocars via Twitter
RT @DWalmroth: Weather's finally cooperating, looking forward to racing 1:10 scale autonomous cars outdoors again! @diyrobocars, @NVIDIAEm…
Wednesday
DIY Robocars via Twitter
RT @AIDRI_: I finally succeeded in optimizing the trajectory and speed of a car on a #racetrack. Next step: implement a 2d controller and…
Wednesday
DIY Robocars via Twitter
@jetdillo @circuitlaunch Actually the second *in person* event in a year. We do virtual races every month
Apr 2
DIY Robocars via Twitter
Update: we're moving it back one day to Sunday (the 4th) at 11:00am instead
Apr 2
DIY Robocars via Twitter
@GrantEMoe @circuitlaunch Update: we're doing it on Sunday (4th) at 11:00am instead
Apr 2
Laurie J. Troy liked Jasper Kueppers's profile
Apr 1
DIY Robocars via Twitter
RT @chr1sa: Maybe we should have a mini @DIYRobocars race in our lower school's playground https://t.co/xLFeua1R6X
Mar 29
DIY Robocars via Twitter
If anybody wants to join us for an informal outdoors hack/race we're going to be meeting at the @CircuitLaunch park… https://twitter.com/i/web/status/1375907409223249923
Mar 27
DIY Robocars via Twitter
RT @SmallpixelCar: Ready to reopen, innovation has to continue. Inside/outside, LiDAR/GPS, race/delivery https://t.co/jpmvttoHEd
Mar 26
DIY Drones via Twitter
RT @DAVGtech: By far best race yet! Congratulations to the winner @Heavy02011 🥇🏆🍾👏👏👏 @diyrobocars @donkey_car @NVIDIAEmbedded https://t.co/…
Mar 20
DIY Robocars via Twitter
RT @Heavy02011: #VirtualRaceLeague: @DIYRobocars Race #8 - #ParkingLotNerds ⁦@DAVGtech⁩ ⁦@DWalmroth⁩ ⁦@OttawaAVGroup⁩ - join us tomorrow h…
Mar 20
DIY Drones via Twitter
RT @mrpollo: 11 years ago, the pxIMU was announced to the world on @DIYDrones, and it changed the life of many (mine included). The followi…
Mar 18
DIY Drones via Twitter
RT @ishcahealth: This is awesome! ☘️ @DroneDJ @DIYDrones @WorkerDrones @DroneMedia_UK @dublinaviation https://twitter.com/media_ireland/status/1372077878536462336
Mar 18
More…