Bitcraze Forums

Cool.. looking forward on how well your altitude ctrl works

Me too....its so much black magic.

Right now im trying to figure out how much the voltage drop affects my PID parameters..sadly quite considerably Need to figure that out

Yeah for this it would be good if one could ctrl the "real" thurst. This idea already came up in the other hover thread here:

beat wrote: I think it would generally useful to compensate the battery voltage dependency of the motor control values ( pwmDuty = controlValue * constant / batteryVoltage ).

This equation of cause is just a simple linearisation of the problem, but would already be quite usefull.

Quick results just using the barometer:

http://www.youtube.com/watch?v=aRsvPyRQaFA - static
http://www.youtube.com/watch?v=0oYzMVUKZKI - moving

Next up Ill try to use the accelerometer. Once everything is working ill post the code, but for now ive changed so much (using my own flie driver in python & ROS, etc)

Very very nice! And with accelerometer data as well it can probably be even nicer!

very nice any chance you share your code?

This looks great. I'm glad you are doing a lot of the leg work in testing this. You need to be careful that its not over filtered. If you are going to create a feedback loop to control height you do not want too much lag. Is it possible to try a step change in the pressure? Perhaps run it for a bit and then drop the flie onto something soft. Would be great to see the raw and filtered for this.

For extreme flight you may want to consider trying to keep a constant vertical thrust. As the flie tilts only some of the thrust is down. If you know the real tilt then you want 1/cos(x) compensation (up to a point).

Yo!
Here is the graph you are looking for!

It displays the height from the baro:
- Raw signal (cyan)
- Symmetrically fitted signal (cant get this in real time, only once one knows the "future" values). This represents a perfect filter without lag (red)
- LPF with alpha = 0.92 as mentioned in the posts above (blue). You can see the lag if you compare it to the above signal (red). A quick look at a peak seems indicates the lag is around 11ms
- Ground truth (black)


Link to image for full res (you can zoom in): https://docs.google.com/file/d/0Byd2j7X ... sp=sharing
Let me know if the links dont work.

Hope this helps

Note that the barometer gives you pressure, which I convert to altitude above sea level (around 550ish meters here). I used the first 10 seconds or so of data to compute the mean above sea level with the quad sitting on the floor. I use then subtract this estimate from all height estimates so when the quad is on the floor the altitude is reported as 0 meters. Here you can see the noise/variance etc. Note that once I apply thrust for takeoff, the pressure/temperature changes and the quad first reports a -0.5m altitude above ground level, even though it has not moved yet.

For reference Ive uploaded the code and the thread is being continued here: http://forum.bitcraze.se/viewtopic.php?f=6&t=523