I just bought an FrSky Taranis for my quad copter and needed to get the Mavlink data up on the Taranis LCD telemetry display. So here is my solution using a Teensy3.1 as a converter between MavLink and the S.Port on FrSky X8R.
See attached file below...
yep still on ebay
Displaying the error codes could be really useful. Definitely worth checking out.
The yaw-angle should already be present via the heading-attribute? And having a nice looking arrow showing if you are traveling towards or away from the home position would be a nice feature. Depending on the number of steps you really need, you shouldn't need that many image-filesI think.
The Yaw angle might be different from the Heading :) and the Magnetic Heading can also be different from the GPS Heading :) :) and all different.....but in the end the Yaw might not be relevant, but Roll and Pitch are. At least to know how hard you're going to crash :)
I already have some nice looking Photoshopped 3D arrows for the Course to Home I believe that 8 should be enough (N,NE,E,SE,S,SW,W,NW). That part is already done including the calculation for the Course to Home. Because of those arrows I filled a bug on OpenTX that Bertrand has already closed - Lua error with BMPs
For the error codes I'm now looking at the Mission Planner sources to get some ideas....
I understand the gps-heading and the frame-heading/orientation. But what do you mean by yaw angle? I wasn't aware of any other angle in that sense.
That sounds reasonable. How many pixels are these arrows?
Yaw angle as reported by the Mavlink Attitude. I believe is the true angle <horizontal> that the frame is, which might not coincide with headings. Think of wind pushing the frame and the vehicle moving in one direction but pointed to other...
case MAVLINK_MSG_ID_ATTITUDE: //30
ap_accX = mavlink_msg_attitude_get_roll(&msg) * 180/3.1415; //value comes in rads
ap_accY = mavlink_msg_attitude_get_pitch(&msg) * 180/3.1415;
ap_accZ = mavlink_msg_attitude_get_yaw(&msg) * 180/3.1415;
the arrows can be any size. I've drawn them in Photoshop :)
At the moment regarding the HUD display I'm still undecided on HUD resolution.
My target is to get something large enough to be seen at a glance but informative enough, a bit like the HUD from Google Earth, problem is that we only have 212x64 pixels and if we push for larger more visible/useful size we waste a lot of screen estate....
Any update on a fix for Cells on 2.0.8?
I asked at OpenTX forum but still had no time to get a solution.
I believe others might have a solution now
The batteries problem
Thanks. I was able to get it working by adding the cell count as noted above.
FrSkySPort_SendPackage(FR_ID_CELLS,(temp >> 20) | (temp >> 8) | (ap_cell_count >> 4)); // Battery cell 0,1"
I have pushed the changes I have worked on to github:
- Acc X/Y/Z reports the average vibrations (difference between max/min) instead of actual accelerometer values.
- Reports gps-speed instead of hud-speed.
- Change how the code responds to tx telemetry requests. This fixes the missing cell/cells in the latest open-tx versions.
- Updated the cell detection to minimize the risk of detecting to many cells (unless the battery is low upon connection)
and changing the cell count inflight when the battery voltage drops.
- Changed the averaging for voltage/current to be more accurate to the voltage/current fluctuations. Hoping of increasing the
accurasy of the mAh-counter. Use FAS as both voltage/current source.
- Delays sending the voltage/current until the voltage reading through mavlink has stabilized. This should minimize the false
low battery-warnings upon model powerup.
I assume you're using
to debug ??
or other way?
I mostly use the built in serial monitor in Arduino actually.
Don't really like the arduino-ide, but since I only made small changes I haven't looked into any alternatives.
Working well for me so far. Would have saved me a lot of time yesterday if I had waited. Thanks!!!