cycle time vs stability?

[jy0933]

I have seen from different posts saying a higher fixed cycle time will bring mwc better stability. I wonder how significant will the improvement be? and what kind of cycle time to be fixed on can bring the best result?

currently I'm using AIOP.. tried to change cycle time to 5000.. but it seems there is still minor twitching after setting acc lpf factor and gyro filter...


thanks

[copterrichie]

To my present understanding, the cycle time is or was directly linked to the I and D parts of the PID settings. I don't believe or have I personally experienced having a higher cycle time that produced greater stability.

[jy0933]

i am thinking about a more stable/fixed cycle time than jumping around like now

[copterrichie]

There was some code done, (not sure if it is still in the recent development code) allowing the cycle time to be set in the MWC firmware and I know baseflight had the feature too. Again, not sure how much it goes towards stability.

[QuadBow]

I gave already some toughts to this question.

I calculated the differnce of the angle (pitch, roll) between two cycles in a worst case scenario and resulted in
0,06° for 1ms cycletime (ct)
0,54° for 3ms ct
1,5° for 5ms ct and
6,0° for 10ms ct

Thus a cycletime of 3-4ms is acceptable, but not more.
This is only valid for quadrocopter with a certain power of the motors and a certain moment of inertia.
The smaller the copter is, the more critical becomes the effect.

I observe that the cycletime is increasing every release and recognise an issue as to the processor performance soon - at least for small copters.

[copterrichie]

IMO, the variance in the cycle time is due to the processing of serial data, enable/disabled features. The actual flight calculations are very minimum. so having a fixed cycletime would help in this aspect, but again IMO, not with flight stability.

[QuadBow]

Having a look into the code reveals that
- a certain part of the cycletime is due to the I2C traffic => 500us
- complementory filter, rotate vector, atan2, etc takes 60 long lasting (200 clock cycles each) floating point multiplications to calculate the euler angles
- together with some LPF calculations that results easily to 1000us
- GPS code has also many floating point calculations, but it is not conduted every cycletime, so the average might be 500us

Of course, the rest of 1000-2000us is not less, but, you should not neglect the processor duty time for flight calculations (ca. 2000us).

It might be a good trial to go to a fixed cycletime, since that allows a better optimisation of PID values.

[jy0933]

i tried to trace the origin of the entire setup-cycletime-manually thing... it seems came from naze32 at the very beginning to reduce twitching due to the over-powered MCU...

honestly.. from a non-EE/programmer aspect.. it is really hard for me to understand it... and the documentation is not quite elaborated to give enough info

anyways... it sounds making sense to me setting a fixed cycle time will give a stable the correction/calculation cycle so that same PID will not bring up different results with floating cycle time ( )

[Hamburger]

the search function would link you to previous discussion here viewtopic.php?f=7&t=2378&hilit=cycle+time

[copterrichie]

the search function would link you to previous discussion here viewtopic.php?f=7&t=2378&hilit=cycle+time

R311

Code: Select all

/************ EXperimental: force a stable, fixated (high) cycle time       **********/
    /* when activated, the displayed cycle time in GUI will not be correct.
     * Tunable via LCD config menu.
     * value of 0 turns the feature off.
     */
    //#define CYCLETIME_FIXATED 9000 // (*)

[jy0933]

it looks to me that the best way to determine cycle time is to put on/enable all components will be use and observe the cycle time... then add a bit of redundancy to this cycle time as final

and then start tuning everything/parameters from here?


btw.. after reading thru that thread.. it is only said to be more stable since the averaging time is longer(average out the noise?)... but I have concern of longer averaging time is that in rapid change(gust?).. the longer average time could result in slower response.. dont we want to have a fast(rapid?)response to change and be stable at the same time?

[Alexinparis]

This is only valid for quadrocopter with a certain power of the motors and a certain moment of inertia.
The smaller the copter is, the more critical becomes the effect.

http://vimeo.com/53932030
http://vimeo.com/57046902
probably the smallest multiwii quad in the world. do you see any problem of stability

I observe that the cycletime is increasing every release and recognise an issue as to the processor performance soon - at least for small copters.

don't worry, we can stil develop other strategies to minimize average cycle time on "poor" 8bits processor (one quite obvious: no need to calculate the angles at each cycle)

[copterrichie]

Let me answer that, NO!! Ha

[albertoLG]

