Developer

Arducopter Alt hold

3689422262?profile=original

This is a simulation I'm working on to improve the Altitude hold and change control laws. I have identical code from Arducopter running in Flash as OO Javascript so I can ensure the behavior is the same as the real thing. I sampled data from the barometer to introduce identical noise into each copter's solution. This allows me to test PID and other tricks side by side and see how the copter will behave. The copter itself is a simple physics equation and should be fairly accurate.

 

The Hover value is in your logs when you switch to Alt Hold. You should see it with the mode switch name. Mine was 495 which is the equivalent of 49.5% throttle. A lower value has a profound effect on the flight so play around with that.

 

The A copter is the current control solution. The B and C copters are Pi->Pi rate based solutions and are identical. You can adjust PID setting to pit the two against each other.

 

The scale on the left is meters. The Sonar is active and the mix is identical to the current AC2 solution.

 

This new code is in testing and will be available next week in 2.0.40b

Jason

 

 

 

 

E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones

Comments

  • Developer

    I'm heading out in 10 min. I will film it for you.

  • That is Great....

    I want to see :D

  • Developer
    I spent sat night on the baro and reworked it. It's really good now! Like sonar in the sky.
  • Developer

     

    Perhaps that a solution would be to use 2 baros devices ? or 4 baros and average them ? This would filter the random walk.

     

    "Also, I believe the baro is not really noisy. It has a random walk that takes a few seconds. That's incredibly hard to filter and a faster filter won't help that."

     

  • its cool :)

  • Hi jason

    Maybe Roberto can make some tests with his MP32 (with 40 Hz). The board should have some 'spare' CPU cycles for this. Could be interresting

  • Developer

    I'm worried we don't have the  CPU cycles to read at 40Hz. The baro is an incredibly complex calculation. If you want to do some experimenting, try reading the raw data. I've been thinking we could take some shortcuts on the calculations since we only need a few hundred feet of accuracy. 

    Also, I believe the baro is not really noisy. It has a random walk that takes a few seconds. That's incredibly hard to filter and a faster filter won't help that.

  • The simulation looks really nice!

    I'm very curious about baro performance and how to get good alt hold from so noisy data, I couldn't get good alt hold yet.

    I did some tests of the baro on the table, getting values for some time and graphing histograms to see the distribution of the values. I get different results from 3 consecutive tests, not a consistent deviation. I'm wondering why is that. Did you get consistent noise values from your samples?

    I see the baro is read at 10Hz.What do you think about reading at 40Hz (is it the max?) with filter of bigger size?

    Maybe this is not affecting too much, but did you note that barometer.Read() gives a duplicated value every 5 calls? There is a state machine of 5 states, one is for temp and the pressure is not updated for that state, keeping the value of the previous call.

  • Developer

    Yes, Testing it today. Loiter and RTL are sooo much better. It's stunning.

    Jason

  • Hi Jason,

    That is very good news!  Will this solution also work for GPS hold?, to make it also more accurate?  And even waypoint navigation?

    Greetings,

    Hein

This reply was deleted.