reoganize main loop /timed events?

[Hamburger]

Do we stand a chance to restructure the main loop and the handling of timed events?
It seems a fixated frequency for sensor readings and outpu updates would increase smoothness/stability?
So if this could be tied to an interrupt? Maybe not the actual sensor readings and computations but the triggering?

It is not really my field of work but the current implementation has grown over time and maybe could use an overhaul?

[jevermeister]

+1

[Sebbi]

1) The fixed loop time would need to be high enough so nothing can disturb it (= needs more time)
2) I only noticed changes in smoothness/stability when the loop time is changed. For example from 3000 µS to 7000 µS ... it was smoother with the same PID values, but a change of the PID values should result in the same smoothness with a loop time of 3000 µS. The sensor algorithms shouldn't be affected by different loop times, since they make use of the measured loop time to calculate new values ... the PID controllers don't :/
3) Burning CPU time doing nothing is always bad I like the MultiWii approach of doing everything as fast as possible.

[Hamburger]

I was under the impression that a higher but stable loop time was better than a slightly lower one with intermittent high spikes.

[jevermeister]

Hamburger,

I think timecops way is the right one. Imho the 8bitters are for casual use and the current software seems good enough.

I think the future really is 32bit :-/.
Altouh I realy like my Flyduino!

But nevertheless, it is worth a try to reorganize, count me in if you need assistance.
Nils

[Hamburger]

I will continue to not engage in the 8 vs 32 bit debate. When it is time to move we will move.
Regardless I think it is a good thing to improve on the handling of timed events, if it is considered worthy. Else we will do the same 'wrong' handling, only faster on faster h/w. If it is considered fine please tell me.

So
- analyzing rx inputs for stick combo @ 50Hz proven as sufficient
- gyro reading
- acc reading
- computeImu
- other sensors reading round robin and compute flight influence

For most I have no idea what would be desirable and possible.

[pm1]

the PID controllers don't :/

Exactly. The constant time would be fine for IMU calculation and writing output to motors. If you make this part in a constant interval, let's say to 5ms, you can put everything else in a loop and do it as fast as you can (or better, as fast as you want!).

I think, the whole timing should be more predictve. If you read the code for the baro at the moment, you would think, that it outputs a new value at every 20 ms. The reality is 70 ms+. It might be ok, that this is enough, but I would like to *know* it. Then you don't need 10 array elements for averaging the baro values, when you know, that you have only 3 unique values in 240 ms...

[copterrichie]

This conversion is remaining me of the olden days of multitasking/time-sharing. It is time to upgrade.

[Hamburger]

You mean we need an underlying os and use true multitasking?
Even if that happened we should spend some effort on analyzing which timing constraints we consider important.
Or else you have to use brute force to overcome conceptual weaknesses.

[ReadError]

Wouldn't it make more sense to invest time in a platform that is future proof? I really appreciate the project and continue to use the Arduino code as well, but it would make much more sense to spend keystrokes on something that has potential above and beyond what the AVR/Arduino is capable of today. (Granted, I would like to see a 32 bit board with a bit more IO options if that route was chosen, maybe an F4) ((Also, Arduino has an ARM processor coming out here shortly which should use the Arduino IDE, not sure if the code is compatible))

[copterrichie]

You mean we need an underlying os and use true multitasking?
Even if that happened we should spend some effort on analyzing which timing constraints we consider important.
Or else you have to use brute force to overcome conceptual weaknesses.

Hamburger, I am not advocating investing more time in redesigning the present firmware to incorporate true multitasking. What we really need to do is look to the future as previous stated, I heard there is a 32bit Arduino in the pipeline, not sure if it will be able to use the same code, but things are changing and changing fast.

[Sebbi]

It will use the same Arduino code, but direct use of hardware wont port so easily. But nothing that could'nt be addressed with more ifdefs

End of october is the date for Arduino Due ... I hope someone builds something that we can stick on our copters ...

[Hamburger]

