Running copter inner loop at 400Hz on Pixhawk/Iris?

[Chris Anderson]

Team, 

As you know the first flight code that will be released on Pixhawk will be APM:Copter, optimized for Iris. Given the amount of processing power we now have available (and the fast-response SimonK firmware on Iris), it seems like an opportunity to speed up the inner loop from 100Hz to 400Hz, for faster response and better stability.

What do you think? Is this a relatively easy experiment to try, to see what kind of performance improvement it gives?

Best, 

Chris

--
Chris Anderson

CEO, 3D Robotics

ch...@3drobotics.com

[Randy Mackay]

Chris,

     It's not terribly hard, I did a review a few weeks ago and found about 5 ~ 10 places where we have hardcoded times in the code so we would need to replace those with different hardcoded numbers for the px4-fmu2 or better yet replace with an actual time since the previous iteration.

     ..another option is just to try to speed up the inner rate controllers to 400hz first.  The rate controllers are the lowest level of control so speeding them up might provide the biggest boost.  Also they're already quite independent so the change is relatively easy I think.

-Randy

---

From: Chris Anderson <ch...@3drobotics.com>
To: drones-discuss <drones-...@googlegroups.com>
Sent: Saturday, August 31, 2013 11:09 PM
Subject: [drones-discuss] Running copter inner loop at 400Hz on Pixhawk/Iris?

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Robert Lefebvre]

My opinion on this is that it's definitely possible and worth trying, but I'm skeptical we'd see a lot of opportunity for improvement.  The physical response rate of the copter just isn't that fast.  A number of other systems on the market advertise 400Hz updates, or even the physically impossible 800Hz....  But the propellers have a response rate that is slower than 400Hz to start with.  And then the rest of the airframe also has a response rate slower than that.  The fact that we are currently running with a 10-20Hz filter with no noticeable effect also highlights this fact.  

IMO, the idea of a 400Hz update rate is purely marketing driven.  

Have we got any objective benchmark data about stability compared to competitors that would allow us to make a decision on whether or not it's worth dedicating using the processing resources for this?

I would like to see more resources put into advanced attitude rate planning.  Limiting jerk in both the stab controllers, and the navigational controller.  I'd also like to see CG-IMU offset correction.

Also, there's no question that we should probably be running the navigation controller as something faster than 10Hz.  Maybe 50-100.  I'm mainly questioning if there's any real benefit to running the rate controllers at 400 Hz rather than 100Hz.

[Robert Lefebvre]

Randy, would it be hard to set it up such that the rate we run these loops at is defined by a #define or parameter, instead of hard coding it?  I think that would be a good thing to do whether we decide to run at 400 Hz or not.  

[Curtis Olson]

Here are a couple thoughts.

• you need to be able to query the sensors ... especially gyros and accelerometers at 400hz for this to make sense.
• you need to be able to update the attitude estimate also at 400hz which shouldn't be that difficult (cpu-wise) if the sensor data is coming in that fast.
• you need to be able to drive your servos at this rate (and the servos would need to be able to respond to signals at this rate.)  Oh wait, we are just running motors faster/slower on a quad ... so can the motor controller and prop speed respond noticeably better at 400hz vs 200hz vs 100hz?  Probably not since the motors/props have quite a bit of momentum relative to 1/400th of a second.  But I'm a fixed wing guy so I'm mostly guessing at how the motor controls might respond at these higher rates.

So there could be some benefit at the front end for integrating your attitude estimate with a smaller time step.  But running your filters faster than your sensor input doesn't make much sense to me.  If you are driving servos, remember that analog servos can only respond to 50hz inputs, and digital servos can respond to much faster signal updates but I don't know the practical limit.  I've heard of people driving their digital servos at 200-250 hz.  You might be able to send the signals even faster than that, but would the servo's electronics and motor respond any faster or better?  There might be some internal servo limits that need to be tested.  It does make sense to me to drive your servo output signal faster than your inner update loop ... my theory is that if you are driving your servo output signal at 200hz and updating your inner loops at 100hz, the servo could pick up any change in the control command 1/200th faster (on average, [caution, on-the-fly-stats here]) :-) so you could get a tiny bit better response from your system running the servo output signal faster than the inner loop.

Otherwise, unless you are significantly reducing battery life or creating a lot of extra heat, I can't think of any reason you wouldn't want to query your sensors and run your filters and inner loops and then drive your output servos/signals as fast as you possibly can with the available cpu bandwidth.

Curt.

Curtis Olson:

http://www.atiak.com - http://aem.umn.edu/~uav/

http://www.flightgear.org - http://gallinazo.flightgear.org

[Gareth Owen]

I'm with Robert on this. In the absence of quantitative data to the contrary I just don't think there will be any improvement. I doubt the motors can even respond at 100hz we use now (recently reduce from 200hz because of noise by tridge I think). We have a 20hz low pass filter because much above this is just noise.

I've found good stability can be achieved at less than 50hz easily.

Gareth

[Arthur Benemann]

Just remembering something from my class on digital control systems (note that it may be a little outdated):

