MavLink_FrSkySPort
MavLink_FrSkySPort copied to clipboard
Clooney82
Support realtime ekf/vibe monitor
ala https://github.com/diydrones/apm_planner/issues/779
also incorporate dynamic messages/alerts from ekf
a vibe monitor is really great. this inform you if something goes wrong on the structure side of the model. "extended kalman filter" warnings are hard to interpret. this need an good translation that non scientists or non engineers understand what goes wrong:)
Although I like (and use) the EKF and Vibe monitor, I believe we might easily overload the data link from the FrSky telemetry. For the EKF we need 3 states (Red/Yellow/Green) per monitor (Velocity, PositionH, PositionV, Compass, Terrain), and the Vibes are being parsed already from MAVLINK_MSG_ID_RAW_IMU and encapsulated on the FrSky avg vibration AccX,AccY,AccZ.
I'll have to check if the VIBES display new to MP and APMPlanner is also from the same Mavlink msg.
It still would be required (to be on par with MP) the Clipping of the Vibes per IMU (up to 3) and the 10 EKF flags (ON/OFF).
Most of the work is finished on 3.3, and unless something weird comes in testing this week expect the release shortly :)
If only the 2.1.3 bugs from OpenTX would also be sorted for a 2.1.4 release :)
The dynamic messages either from the EKF or from other sources, present a different challenge for a parser. My suggestion would be to disregard the dynamic part of the message and just send down the fixed part, like the warning of having only x GPS satellites and needing 6, the FrSky message would be simply "not enough GPS satellites"
this point something i am thinking about a while. currently we transmit accelx-z via sport on acc sensor. but imo we do not need them on taranis. if we need a vibe monitor on taranis, all needed math is calculated on average.ino. we can extend the math to report a little bit more infos. so we can use the three slots from acc sensor for more things. maybe first to send vibration infos. we can add 1-3 bits to carry different infos. bit 1 can hold the direction which produce a lot of bad vibes:). also with simple fft we can estimate an frequency. maybe send this on bit2 and on bit3 we can send the amount. accy and accz can also used for example ekf things. in moment teensy3.1 is very idle to do more math ore parsing messages. we also have a lot of mem free to add more messages.
/g wolke
We don't need to "encapsulate" more info on the existing sensorID's. With 2.1.x we can define new sensorID's. These tables were a proposal:
The next messages have the tables, GitHub freaked out when I pasted them here :)
Some already exist on the FrSky "standard" telemetry, but these were a list of "nice to have" on FrSky
Vibes are from rawimu accel but heavily processed, as described here: http://copter.ardupilot.com/wiki/common-measuring-vibration/ It doesn't make any sense to duplicate the algorithms on the teensy, but to pluck the VIBE messages from the FC stream instead. We also get clipping data as a bonus, which I don't think can be calculated from existing data. Basics implemented in https://github.com/Clooney82/MavLink_FrSkySPort/commit/27c3bc46b355669d03bf2a200547df4eaf680770
Please push new features to s-c-l-v-rc-opentx2.1-next branch. We should first get a stable version (Version 1.6) before implementing new features (Version 1.7).