It will use the same Arduino code, but direct use of hardware wont port so easily. But nothing that could'nt be addressed with more ifdefs

End of october is the date for Arduino Due ... I hope someone builds something that we can stick on our copters ...

What exaxtly do you have in mind?
Ignore conceptual sbortcomings in current code and run bigger hardware?
Abandon current hardware support and move to new start with software rewrite?

[copterrichie]

Just my two cents here, NO, never abandon the 8bit, maintain it with bug fixes and minor upgrades but for anything more advance, an upgrade is required.

[pm1]

... not sure it will be able to use the same code, but things are changing and changing fast.

I really wish, this will *never* happen. Porting this ifdeffery and avoiding any structured code 1:1 to any 32 bit platform gives you only the exactly the same problems without more or less any advantages. If you want to make a step further, you will have to cut backward compatibility.

[copterrichie]

I really wish, this will *never* happen. Porting this ifdeffery and avoiding any structured code 1:1 to any 32 bit platform gives you only the exactly the same problems without more or less any advantages. If you want to make a step further, you will have to cut backward compatibility.

BUT, what about all of the existing hardware out there?

[pm1]

Btw. I just figured out, what costs the biggest delay: Reading a new GPS message from the serial interface with the SerialRead, which only can read one byte at a time. It reads (ublox) up to 165 bytes at once, which costs about 5000 us!!!! i guess, nmea will read a few more...

[ReadError]

Hamburger,

Come on #multiwii (freenode) to take this realtime, many folks on there would like to speak with you

[pm1]

BUT, what about all of the existing hardware out there?

Forget it! There will be only bug fixes there. The mostly used processor I guess, is the 328P. Even now you cannot use new functionality like GPS (ok, I have a i2c nav board too..). The only processor, which is theorectically prepared for new versions, is the mega2560. But why do you want support it? New boards are in the 50 $ range...

[Sebbi]

It will use the same Arduino code, but direct use of hardware wont port so easily. But nothing that could'nt be addressed with more ifdefs

End of october is the date for Arduino Due ... I hope someone builds something that we can stick on our copters ...

What exaxtly do you have in mind?
Ignore conceptual sbortcomings in current code and run bigger hardware?
Abandon current hardware support and move to new start with software rewrite?

I'm just curious about the new Arduino hardware. For both copter/plane use and other tinkering ... tried to get my hands on one of the Google Android ADKs 2.0, but couldn't ... they are already using the Due for that one

As for the path MultiWii is going: I see no reason why algorithms and how MultWii works couldn't be ported to a different platform (see baseflight). A rewrite would probably be the logical way, but that costs time. So more ifdefs like with the Leonardo and Mega boards should be ok for then (Due still not out).

[copterrichie]

Forget it! There will be only bug fixes there. The mostly used processor I guess, is the 328P. Even now you cannot use new functionality like GPS (ok, I have a i2c nav board too..). The only processor, which is theorectically prepared for new versions, is the mega2560. But why do you want support it? New boards are in the 50 $ range...

I agree with you BTW.

[Magnetron]

Forget it! There will be only bug fixes there. The mostly used processor I guess, is the 328P. Even now you cannot use new functionality like GPS (ok, I have a i2c nav board too..). The only processor, which is theorectically prepared for new versions, is the mega2560. But why do you want support it? New boards are in the 50 $ range...

I agree with you BTW.

I agree also.
Why we don't concetrate on mega 2560: more resources, more memory, multi-serial, more i/o.
I have one mega2560 on an hexacopter, and I would to buy another one for a new quad.
I think arduino is adeguate and multiwii firmware has not reached it limits. So we must optimize code!

Main loop time is one target: we must optimize it to permit a deterministic behaviour.
I think one goal is to know really all the time for all tasks independently so we can write some code like this to know that time:

