EnuCoor_i and NedCoor_i units

[Fabien-B]

EnuCoor_i structures can be expressed in INT32_POS_FRAC or centimeters, and its not always clear which unit is used.
I think its a huge risk to introduce bugs.
I would suggest reserving this struct for INT32_POS_FRAC coordinates, and make a new structure EnuCoorCm_i if centimeters are needed, to reduce the risk of errors.

Does anyone have an other suggestion ?

Example were it can be found:

paparazzi/sw/airborne/subsystems/navigation/waypoints.c

Lines 280 to 285 in b2c7f87

	enu_of_lla_point_i(&enu, &state.ned_origin_i, &waypoints[wp_id].lla);
	// convert ENU pos from cm to BFP with INT32_POS_FRAC
	enu.x = POS_BFP_OF_REAL(enu.x) / 100;
	enu.y = POS_BFP_OF_REAL(enu.y) / 100;
	enu.z = POS_BFP_OF_REAL(enu.z) / 100;
	waypoints[wp_id].enu_i = enu;

[fvantienen]

I didn't know this problem existed. But seems like a good solution.
For me personally I prefer to do most calculations in float, since almost all autopilots can easily compute floats.

[gautierhattenberger]

Using float is mainly a matter of rewriting a lot of navigation, control and estimation code...

[fvantienen]

I was not meaning to really rewrite most of the code, but more if new code is made or code is refactored I don't mind anymore if it is only made using float's. Since it avoid's a lot of error's and mistakes with converting and precision etc.