This is only valid for quadrocopter with a certain power of the motors and a certain moment of inertia.
The smaller the copter is, the more critical becomes the effect.

http://vimeo.com/53932030
http://vimeo.com/57046902
probably the smallest multiwii quad in the world. do you see any problem of stability

I observe that the cycletime is increasing every release and recognise an issue as to the processor performance soon - at least for small copters.

don't worry, we can stil develop other strategies to minimize average cycle time on "poor" 8bits processor (one quite obvious: no need to calculate the angles at each cycle)

I WANT ONE!!!!!!!

[QuadBow]

Alexinparis wrote:

QuadBow wrote:This is only valid for quadrocopter with a certain power of the motors and a certain moment of inertia.
The smaller the copter is, the more critical becomes the effect.

http://vimeo.com/53932030
http://vimeo.com/57046902
probably the smallest multiwii quad in the world. do you see any problem of stability

It is really amazing, that the algorithm is able to cover such a small copter. For that the PID values must have been selected very properly.

I observe that the cycletime is increasing every release and recognise an issue as to the processor performance soon - at least for small copters.

don't worry, we can stil develop other strategies to minimize average cycle time on "poor" 8bits processor (one quite obvious: no need to calculate the angles at each cycle)

Well, even if it is a worst case scenario, that I pointed out earlier, the angle can change at a cycletime of 5ms 1.5° every cycle for a mid-size copter.
The littlelun of a tenth of this size would change 15° every cycle !!! I don't belief that we should abolish angle calculation every cycle.

If there was a need for optimisation of the currently used 8bit processors my proposal would be:

Reduce the number of small functions in the code and replace them by definitions (e.g. serialize32, vserialize16, serialize8 with only a few lines of code)
+ faster code
- larger code, so it is only applicable for Mega boards

Avoid any use of floating point calculation and use a fixed point library
+ faster code
- significant change required

Realise functions like atan, sqrt as a look-up table
+ very fast code
- very large code, so it is only applicable for Mega boards

Go for a fixed cycle approach
+ only one measurement of the gyros required, less i2c traffic
- requires a scheduler, so it is a significant change of code

@all
So, before coding, what do you think about it?

[Hamburger]

use the existing feature of fixating cycle time to make your own real world flight tests, report results and from there start debating possible improvements

[copterrichie]

I think we need a definition of Stability.

[Alexinparis]

Well, even if it is a worst case scenario, that I pointed out earlier, the angle can change at a cycletime of 5ms 1.5° every cycle for a mid-size copter.
The littlelun of a tenth of this size would change 15° every cycle !!! I don't belief that we should abolish angle calculation every cycle.

What angles are you talking about ?
PITCH&ROLL angles are computed in getEstimatedAttitude(), and in this function (currentT - previousT) is taken into account.
So the cycle time variation should not be an issue here, no ?

If you talk about the main PID control loop and the way to estimate each I&D, yes there is no dTime. But it's apparently not an issue ragarding the variation cycle time.

Reduce the number of small functions in the code and replace them by definitions (e.g. serialize32, vserialize16, serialize8 with only a few lines of code)
+ faster code
- larger code, so it is only applicable for Mega boards

how much faster ?

Avoid any use of floating point calculation and use a fixed point library
+ faster code
- significant change required

This was something in my dream: not a single line using a float.
a prototype on this is highly welcomed.

Realise functions like atan, sqrt as a look-up table
+ very fast code
- very large code, so it is only applicable for Mega boards

as you say: very very large code...

+ only one measurement of the gyros required, less i2c traffic

I never tried to tune more this empirical code, since the stability result is excellent:

Code: Select all

    Gyro_getADC();
    for (axis = 0; axis < 3; axis++)
      gyroADCp[axis] =  gyroADC[axis];
    timeInterleave=micros();
    annexCode();
    if ((micros()-timeInterleave)>650) {
       annex650_overrun_count++;
    } else {
       while((micros()-timeInterleave)<650) ; //empirical, interleaving delay between 2 consecutive reads
    }
    Gyro_getADC();
    for (axis = 0; axis < 3; axis++) {
      gyroADCinter[axis] =  gyroADC[axis]+gyroADCp[axis];
      // empirical, we take a weighted value of the current and the previous values
      gyroData[axis] = (gyroADCinter[axis]+gyroADCprevious[axis])/3;
      gyroADCprevious[axis] = gyroADCinter[axis]/2;
    }

