attitude lock mode?

[rubadub]

I searched around, but couldn't find anything relevant, or perhaps I missed it.

Is there an 'attitude lock' flight mode in MW? i.e., releasing the sticks will hold copter's attitude (Roll/Pitch/Yaw angles all held fixed). I'm not talking about HORIZON either. I want the ability to set the copter's attitude and have it locked into place until I decide to change it. I guess this could be a precursor to a full-blown 'GPS MODE' similar to NAZA's.

It seems like it would only require testing of the stick inputs, and locking the current RPY angles. Not sure if it would require separate 'lock PIDs' or if the standard ones would be enough. Also, not sure if I'm missing any obvious gotcha's/caveats on getting this to work practically & without causing a high crash probability.

Any thoughts or advice on how this could best be implemented?

[Hypermobile]

Try:
Angle + GPS hold(Position Hold) + Baro (altutude hold)+ Mag (head hold)

[rubadub]

Try:
Angle + GPS hold(Position Hold) + Baro (altutude hold)+ Mag (head hold)

thanks, but that's not quite it.
ANGLE will try to level the 'copter based on the calibrated ACC values and ACC trim.
BARO is alt hold, which isn't really what I'm referring to.
MAG *can* be part of the equation, assuming that there's a mag sensor.

ATTITUDE should rely on ACC angles, and, optionally, MAG angle.
If, for whatever reason, you have a 'copter that isn't perfectly balanced and tends to droop, or if you have a slight side wind blowing, or if you simply want to hold a specific attitude (such as a slow forward drift), then, with attitude lock, you can manually level & position the craft with your desired attitude/angle of attack, and have it held in place.

[happul3]

Wouldn't angle mode do what you want if you use pitch trim on the transmitter to set desired attitude? Alternatively, you should be able to trim ACC while airborne, which gives the same net result (I never tested that functionality myself, though).

[EOSBandi]

Think a minute about what ACRO (GYRO) mode is doing...
You control the angular velocity by the sticks. And when you release the stick the angular velocity become zero, and the copter holds the current angle (either pitch or roll). Add MAG mode for holding YAW and there you are....

[rubadub]

Ideally, yes, that's true... but, in the real world, if the copter drifts slowly, the gyro's won't detect it.
Angle should be locked with data from acc sensor for it to be a true attitude lock.

[crazyal]

this describes it pretty accurately: https://github.com/TauLabs/TauLabs/wiki ... s#axislock
probably someone (not me) could even copy/adapt the taulabs controller to use in multiwii.

[rubadub]

this describes it pretty accurately: https://github.com/TauLabs/TauLabs/wiki ... s#axislock
probably someone (not me) could even copy/adapt the taulabs controller to use in multiwii.

yup, there you go, that's what I was referring to. It even states that it gives a more locked-in feel.

The implementation would be simple, you basically just need to apply the same concept/algorithm as in MAG mode wherein you save the angles upon activation, and update them depending on stick inputs. The ANGLE code could be used but adjusted so that it holds a specific angle instead of the 'zero' angle for auto-level.

I guess this ATTI mode could exist between ACRO and ANGLE/HORIZON...

[rubadub]

some mock-up code...
Multiwii.cpp

Code: Select all

//line 96
  #ifdef ACC
     "ATTITUDE;"
  #endif

//line 150
  #ifdef ACC
     20, //"ATTITUDE;"
  #endif

//line 183
#if ACC
int16_t attilock[2];
#endif


//line 976
    if (rcOptions[BOXATTITUDE]){
        f.ANGLE_MODE=0;
        f.HORIZON_MODE=0;
        if (!f.ATTITUDE_MODE) {
            attilock[ROLL]   = att.angle[ROLL]; 
            attilock[PITCH] = att.angle[PITCH];
           f.ATTITUDE_MODE = 1;
        }
   } else {
        f.ATTITUDE_MODE = 0;
      }

//line 1175
  #if ACC
      if (f.ATTITUDE_MODE && (abs(rcCommand[ROLL]) >70 || abs(rcCommand[PITCH]) > 70)  {
         attilock[ROLL]=att.angle[ROLL];
         attilock[PITCH]=att.angle[PITCH];
      } 
  #endif


//line 1249
    if (f.ATTITUDE_MODE) { // attitude lock mode
      //what happens if att.angle[i]==attilock[i]? is P-term overloaded with 'rc' value again?
      errorAngle         = rc - att.angle[axis] + attilock[axis];   
      //this is from ANGLE, is it ok in this context?
      errorAngleI[axis]  = constrain(errorAngleI[axis]+errorAngle,-10000,+10000);
      //again, this is from ANGLE, should it be ok in attitude lock?
      PTermACC           = ((int32_t)errorAngle*conf.pid[PIDLEVEL].P8)>>7; 
      ITermACC           = ((int32_t)errorAngleI[axis]*conf.pid[axis].I8)>>12;   //is this ok?

      //not sure about this, prop probably needs to be removed???
      ITerm              = ITermACC + ((ITerm-ITermACC)*prop>>9); 
     //same as above, not sure about prop factor in this context
      PTerm              = PTermACC + ((PTerm-PTermACC)*prop>>9);
    } else if (f.ANGLE_MODE || f.HORIZON_MODE) { // axis relying on ACC

^^^ not sure about the PID math in the last section above. Someone with more experience with this stuff will need to take a look at that. Mainly, I'm not sure if the angle addition sign convention is correct (is it "att.angle[axis] + attilock[axis]" or "att.angle[axis] - attilock[axis]"?), and I'm also not sure if " ITermACC = ((int32_t)errorAngleI[axis]*conf.pid[axis].I8)>>12;" looks ok (just modified the existing ANGLE code, so the >>12 bitshift might be too much).

types.h

Code: Select all

//line 82
  #if ACC
  BOXATTITUDE,
  #endif
  CHECKBOXITEMS
};

//line 120
  uint8_t HORIZON_MODE :1 ;
  uint8_t ATTITUDE_MODE :1 ;  
  uint8_t MAG_MODE :1 ;

Protocol.cpp

Code: Select all

//line 374
     #if ACC
       if(f.ANGLE_MODE)   tmp |= 1<<BOXANGLE;
       if(f.HORIZON_MODE) tmp |= 1<<BOXHORIZON;
       if(f.ATTITUDE_MODE) tmp |= 1<<BOXATTITUDE;
     #endif

not sure if I missed anything else or if I made any obvious, stupid mistakes.Please let me know if so...
Assuming that it works, does anyone have a beater/test quad that they'd be willing to test on?