Add VFR_HUD info

[maruina]

I'd like to add the support for all the info you can find under VFR_HUD:

• airspeed
• groundspeed
• heading
• throttle
• climb

I have a PR ready with a new class, HUD. If you think it's better to add these as vehicle's attributes, I will change my code and submit a PR.

[hamishwillee]

Well, airspead, and groundspeed are already in the vehicle class. I think that velocity gives you the three elements for a heading (or were you thinking something else)?

What is the climb? Pitch angle? Is this something that you can get from Vehicle.attitude? Or again, is it an element from the velocity value?

For throttle, are you after the current channel value? This can be set using channel_override and default values (I think the throttle is channel 3). Are you just trying to get it, or set it? My concern here is that generally people shouldn't be setting throttle (or any channel_override), but instead using commands like takeoff and the change speed messages (in AUTO).

My general thoughts are:

• These are vehicle-specific parameters, so I would expect them to be accessed through the Vehicle (what is the value of a new class here?)

@mrpollo - thoughts?

[maruina]

• The heading is where the copter is looking: it's an integer between 0 and 360 where 0 is the north. I'm using it to show the heading of the drone on google maps and it's very useful.
• The throttle is the current throttle setting in integer percent (0 to 100), and it's useful to have a quick reference.
• The climb rate is in meters/second

Since I wanted to add some attributes and they are all grouped under the same mavlink message, I thought would have been useful to have all of them under the same class like Attitude, Battery and Location, but maybe this is too much opinionated :)

[hamishwillee]

Hi @maruina Thank you for the explanation. I guess this is kind of a "philosophical" question - Python tends to promote just one way to do stuff, and having separate classes duplicates information. On the other hand, if the aim is to provide a nice wrapper for sending MAVLink commands, then it makes sense to map the MAVLink command structure.

Thinking about it I'm not sure which is better design. Having the information as vehicle attributes is only a little bit more obvious than having the vehicle own a HUD object to access the information. Deciding that we'll always extend the vehicle by adding an attribute that maps to the command type (like HUD) would significantly reduce the work in thinking about how the architect changes in future.

I don't know which philosophy @mrpollo subscribes to :-) Lets see. Thanks for your patience.