RFC fix cycle time (to 3000us)?

[Hamburger]

we could fix the cycle time to 3000us just like the annex.code is foxed to 650us now
We gain
+consistent cycle time independant of varying sensors tim requorements in one copter
+comparable PIDs between dofferent copters.

From Alex former remarks 3ms gives decent flying.
The 3000 would be a define of course.
What do you think?

[copterrichie]

without analyzing the annex.code, what will the processor do during this time? Sleep until there is an Interrupt event? if this is true, I would think making the senor interrupt driven verse poling would be required also.

[Hamburger]

Not touching the interrupts.
Wasting time away in an empty loop.

[copterrichie]

After giving this more thought, the only sensor that would require an Interrupt is the gyro, all of the others can be poled. In fact, I strongly believe, this would also improve stability with the gyro on an interrupt. Question is, can this be done on the ProMini.

[copterrichie]

Oh and to keep it Simple, in that dead time Loop, if it was to pole the Gyro Interrupt flag, I believe it would work on a Promini without any hardware modification. Hmmm, you maybe onto something Hamburger.

[Alexinparis]

we could fix the cycle time to 3000us just like the annex.code is foxed to 650us now
We gain
+consistent cycle time independant of varying sensors tim requorements in one copter
+comparable PIDs between dofferent copters.

From Alex former remarks 3ms gives decent flying.
The 3000 would be a define of course.
What do you think?

I think before constraining any loop time, it's mandatory to make empirical tests and not just do it because we intuitively think it would be better.
For a 10DOF+GPS, we also already know that some cycles will last much longer than 3ms: mag polling (in a 9DOF case), alt measurement, alt correction, GPS frame treatment.

[Hamburger]

With a 10xof I could see periodic spikes in cycle time.
The 3000us number was just a proposal.

I am not the most qualified to debate the successrate of this approach beforehand. From what I picked up reading it seemed a possible approach for improvement.
If noone is interested we can simply drop the issue.

[copterrichie]

With a 10xof I could see periodic spikes in cycle time.
The 3000us number was just a proposal.

I am not the most qualified to debate the successrate of this approach beforehand. From what I picked up reading it seemed a possible approach for improvement.
If noone is interested we can simply drop the issue.

I would take the Challenge but can not make any commitments because I work very slow and at my own rate. I think this is very workable. Others have also made the suggestion of a fixed loop time.

[nicog]

You are porposing the same thing we have in the 32bits dev. A configurable looptime that can vary from 0 (in fact, 1.5ms normally) to 10ms.
It is know that with the fixed looptime, the level mode works better. I did some test going up to 10ms in a big quad, stability was improved.

And yes it was easy to implement (not me).

[Hamburger]

interesting.
So maybe it is not that bad an idea after all.
Yes, should be simple to implement.
'32bits dev - by that you are referring to timecop's port?
Can you describe the difference in flight characteristics between a low (like 1 up to 3.5ms) and high (10ms) fixed cycle time, if any?

[copterrichie]

Just adding a thought here, by making the loop time fixed, should aid in PID tuning right? I would think so.

[Hamburger]

at least you need not re-tune everything each time you activate/deactivate one of the additional sensors (mag, baro, gps) or enable/disable a feature that affects cycle time.

[nicog]

interesting.
So maybe it is not that bad an idea after all.
Yes, should be simple to implement.
'32bits dev - by that you are referring to timecop's port?
Can you describe the difference in flight characteristics between a low (like 1 up to 3.5ms) and high (10ms) fixed cycle time, if any?

32bits dev: Yes of course, Timecop port, what else?

Yes I can describe the diference.

What I tested with is a small 400mm quad 8x4.5 props 1100Watts of motor power and a
2.5 kg 13x4.5 propeller film rig.


