Page 1 of 1

Loop time optimization

Posted: Sat Feb 18, 2012 11:31 pm
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.

Re: Loop time optimization

Posted: Sun Feb 19, 2012 12:49 am
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

Re: Loop time optimization

Posted: Sun Feb 19, 2012 8:12 am
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.

Re: Loop time optimization

Posted: Sun Feb 19, 2012 2:16 pm
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.

Re: Loop time optimization

Posted: Sun Feb 19, 2012 3:09 pm
by Magnetron
This optimization will be in new release?

Re: Loop time optimization

Posted: Sun Feb 19, 2012 3:11 pm
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?

Re: Loop time optimization

Posted: Sun Feb 19, 2012 3:34 pm
by Magnetron
Excuse me Marbalon r568 is 20120203 version?

Re: Loop time optimization

Posted: Sun Feb 19, 2012 4:49 pm
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.

Re: Loop time optimization

Posted: Sun Feb 19, 2012 4:54 pm
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.

Re: Loop time optimization

Posted: Mon Feb 20, 2012 12:18 am
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 ...

Re: Loop time optimization

Posted: Mon Feb 20, 2012 7:35 am
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

Re: Loop time optimization

Posted: Tue Feb 21, 2012 12:17 am
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