Bitcraze Forums

The 'slippery' feeling is (in my opinion) what a self-level feature should produce. If you're flying forward at 30 degrees and release the pitch control, the copter should return to perfect level and continue in the exact same direction forward at the exact same speed. If you pretend air resistance isn't a thing, the copter would never slow down and never stop.

The behavior prior to the experimental PID settings was that the copter would kind of brake itself. If flying forward at 30 degrees and the pitch control was released, it would overshoot to like -5 or -10 degrees and slow way down, then return to level. This was due to an overaggressive PID controller that caused overshoot.

The self-braking can definitely be desirable for indoor flight, but IMO accomplishing it by tuning the PID to be over-aggressive isn't quite right: The over-aggressive control would affect all of flight, not just return-to-zero. Also, it's less controlled and precise than some specific "braking" logic that only kicks in at a setpoint of zero or something.

Agreed, the 'slippery' feeling is definitely what we want for the angle control. The angle control, if well tuned, should be seen as an acceleration control.

I would love to have some kind of "open-loop velocity control" that estimates the current speed out of thrust and angle and so we could have an auto breaking by sending velocity setpoint instead of angle/acceleration setpoint. I have done some experiment but never got the time to really finish anything yet. Lately there has been some more work done on the Kalman filter for the LPS and I think one of the output will be a pretty good estimation of the thrust which should help making this open loop velocity control.

I've been super busy with life events recently and haven't looked at this stuff much.

However, looks like Mike Hammer has been super busy with stability improvements! Anyone try out the latest firmware with the interrupt driven sensor reads and the kalman filter yet? I'm looking forward to trying it out soon. Also, looks like the Kalman is targeted at position estimation, or are there any thoughts to use it in place of the AHRS for stabilization?

In the current form the Kalman filter is mainly aimed at position estimation. However it seems to be doing a good job without position input so this is to be tested and hacked

Excited to see the recent change from @stephanbro to increase the imu sample rate to 1k -- I'm curious how this affects stability performance but I'm likely not going to get a chance to test it out for a while due to some travel plans. Anyone test it out yet?

Edit: Oh and a bunch more accel changes -- DLPF decrease, range increase, and a software LPF. I'd love to hear some of the logic behind these changes. For example, why do you need 16g of accel range? I was actually going to go the opposite route and drop accel readings that deviate too far from 1g -- the idea being to react less to external forces and prevent overcompensation by the PID loop.

I would say the stability, or maybe better term, vibration rejection is a bit better. The reson for the accel changes is that other firmwares (pixhawk, arducopter, etc) do similar to this and that we have seen saturation (or similar strange behavior) of the accel at 8g. Have no idea if it really helps though. I have been working on a SD card deck so we can log all data at high speed. That will hopefully give some answers.

Hi...i am a new user here. As per my knowledge they did put a lot of effort into the tuning when developing the CF1 but since then other tasks have taken priority.
Another thing that might improve things is the propagation delay from sensor output to actuator output. Right now we are not syncing to the the sensor output which could have an effect on performance. The interrupt line is wired from the MPU9250, it is just not used in the code.

board pcb assembly

Thanks for the suggestion @HattyDamp. During the spring 2016 the data ready interrupt is used to shorten latency. I have not measured the propagation time from sensor data to motor output though. Would be interesting to test.

HattyDamp wrote:Hi...i am a new user here. As per my knowledge they did put a lot of effort into the tuning when developing the CF1 but since then other tasks have taken priority.

A note on that: with the help of theseankelly the PID settings have been greatly improved last year for CF2, we are now confident that the settings are very good and much better than the one we had from CF1.

Hey Hatty -- you're right. The INT pin is being used to read the data but IIRC the main reason for adding that feature was to reduce CPU busy time/polling. There's still no between the sensor loop and the PID loop. Implementing that probably holds the most potential for improvement and has been on my list for a while. The sensor data rate is 500hz and the PID loop is 500hz, so that alone will add up to 4ms of latency simply due to non-synced loops. I'll try it out soon I hope!