Re: [Paparazzi-devel] Suggestions

[Felix Ruess]

Hi Antoine,

just came back from 2 weeks of vacation and hence didn't answer earlier...

I've been using Paparazzi's control laws (5.0.0) as benchmark and while doing so, a couple of things bugged me that i though i might share:

 Thanks!

For rotorcraft, it wasn't too hard to isolate control laws except for minor details:

 

  sw/airborne/firmware/stabilization/stabilization_attitude_rc_setpoint.c pulls autopilot_mode, guidance_h_mode, transition_theta_offset

Not nice indeed, patches welcome... also added an issue about it so we don't forget: https://github.com/paparazzi/paparazzi/issues/599

   

  USE_FMS is only used in sw/airborne/firmwares/rotorcraft/guidance/guidance_v and nowhere else, it could probably be removed

 Jep, removed in master.

   sw/airborne/firmwares/rotorcraft/guidance/guidance_v.c includes nav... that seems to be backward

Yes, it is backwards... just like in a couple of other places where the setpoint values are read from a global var of a "higher" subsystem instead of calling a function to set the setpoint in the "higher" system (in this case nav).

I guess a better solution would be get rid of GUIDANCE_V_MODE_NAV, GUIDANCE_V_MODE_RC_CLIMB, etc. and only have 3 modes in the end regardless of where the setpoint is coming from:

- GUIDANCE_V_MODE_MANUAL|DIRECT: direct throttle setpoint

- GUIDANCE_V_MODE_CLIMB|SPEED: vertical speed setpoint

- GUIDANCE_V_MODE_ALT|POS: altitude (vertical pos) setpoint

And then set the setpoints according to vertical_mode in nav_run if in NAV mode...

In the end we should revisit the complete (autopilot/guidance) mode system anyway, but no one volunteered for this bigger task so far (lack of time).

Or do you have any other ideas?

For fixedwing, it was much harder, the weight of history is being heavily felt...

    

  firmwares/fixedwing/stabilization/stabilization_attitude.c includes both "autopilot.h" and CTRL_TYPE_H (which is... the type of vertical guidance and can be either  guidance_v.h,  guidance_v_n.h or energy_ctrl.h)

Jep, complete fixedwing control loops need refactoring and cleanup... also a bigger task...

Patches/pull requests very welcome!

 

  firmwares/fixedwing/guidance/energy_control get its' accelerations directly from imu, maybe it would benefit from using the state interface

Currently acceleration can only be read in "fixed" world coordinates from the state interface: http://docs.paparazziuav.org/latest/group__state__acceleration.html

Also it is not actually set with all the INS implementations (e.g. not with the fixedwing ins alt_float).

I'm not sure if it really makes sense to add acceleration in body frame to the state interface, as we currently don't have any filters estimating it (the INS subsystems estimate accel in world frame).

But maybe it would make sense to read the acceleration in NED from the state interface and rotate it to body frame? Or even add this as a get function to the state interface?

@Christophe, you wrote the energy_control, what do you think?

 

  it also uses "launch" and "kill_throttle" from autopilot.h. Shouldn't those be part of state? (at least launch, which is the airborne status of the vehicle and is called in_flight in the rotorcraft version)

I guess it might make sense to add an airborne status to the state interface to replace launch and in_flight.

The question then is of course if a boolean airborne flag this is enough for the state interface (and other states like motors_on, takeoff, landing, should be handled in separate state machines).

I'll stop here for now. Let me know if you're interested in more

Please keep it coming ;-)

Cheers, Felix