I’m working on in civil aviation. I flew in the cockpit of many aircraft like A320 B737 and my virtual pilot. Everything was going well when you decided to build a drone, but until I see the PFD… it frames (movment) very badly. All parameters move too much.
All parameters and animations (like speed, alt change) in a real airplane are smooth (like this video) PFD is better when connected via usb, but the parameters are very bouncing… everything gets worse when connected wirelessly. I know how wireless systems work packet frequency is slow so the screen looks like 5fps… But please add an animation to it so you can fill in the number of frames in between. I’m begging you, I get sick every time I see. @rmackay9@iampete
Well, it is not that easy. The update of PFD (HUD) is data driven, if the data comes in slowly then the update rate is slow as well. Adding animation adds delay to the display as well, and adds a lot of unnecessary load to the gcs computer.
Extrapolating is a possible solution, but this can lead to displaying invalid data, and even bigger jumps.
Real airplane displays are smooth because they got in a high rate.
If you have a good telemetry link then you can increase data rate, and get fluid update rate.
@prodha You are absolutely right.
This has very much to do with the fact that our telemetry is poorly (NOT) optimized for nice flight monitoring or PFD.
The telemetry is provided in many MAVLink “messages” - each “message” contains a set of values.
There are many such “messages” - and unfortunately, the control of which packets you need, at which rate - is far from granular.
The SRx_ parameters set a whole bunch of messages to a desired rate.
So: in other words: if you want for example attitude at 25Hz, then you need to have many other, less significant messages at this rate.
With a finer control of rates per packet, we could very well have 25Hz PFD data. But instead, we need to settle to lower refresh rate, because most of the link is saturated by data that could very well have been updated at 1Hz or less.
I would propose one of two solutions:
1: option to request rates mer message type.
2: a few new messages that would transmit all PFD data at high rate.