Going as fast as your ADC or actuator may not be the best choice. With a too high sample rate the poles/zeros of the system/controller start to move toward the unity circle (or the zero I'm not sure). This causes the influence of numerical rounding errors become dangerous. I remember doing a MATLAB experiment with a simple system+PID controller, in which just by increasing the sample rate caused the system to become unstable.

Long story short:

When Increasing the sample rate be careful of numerical errors.

[Arthur Benemann]

Just to complement my last post:

This is not to say that oversampling the ADC and actuator isn't a good idea. You can simplify a lot the noise/aliasing problems by doing this.

[john...@gmail.com]

Just remember that the faster update isn't necessarily directly linked to the frame visibly moving, but more about finding a equilibrium where the system does as little hunting for a stable position as possible in the PID's etc. There is also a couple of other aspects like quicker response to external factors (gusts of wind), and possibly better handling if you lose a propeller etc.
Also, if 20khz was all we ever needed then why does SimonK clearly help with stability and re-positivity. There is a demo from the Mo-Cap quad system where they slowly lower the refresh and it breaks apart somewhere around 30hz I think.

- JAB

[Emile Castelnuovo]

From my experience in fast loops on VRBRAIN (ARM STM32F4) I can tell that probably the best option would be a slightly different approach.

Now that we "speak the same language" I would suggest this approach:

Sample the MPU6000 with 1Khz update rate (fastest possible using internal filter)

Run main loop at 200/250Hz and get 5/4 MPU6000 samples averaged.

Slightly rise default filter to 42Hz or 98Hz

Run scheduler ay 2KHz to get all MPU samples OR (better)  re-enable interrupt on MPU6000 to add the samples in the sample array, so scheduler can still run at 1KHz.

Last but not least change the full scale to 1000 dps, this give a slightly more fine resolution

I have successfully flown with this, and I can surely tell the difference is noticeable, smoother, that's the word I would use.

Now I'm not sure what are the performances on your new IMU chip, but I reasonably think that it can be done.

Recently to keep up with the AP_HAL, we switched to the APM:Copter looping time but already working to get the "original" configuration back to life.

Best,

Emile

2013/9/2 <john...@gmail.com>

[Meier Lorenz]

Emile,

Thanks for sharing. This has already been done, for the MPU6K and for the new sensors. But with a proper filter design (digital Butterworth) and identification, not a moving average, which is from a filter view not n optimal choice. The 1000 dps resolution is something worth considering, but last time we discussed this, the verdict was that this range is too narrow for some setups.

It is indeed quite smooth.

-Lorenz


------------------------------------------------------
Lorenz Meier
Computer Vision and Geometry Group
Institute for Visual Computing
ETH Zurich
http://www.inf.ethz.ch/personal/lomeier/

On Sep 2, 2013, at 12:59 PM, Emile Castelnuovo <emile.ca...@gmail.com<mailto:emile.ca...@gmail.com>> wrote:

From my experience in fast loops on VRBRAIN (ARM STM32F4) I can tell that probably the best option would be a slightly different approach.
Now that we "speak the same language" I would suggest this approach:

Sample the MPU6000 with 1Khz update rate (fastest possible using internal filter)
Run main loop at 200/250Hz and get 5/4 MPU6000 samples averaged.
Slightly rise default filter to 42Hz or 98Hz
Run scheduler ay 2KHz to get all MPU samples OR (better) re-enable interrupt on MPU6000 to add the samples in the sample array, so scheduler can still run at 1KHz.
Last but not least change the full scale to 1000 dps, this give a slightly more fine resolution

I have successfully flown with this, and I can surely tell the difference is noticeable, smoother, that's the word I would use.

Now I'm not sure what are the performances on your new IMU chip, but I reasonably think that it can be done.

Recently to keep up with the AP_HAL, we switched to the APM:Copter looping time but already working to get the "original" configuration back to life.

Best,
Emile

2013/9/2 <john...@gmail.com<mailto:john...@gmail.com>>

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<mailto:drones-discuss%2Bunsu...@googlegroups.com>.

For more options, visit https://groups.google.com/groups/opt_out.


--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<mailto:drones-discus...@googlegroups.com>.

[Emile Castelnuovo]

Good Lorentz, but this is not for the APM:Copter firmware right?

2013/9/2 Meier Lorenz <l...@inf.ethz.ch>

[Leonard Hall]

Hi all,

I have been talking to Randy about this and my understanding of the plan is to make all time loop frequencies user definable so we can explore the options. 

My expectation of the results is that we will see little to no improvement running the main loop quicker but we could go as high as 400 Hz. The big advantage is aliased noise rejection when calculating our attitude (DCM ect.) and position (inertial navigation). I do expect to see loiter and auto mission improve significantly if we can increase them from 10 Hz to near 100 Hz, especially during high yaw rates.

As for the signal conditioning, the PX4 based processors are all sampling at around 1kHz and then filtering down to around 30Hz. The last sample then just grabbed whenever it is needed at what ever rate it is needed.

And finally the reason the SimonK firmware improves the performance is because it doesn't have the delay. The thing we need to be very mindful of here is the time it takes for our gyro to detect a rotation through to the time we can change the RPM of the propeller to counter that movement. Here every little delay adds up and the Simon K addresses a significant part of that delay. When people reduce the update rate of the ESC's it isn't the frequency that is significant, it is the delay that it creates that causes the problem.

Leonard