paparazzi/paparazzi — Issue #101: General vehicle state interface
Author: flixr
Created: 2011-12-11 14:25:43+00:00
State: open
Labels: Airborne

A general state interface that holds all the most important vehicle states like position, speed, attitude, etc. for fixedwings and rotorcrafts alike would be nice. It should also do the appropriate coordinate and fixed/floating point conversions automatically and only when needed.

I started on this quite a while ago already, see [state.h] (https://github.com/paparazzi/paparazzi/blob/new-state-interface/sw/airborne/state.h) and [state.c] (https://github.com/paparazzi/paparazzi/blob/new-state-interface/sw/airborne/state.c) in the [new-state-interface] (https://github.com/paparazzi/paparazzi/tree/new-state-interface) branch.

Current status:

* Most of the state interface and needed conversions are done (e.g. UTM is still missing)
* You can set e.g. the position in any coordinate system you wish: ```stateSetPositionNed_i(pos_ned_i)``` to set the position in fixed-point NED coordinates
* If you need to read the position somewhere else in a different representation, simply call: ```stateGetPositionLla_f()``` and only then the LLA float position representation is calculated and returned on the fly. It's also only calculated once, until a new position is set.

There are however some open questions that need addressing before we go further:

* How to deal with the problem that a given representation can't be calculated or is not valid, e.g.
* something needed for conversion not initialized (e.g. LTP origin not initialized)
* simply no measurement of the state available (e.g. no airspeed sensor)
* state not valid (e.g. no 3d GPS fix, hence pos/speed not valid)
* Add extra functions to set multiple representations of the same state at once, or allow to set a state without marking the other representations as uncalculated?
* E.g. when the GPS already does the work and calculates several representations, why not use that instead of only setting one and doing the conversions again ourselves...
* We could get rid of the AHRS and INS interfaces and only have implementation specific structs that hold only the necessary data (e.g. fixed point in imu frame) and then just use the ```stateSetFoo_i(bar)``` functions to copy to the state interface where the other representations (e.g. float in body frame) will be calculated automatically on the fly when needed.
* more that I don't recall right now...