New airframes

[dansmrcka]

• added config for m1200
• renamed t-drone config to m690
• modified the static frames selection
  • static_rplidar.py now includes allowed_frames list
  • it automatically searches for a configuration launch file in format static_tf_<airframe-name>_launch.py

[joonas-fi]

It's a bit problematic that the airframe configuration is part of the program code. That is to say, it's not nice to have to ship new software version in order to:

• change coordinates of fcu_to_rplidar or fcu_to_garmin
• add new airframe
• remove an airframe

I'd much rather extract the configuration outside of this software, in pseudo this could be in manifest:

{
	"Airframes": [
		{
			"Name": "holybro",
			"LidarParameters": {
				"Kind": "rplidar",
				"fcu_to_rplidar": "0, 0, 0.09, 0, 0, 0",
				"fcu_to_garmin": "-0.007, -0.05, -0.036, 0, 1.5708, 0"
			},
			"Notes": ""
		},
		{
			"Name": "rover",
			"LidarParameters": {
				"Kind": "rplidar",
				"fcu_to_rplidar": "0, 0, 0.09, 0, 0, 0",
				"fcu_to_garmin": "-0.007, -0.05, -0.036, 0, 1.5708, 0"
			},
			"Notes": "Lidar parameters the same as for holybro"
		},
		{
			"Name": "m690",
			"LidarParameters": {
				"Kind": "rplidar",
				"fcu_to_rplidar": "-0.078, 0, 0.0614, 3.141592, 0, 0",
				"fcu_to_garmin": "-0.20, 0, 0.0139, 0, 1.5708, 0"
			},
			"Notes": ""
		},
		{
			"Name": "m1200",
			"LidarParameters": {
				"Kind": "rplidar",
				"fcu_to_rplidar": "-0.15, 0, 0.09, 3.141592, 0, 0",
				"fcu_to_garmin": "-0.13, 0, -0.13, 0, 1.5708, 0"
			},
			"Notes": ""
		}
	]
}

Then we could just give as ENV vars these from manifest:

--env=AIRFRAME_FCU_TO_RPLIDAR=0,0,0.09,0,0,0
--env=AIRFRAME_FCU_TO_GARMIN=-0.007,-0.05,-0.036,0,1.5708,0

(just an example, of course fog-hyper would provide the correct ones based on selected airframe)

This would:

• remove the need to ship new versions of software to change the configuration.
• make the software simpler because right now we have six different launch files that govern how the software is launched. That's theoretically six different ways the software behaves (not just with respect to the parameters fcu_to_rplidar & fcu_to_garmin)

[mehmetkillioglu]

After the t-drone -> m690 link change is done, it could be merged

[joonas-fi]

After the t-drone -> m690 link change is done, it could be merged

I thought we had consensus that we should move airframe configuration to reside outside of the software?

I mean if this is not the perfect time to implement it then when is? I'd happily implement this at fog-hyper side, if we don't have time to design a file format we can first hardcode the airframe config registry into fog-hyper and use ENV vars to pass this data and then later revamp the design.

[mehmetkillioglu]

After the t-drone -> m690 link change is done, it could be merged

I thought we had consensus that we should move airframe configuration to reside outside of the software?

I mean if this is not the perfect time to implement it then when is? I'd happily implement this at fog-hyper side, if we don't have time to design a file format we can first hardcode the airframe config registry into fog-hyper and use ENV vars to pass this data and then later revamp the design.

I am working on it, the structure to work both with fognav, rplidar, and some other possible nodes. It requires some planning, both in fog_hyper and manifest. It will also ease up the parameter structure of fognav. I added some comments here about the possible ways in DP-8150. Feel free to comment and add ideas.

Meanwhile, we can continue with this to not block any further development on m1200 frame. Later, reworked version will be added.