Wojciech Batog
• Male
• Poland

1076 members

295 members

# Wojciech Batog's Page

## Profile Information

I'm a student of Robotics from Poznan University of Technology in Poznan, Poland. I'm also a glider pilot.
I have an intrest in IMU's and flight augmentation
Hometown:
Poznan

## Comment Wall (3 comments)

At 4:51pm on November 9, 2011,
T3
William Premerlani
said…

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

At 2:36pm on November 10, 2011, Wojciech Batog said…

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.

Best regards
Wojciech

At 1:35am on August 23, 2012, Marooned said…

Greetings from Poznań! :)

Join DIY Drones

1

2

3

4

5

6

7

8

9

10

## Groups

283 members

1472 members

45 members

470 members

• ### 3D Models

57 members

Season Two of the Trust Time Trial (T3) Contest
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here