Hi all,
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...
Replies
If you have F.Port on your Rx, then no converter is needed now (of course updating Tx/Rx/FC).
Also, there are much better FC for as little as $20, like the OmnibusF4v3Pro.
https://discuss.ardupilot.org/t/frsky-bidirectional-telemetry-imple...
I guess because all of this is customized, that Taranis does not support the scaling for the raw data.
Thx for your help
Scot
Robert, the input to your scripts (even though the sensor is configured for kts in the sensors screen) will still be in m/s you need to do a translation in LUA to scale that to whichever scale you need.
Hmm, I do not see files as uploaded. See files in the below links if they do not show up in the post.
https://drive.google.com/open?id=0B_rKS7jwgyK3U29KdmFoaHlwUGs
https://drive.google.com/open?id=0B_rKS7jwgyK3dTZwMFVqX0ZjWEk
https://drive.google.com/open?id=0B_rKS7jwgyK3aC1LRXItc2twWTA
IMAG2527.jpg
IMAG2528.jpg
IMAG2529.jpg
The issue I have is not with the lua script. The issue I have is with the sensor data. I am fully configured for kts as my units of choice. The Lua dashboard you have is working accurately. But when I create my own dashboard and create alarms based on aspd and gspd sensors, they come through in m/s, even though I have them configured for kts. See screens which are attached. The scalling is missed for these sensors for some reason.
I will look over the docs again but I think this should have covered all of my scaling needs.
Robert, Glad you're finding the project interesting.
Are you aware of the configuration page which is part of the main lua script? The telemetry script has two screens. When you load it (long press on PAGE button) you see the main telemetry screen, but if you press the MENU button on the Taranis, then the script switches to the configuration screen. Press MENU again and it switches back. You can see a picture of the config screen in the second image on this wiki page https://github.com/athertop/MavLink_FrSkySPort/wiki/0.-Overview
In fact the screens are described in the WIKI using that link - would suggest you give that a read.
This configuration screen provides drop downs providing options which set all the required parameters - you don't need to tweak any code or manually write to any config files (or use the old offsets.lua mixer script any more) - this screen does it all. If you haven't yet gone into this screen, then default options are assumed - these default options are those you see when you first access the config screen for any model using the script. So if you change any option on that screen then all the settings on there are written to a config file which is loaded next time you load the telemetry script. There is one configuration file saved for each model using that script. So say if you have a model stored for a plane called "maverick" and a copter called "goose", you will have two config files - maverick.cfg and goose.cfg in /SCRIPTS/TELEMETRY/DATA on your SD card (make sure that path exists, along with all the other SD card contents as detailed in the wiki also), each holding your selected config for that model.
As regards your next post (two above, or is it three?) - yes I knew that the teensy provides the speed values in m/s and wrote the lua script to deal with this. Not exactly sure what issue you have with this - as a user, if you set kts on the telemetry sensor page (as discussed in the WIKI which is the default unit for newly detected GSpd and ASpd sensors) you should have no issues at all. OpenTx seems to be coded to expect the incoming data in kts, so by selecting kts as the sensor it does no scaling on the value sent from the teensy (or FrSky GPS/Airspeed sensor), so the LUA script expects the value provided by the sensor to be m/s (which it will be even though the sensor is configured for kts) and it provides scaling based on this m/s input.If you choose any other unit against sensor config then this is scaled by OpenTx (it assumes the incoming value is in kts and scales this to fit the selected unit) and this messes things up for the LUA script (which like I said assumes that incoming number to be m/s). So just leave that detected sensor alone, choose the unit format you want to appear on the LUA telemetry screen and that should be it! There's no smoke an mirrors honestly! Its all documented in the WIKI - see the link some paragraphs above) and the wiki documents the code in my repo, so make sure you're not using the older Clooney82 code from his repo (even Clooney is using my version of this code now :-)
As regards AoA - i'm not really interested in developing this, but feel free to fork the repo and have a go yourself - that's the beauty of Open Source code after all! Just for info AoA and sideslip estimation was added in Plane 3.8, and I believe this data is available in Mavlink. See release notes here: https://github.com/ArduPilot/ardupilot/blob/master/ArduPlane/releas...
Cheers, Paul
On a side note about the AoA question, I can see that the data flash logs do have an AOA data set. I am unsure how it is calculated or how good the data is. There are lots of fluctuation probably due to vibration but you can see it creep up as the plane slows or in turns. It would be nice to have data like this to sound a stall warning. I have no hardware on my plane for measuring AoA. For now, I am just using the calculated airspeed to alert me when a stall might be coming. Not perfect but better than nothing and good for helping me shoot consistent landing approaches.
Cheers
Scot
I want to walk back the statement that your code is mathematically correcting the error. That may not be true now that I have a chance to think about it. it is possible that the person who coded this knew that the data is coming over in m/s regardless of how Taranis is calling it. The script code does indicate that the units being sent over are m/s. There is a problem in the sensor code on Taranis where they use the wrong units. That is a mistake in someone's code. It should be an easy fix for someone familiar with the code.
So I should make a change to my models configuration? What should I set the speed to?
return {["speedUnits"] = 2,["altUnits"] = 1,["apType"] = 1,["offsetmah"] = 0,["offsetwh"] = 0,["whCap"] = 0,["armGvar"] = 0}
If I change this, will this impact the other customized lua dashboard that goes along with this tool? I do not want to fix one dashboard to corrupt another.
I am sure this is a coding issue as you stated as much. They are sending 'm/s' over for speed but labeling it knots in the sensors on Taranis. My impression is as much too. It seems that somehow your code mathematically corrects that mistake for the customized lua dashboard only, leaving the raw sensor with the unit error. It seems proper to fix the raw data in the code so it can be used for future purposes without having to code in a correction after the fact.
-
1
-
2
-
3
-
4
-
5
of 186 Next