Code: Select all

 } else { // not in rc loop
    static uint8_t taskOrder=0; // never call all functions in the same loop, to avoid high delay spikes
    switch (taskOrder++ % 5) {
      case 0:
        #if MAG
          cycleMag=currentTime;  //---------------------------------------------
          Mag_getADC();
         cycleMag=currentTime-cycleMag;  //---------------------------------------------
        #endif
        break;
      case 1:
        #if BARO
         cycleBaro=currentTime;  //---------------------------------------------
          Baro_update();
         cycleBaro=currentTime-cycleBaro;  //---------------------------------------------
        #endif
        break;
      case 2:
[...]
  }

So I think that more operation can be executed at the same time if the total time is < than rcTime (main loop scheduler for rc time).
Another way is to execute a time interrupt for execute some operation like PID, so in that case time is very important.
But I think that sensors like gyro + acc must be readed at real-time, every cycle and every cycle must be executed the data computation.
Sebbi is on the right root to obtain same extra results...

[Sebbi]

I tried to come up with a "fix" for the main loop taskOrder switch statement. Only desk-tested yet, but seems to be much better, since it doesn't waste cycles if sensors arent there or functions in the case-statements didn't do anything.

https://github.com/sebastianherp/multiw ... roved_baro

[pm1]

deleted

[pm1]

Why we don't concetrate on mega 2560: more resources, more memory, multi-serial, more i/o.

Why this step? If you concentrate on one processor, why not a much faster one. A lot of code is already ported to STM32 by timecop. A nice guit to compile the whole thing is there, too...

[copterrichie]

Why not a Raspberry or an embedded Linux system? There are just too many options available today. With this said, we should narrow the choices down to three, then make a selection.

[pm1]

Why not a Raspberry or an embedded Linux system? There are just too many options available today. With this said, we should narrow the choices down to three, then make a selection.

A Raspberry as controlling system is fine. But you need realtime and lots of I/O pins

[copterrichie]

Why not a Raspberry or an embedded Linux system? There are just too many options available today. With this said, we should narrow the choices down to three, then make a selection.

A Raspberry as controlling system is fine. But you need realtime and lots of I/O pins

That is very true and the Mega has them but only 8bit. I think it is the Duo that is due out at the end of the month and is 32bit. We will see.

[copterrichie]

P.S. It truly will be interesting to see if Baseflight can be ported over to the Duo.

[Magnetron]

I tried to come up with a "fix" for the main loop taskOrder switch statement. Only desk-tested yet, but seems to be much better, since it doesn't waste cycles if sensors arent there or functions in the case-statements didn't do anything.

https://github.com/sebastianherp/multiw ... roved_baro

I think your code is a good idea, but I think that it can be optimized. What do you think about this:

Code: Select all

[...]
  } else { // not in rc loop

        #if MAG
          static uint32_t magTime = 0;
          if( currentTime > magTime ) {
            magTime += 66666; // 15 Hz (HMC5883 isn't setup faster)
            Mag_getADC(); // avg 21 µs, max 350 µs (HMC5883)
        #endif

        #if BARO
        if( currentTime > baroTime ) {
          baroTime += 25000; // 40 Hz
          getEstimatedAltitude(); // ~280 µs to calculate altitude (EstAlt) from pressure, 650 µs for the whole function
        #endif

    static uint8_t taskOrder=0; // never call all functions in the same loop, to avoid high delay spikes
[...]

In this case baro and mag was not in task switch statement and can be executed independently scheduled only by time (and compiled code prevents some bytes...)

[Sebbi]

As mentioned by Alexinparis in another thread, the task switch statement ensures that only one long duration task is executed in every cycle. In you code example there could be cycles where mag, baro and GPS are all executed and cycletime would be a lot higher than normal.

[Magnetron]

As mentioned by Alexinparis in another thread, the task switch statement ensures that only one long duration task is executed in every cycle. In you code example there could be cycles where mag, baro and GPS are all executed and cycletime would be a lot higher than normal.

Yes my routine was example only - can be possible to determine what task must take place first and shift next task to next cycle using task switcher. The idea is to avoid emply task cycle also.