It's a kind of "magical" combination.
I never managed to get the same stability using a single gyro read but this was at a time I had only a WMP to test.

[QuadBow]

Well, even if it is a worst case scenario, that I pointed out earlier, the angle can change at a cycletime of 5ms 1.5° every cycle for a mid-size copter.
The littlelun of a tenth of this size would change 15° every cycle !!! I don't belief that we should abolish angle calculation every cycle.

What angles are you talking about ?
PITCH&ROLL angles are computed in getEstimatedAttitude(), and in this function (currentT - previousT) is taken into account.
So the cycle time variation should not be an issue here, no ?

If you talk about the main PID control loop and the way to estimate each I&D, yes there is no dTime. But it's apparently not an issue ragarding the variation cycle time.

I am talking about the roll and pitch angles in a worst case scenario. That could happen e.g. when the PID values are totally wrong.

Reduce the number of small functions in the code and replace them by definitions (e.g. serialize32, vserialize16, serialize8 with only a few lines of code)
+ faster code
- larger code, so it is only applicable for Mega boards

how much faster ?

A first step would be to use the attribute "inline" and let the compiler decide whether to implement the code as a function or just to place the code every time like a definition. This attribute is already used for some functions e.g. sonar_init() or SerialOpen(). Using it to a larger extend would increase code a bit and reduce the time required by the code, since only the function call and the return requires 8 clock ticks.
At a first glance I inserted a lot of "inline" attributes in the code, in particular in "serial.ino" and "sensors.ino", because there are really many small functions. The code was enlarged by 400bytes. So, it should also be acceptable for a 32kB flash processor.
I will study and report back how the resulting cycletime will change. Is there a fast way to low-pass-filter the cycletime already implemented in the multiwiiconf software?

Avoid any use of floating point calculation and use a fixed point library
+ faster code
- significant change required

This was something in my dream: not a single line using a float.
a prototype on this is highly welcomed.

A fixed point library is not the issue, since it has been described by Atmel's application note no. 201.
The result is that a fixed point multiplication takes 20-25 cycles and a floating point multiplication 125. For an addition, there is a factor 10!
The challenge is to normalise the used variables to the appropriate extent. If the variables are too high, it results in an overflow, if they are too low, they are treated as zero. So, I am going think a bit more about it...

Realise functions like atan, sqrt as a look-up table
+ very fast code
- very large code, so it is only applicable for Mega boards

as you say: very very large code...

You are right. You can only implement one table for one function with 16bit input and 16bit output at a mega board.
I think, I will not continue those thoughts, since the small angle approximation is actually accurate enough and fast enough for our purposes.

[QuadBow]

Reduce the number of small functions in the code and replace them by definitions (e.g. serialize32, vserialize16, serialize8 with only a few lines of code)
+ faster code
- larger code, so it is only applicable for Mega boards

how much faster ?

My investigations concluded as follows:
r1240 leads to an average cycletime of 3280us.
The step to r1317 rises the cycletime to 3350us, the programm code increased about 2kB (no issue for a mega board).
Making widely use of the "inline" (instead of definitions as firstly proposed, it's more simply to implement) attribute leads to a reduction of the cycletime to 3290us, the code was again increased, but only by 170 bytes.
Remark: the times have been measured at my hardware and software confuguration. Thus, there are no statistics beyond it. But I expect a similiar reduction of cycletime for more or less every configuration, since the additional load for every function (call function, parameter handling, return to main program) has been eliminated by this way. (And there are a lot of small functions which cause that burden.)
I filtered the cycletime in order to receive a non-flickering result I could read from the screen.

For me it seems to be fine, the only disadvantage is the small increase of memory needs. For those who want to test this approach just put the attribute "inline" in front of the fuction declaration, in particular for all the small functions referring to other functions, e.g.
uint32_t inline read32() {
uint16_t inline read16() {
uint8_t inline read8() {
void inline serialize32(uint32_t a) {
void inline serialize16(int16_t a) {
void inline serialize8(uint8_t a) {
int16_t inline _atan2(float y, float x){
float inline InvSqrt (float x){
int32_t inline isq(int32_t x){return x * x;}
void inline rotateV(struct fp_vector *v,float* delta) {

But, of course, be careful, since there is still no proof that there won't be any negative impact.

The next think I will ceck out is the use of a fixpoint library instead of some float expressions.