Hi Wojciech,

You said:

"Hi
I already contacted Doug, and unfortunately as far as he knows there were none successful attempts.

I was looking at what you wrote in the comments and at your code and as far as the 'dead reckonig' the code is fairly simple but some questions still emerge:

1.How is the GPS latency problem tackled? I see that you feed the error back into the estimates but how that including the data latency?
2.How is the problem with coordinates solved? GPS gives you absolute position and the IMU data is relative movement...

Sorry if i ask the obvious questions, I'm not very familiar with Matrixpilot code

Best Regards
Wojciech Batog"

1. There are several ways to account for GPS latency. I have tried two different methods. The first method that I used was to filter the IMU data with a model of the GPS before comparing it with the GPS data. This method did not work so well. The second method that I like and that I now use a simple geometrical computation that plots a polygonal helix to estimate where the plane really is during a steady turn. If you want to look at the code, it is in the GPS parser. Since the dead reckoning is working primarily from accelerometer data, all you need from the latency compensation is to eliminate bias.

2. In MatrixPilot, all positions (GPS or IMU) are computed in relative coordinates. There is an origin. The origin is subtracted from each GPS reported position to get a relative position. The IMU positions are also measured relative to origin. The origin can be either the location of the plane on power up, or you can specify a fixed origin.

We have been using dead-reckoning in MatrixPilot for some time. It works quite nicely. For example, it continues to provide accurate estimates of position during portions of aerobatic flights that defeat the GPS, such as a straight down spinning dive.

Best regards,

Bill