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?
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.
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.