1.5 excelent acro flying, super fast response to fast accelerations but poor level performance, like drunken sailor walking.
5 ms good acro performance, moderate to poor acceleration (spikes) but good level performance. minimal drunken sailor.
with big quad (13x4.5 props) 10ms no acro perf (it's a filming rig) not fast acceleration but really stable performance.
that's is what I found in my tests.


The code that does this is:

currentTime = micros();
if (cfg.looptime == 0 || (int32_t)(currentTime - loopTime) >= 0) {
loopTime = currentTime + cfg.looptime;


Of course since we have cli we can change the cfg.looptime value when needed on the fly with android naze32 configurator.

[Hamburger]

thank you. That sounds very promising.
Now I am all set to implement it into MWii, via a #define of course.

Of course since we have cli we can change the cfg.looptime value when needed on the fly with android naze32 configurator.

In MWii the lcd interface serves that same purpose.

[Sebbi]

Hmm ... what if instead of a fixed cycle time, the PID algorithms would simple use the current cycle time to calculate everything?

So the integral part wouldn't just add the new error, but the new error times cycle time and the derivative part of the controller wouldn't just be the delta, but the delta divided by the cycle time.

That should have a similar effect on the PID controller as a fixed cycle time AND it allows for wildly variable cycle times (ne need for fixed time annex code?).

A comment at increased stability with higher cycle times (nicog): that is the same effect as changing the PIDs accordingly

[Hamburger]

Frankly I do not know.
Fixing cycle time is the easiest route for me, that's why I will implement that first.

[Hamburger]

it is in _shared now.
It will waste time away in empty loop , so the cycle time is always same. Of course, only values larger than original cycle time make sense here.
Caveat: The cycle time variable used for GUI has not the correct value - could be fixed later.

How does it fly:
level mode, ie. angle/horizon mode is very flyable. I am still experimenting which way the PIDs have to go with the increased but stable cycle time.
Currently flying with 9000us (from original 3200us for a 10dof) and roughly same PIDs.

Code: Select all

 /* 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

Please share your findings.

[jevermeister]

Hm,
can I give my two cents here!?

I am working with PLC on my job and those Controllers always use fixed cycle times.
I do not understnad, why the cycle time has an effect on the level behavior if it is very short. imho this is not intended. A faster loop time should NEVER lead to worse behavior.
There should be algorithms that compensate that.
I fly a medium size Quad and switch from FPV to actions etup in seconds, it is not cool that I have to tune the cycletime and PID...

How is this handled in opther projects like rducopter or DJI?

Nils

[copterrichie]

@Jevermeister, and this is why I PID tune my main FPV copter with all of the gear installed and on. I once created a short routine to store two sets of PIDs in EEPROM but it was just too much trouble to keep updated when new versions of the MWC code was released. I have not had time to test this fixed Cycle time code, but I believe it is the way to go.

[Hamburger]

I do not understnad, why the cycle time has an effect on the level behavior if it is very short. imho this is not intended. A faster loop time should NEVER lead to worse behavior.
There should be algorithms that compensate that.
I fly a medium size Quad and switch from FPV to actions etup in seconds, it is not cool that I have to tune the cycletime and PID...

I have no substantial background on this. I was inspired to try the fixating of ct by some remarks about working rigs with 10ms ct.
We do not know what a short ct would be. Is our average 3ms long or short.
?
We do pid tuning to suit the avg. ct but how does this impact flying with the eventual spikes of higher ct?
I have no answer to any of this. I can say flying two copters with fixed ct to 5ms works ok for me.

We have just begun.

[Mis]

Hi.
I have little smaler code for fixed cycle time:

Code: Select all

  computeIMU();
  // Measure loop rate just afer reading the sensors
  do{
    currentTime = micros();
    cycleTime = currentTime - previousTime;
  }while (cycleTime < FIXED_CYCLE_TIME);
  previousTime = currentTime;

If you set FIXED_CYCLE_TIME to 0, compiler automatically remove not needed code. Setting it to some other value will hold the cycle time close to value (if possible).

[Hamburger]

Mis
Cool. Ca you submit? I am away from computer.

[crashlander]

Naive question/observation: that added cycle time could be used for additional sensor sampling/averaging and in that way we could directly get effect similar to LPF, GYRO_SMOOTHING, MMGYRO...?!

Regards Andrej

[Hamburger]

Yes.
But if you want to exit that at a fixed value (and not only after some point unknown later) it gets difficult to code