"This is a very good initiative. It is now very hard to find reliable thrust data for electric motors especially the larger ones.It would be great if you could get some (preferably all) manufacturers to submit their data.Unfortunately, I feel that…"
"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.
This is very interesting. I didn't look at the GPS parser before. Now I look at the code and and try to figure it out.
I don't yet get how you can simply compute the error with accelerometer and GPS data since theoretically those should (!) be different (movement since last GPS position).
Is this geometrical computation a predictor algorithm of sorts?
In my implementation of this algorithm i'd like to also include Height data from the pressure sensor - which would have some lattency of it's own so I think that good understanding of this latency issue is very important.