Loop time optimization

Post Reply
marbalon
Posts: 107
Joined: Thu Aug 18, 2011 10:59 am

Loop time optimization

Post by marbalon »

Hi all devs,
In last days I'm working on baro code, but for a long time I have one idea. I found that in MWC code there are som functions called periodically like:

- RC idle in 50HZ
- getEstimatedAltitude() 40Hz
and some function that not to be called in every idle like:
- Baro_update()
- Mag_getADC()

So I enable LOG_VALUES, and start to analyze. At start I have idle in range 2700-4200 with four sensors ADXL345, L3G4200, MS5611, HMCL5883. Hmm quite big cycle time jitter. So I start to optimize my baro functions (yes, it wasn't optimized). So I get cycle time 2700-3600. Better but still not satisfied. So then I decide to add switch and call only one of above function in one loop. So I add this code:

Code: Select all

// ******** Main Loop *********
void loop () {
...
  static int8_t idle_idx=0;
 
  #if defined(SPEKTRUM)
    if (rcFrameComplete) computeRC();
  #endif

  //never call all function in the same loop - this increase jitter for this funtion, but less cycle time
  switch (idle_idx)
  {
    case 0:
      idle_idx++;
      break;
    case 1:
      idle_idx++;   
      #if MAG
      Mag_getADC();
      break;
      #endif
    case 2:
      idle_idx++;
      #if BARO
      Baro_update();     
      break;
      #endif
    case 3:
      idle_idx++;
      #if BARO
      getEstimatedAltitude();
      break;
      #endif
    default:
      idle_idx=0;
      break;
  }
 
  if (currentTime > rcTime && idle_idx == 0) { // 50Hz - only called when idle_idx == 0


Now I have a cycle time in range ~2700-2800 using all my four sensors! I ofcourse remove function called in this switch from other place.
In attached file you can find r568 with my patches for baro some extras, and this cycle time optimization.

I've made some test and fly with this code and everything seems to work fine but, I still learning this code so maybe I miss something.
What do you think Alex, Ziss, other devs?

Cheers,
Marcin.
Attachments
MultiWii.zip
(125.06 KiB) Downloaded 126 times

mr.rc-cam
Posts: 457
Joined: Wed Jul 27, 2011 11:36 pm

Re: Loop time optimization

Post by mr.rc-cam »

The general goal of short cycle times is to promote the highest sensor update rate. But reading a sensor every forth cycle is sort of like increasing its cycle time 4X. No doubt some models, sensors (and pilots) may not experience performance issues if the sensor data is not updated very often. But I think that it might be best to find other ways to reduce cycle execution time that does not reduce any sensor updates.

- Thomas

marbalon
Posts: 107
Joined: Thu Aug 18, 2011 10:59 am

Re: Loop time optimization

Post by marbalon »

Please look in to code, I only move to switch functions that don't need to fast updates, thanks to this gyro and acc can be updated faster.

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Loop time optimization

Post by Alexinparis »

Hi,

I'm agree, some tasks could wait for several cycle.
It's a good idea for time stability to ensure only one could be computed per loop.

Magnetron
Posts: 124
Joined: Tue Jul 05, 2011 4:32 pm

Re: Loop time optimization

Post by Magnetron »

This optimization will be in new release?

Magnetron
Posts: 124
Joined: Tue Jul 05, 2011 4:32 pm

Re: Loop time optimization

Post by Magnetron »

marbalon wrote:Hi all devs,
In last days I'm working on baro code, but for a long time I have one idea. I found that in MWC code there are som functions called periodically like:

- RC idle in 50HZ
- getEstimatedAltitude() 40Hz
and some function that not to be called in every idle like:
- Baro_update()
- Mag_getADC()

So I enable LOG_VALUES, and start to analyze. At start I have idle in range 2700-4200 with four sensors ADXL345, L3G4200, MS5611, HMCL5883. Hmm quite big cycle time jitter. So I start to optimize my baro functions (yes, it wasn't optimized). So I get cycle time 2700-3600. Better but still not satisfied. So then I decide to add switch and call only one of above function in one loop. So I add this code:

Code: Select all

// ******** Main Loop *********
void loop () {
...
  static int8_t idle_idx=0;
 
  #if defined(SPEKTRUM)
    if (rcFrameComplete) computeRC();
  #endif

  //never call all function in the same loop - this increase jitter for this funtion, but less cycle time
  switch (idle_idx)
  {
    case 0:
      idle_idx++;
      break;
    case 1:
      idle_idx++;   
      #if MAG
      Mag_getADC();
      break;
      #endif
    case 2:
      idle_idx++;
      #if BARO
      Baro_update();     
      break;
      #endif
    case 3:
      idle_idx++;
      #if BARO
      getEstimatedAltitude();
      break;
      #endif
    default:
      idle_idx=0;
      break;
  }
 
  if (currentTime > rcTime && idle_idx == 0) { // 50Hz - only called when idle_idx == 0


Now I have a cycle time in range ~2700-2800 using all my four sensors! I ofcourse remove function called in this switch from other place.
In attached file you can find r568 with my patches for baro some extras, and this cycle time optimization.

I've made some test and fly with this code and everything seems to work fine but, I still learning this code so maybe I miss something.
What do you think Alex, Ziss, other devs?

Cheers,
Marcin.

I will try it on dev 20111220, is it compatible or not?
I had noted that in your modification for baro on 20111220 you call Baro_Update() routine in getEstimatedAltitude()... is it optimized?

Magnetron
Posts: 124
Joined: Tue Jul 05, 2011 4:32 pm

Re: Loop time optimization

Post by Magnetron »

Excuse me Marbalon r568 is 20120203 version?

marbalon
Posts: 107
Joined: Thu Aug 18, 2011 10:59 am

Re: Loop time optimization

Post by marbalon »

Magnetron wrote:Excuse me Marbalon r568 is 20120203 version?

No it is newer version from svn repozitory. Please wait fo new release, this is not finished. Use less memory and CPU time but I think older works better. Need to check some things, and will release new version in main topic.

marbalon
Posts: 107
Joined: Thu Aug 18, 2011 10:59 am

Re: Loop time optimization

Post by marbalon »

Alexinparis wrote:Hi,

I'm agree, some tasks could wait for several cycle.
It's a good idea for time stability to ensure only one could be computed per loop.


Grate. I will try to keep this optimization when codding altitude hold, and will tell you feedback if something goes wrong.

Regards,
Marcin.

User avatar
shikra
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

Re: Loop time optimization

Post by shikra »

Looks good Marcin.
Faster updates - or more time to add in extra work for the 328.. My original wmp/nk works very well even at 6500 ...

ziojos
Posts: 11
Joined: Mon Feb 20, 2012 6:43 am

Re: Loop time optimization

Post by ziojos »

Ciao This is my first post on MultiWii Forum :)

I had this style of scheduling on JJ-copter (one of few Wii sensor AeroQuad since may 2010 ) and the loop is stable close to 6.5 ms whith WMP,NK, GPS,Ultrasonic,Compass.
IT was very nice to use the 3ms Wii sensor delay to make someting of usefull and to stabilze the loop

Actualy I have ported JJ-copter Mk4.0 to MWii 1.9 (ITG3200,BMA180,HM5883,MS5611, SR04, GPS MTK3329)

adding True Altitude Hold (BARO+Sonar).

Last week Baro Altitude Hold:
http://www.youtube.com/watch?v=D4Eq0mZkvwA

JJ-copter AQ Video Page ;) :

http://aeroquad.com/showthread.php?1268-JJ-COPTER-MK2-STABLE-MODE-(MEGA-Wii-GPS-Compass)

Ciao

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Loop time optimization

Post by Alexinparis »

I already saw some of your vids in the past.
Many of them make me think we can clearly improve the current alt hold feature in multiwii ;)
thank you for sharing your experience

Post Reply