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...

Views: 281280

Attachments:

Reply to This

Replies to This Discussion

Hi Paul.

     Thanks for the comprehensive reply .

   I have  been "out of the loop "  for some time how quickly things change.

I am using a inverter to get data directly from pixhawk into Sport.

the main reason for doing this was to save £20 on a teensy but the cost of craft and theory lua would cancel this out

arducopter 3.4  also seems to directly output "repurposed " telemetry.

I think this would be easier to use with a lua script with a few tweeks.

Thanks again for the information

Tim

There's a third option I'd love to see implemented here which is to adapt these lua screens to the raw frsky telemetry output from ardupilot.  The likes of the pixracer have a dedicated port for this frsky output and includes the cable, so really all you need is the lua scripts.  This would be a great addition to the arudpilot project, I think it's almost irresponsible to fly without these telemetry screens.

Paul Atherton said:

Tim,

The Teensy project is written specifically to provide Mavlink->SmartPort telemetry conversion, so only deals with the Pixhawk being configured to send out Mavlink over the telemetry port and so it is not designed as it stands to deal with the new passthru protocol. The new protocol would not actually require a teensy at all, but just a telemetry inverter, and by adding one of these and selecting the passthru protocol, as you suggest, the Taranis would see lots of new telemetry sensors, but unfortunately the LUA screens as they stand are not coded for these sensors, and to make this work, would involve a lot of research and coding, which I just don't have the time to do at this point. To be honest, this is of no practical use for my model setup in any case, as I use ULRS instead of FrSky Tx/Rx and I have the mavlink data sent over the ULRS radio link where I connect it into Mission Planner on the ground, but secondly I also have the mavlink feed on the ground connected to the teensy where it converts and feeds into the Taranis to provide the usual screens. So in my case sending down the passthrough protocol would be of no use as it would take away the Mavlink capability I would need for Mission planner.

If you wanted to understand the passthrough protocol to develop your own LUA screens then I would suggest looking into the Ardupilot code where I believe the protocol is documented. This protocol was written by the guys at Craft & Throry to allow their commercially available LUA screens to function, so maybe that solution would be better in your case if you really want to take the passthrough protocol route.

If you do develop something, please let us know on the forum as I would be interested in any progress.

Cheers and good luck, Paul 


@Paul what is the current best version to go with - is it your master branch with opentx 2.2.0-rc12, or best to stick with 2.1.9 for now?

I've got a lot of corruption with the status messages.  Unfortunately spending all my spare time on other projects at the moment so haven't had time to delve back into this one.

Hey Fnoop,

The 2.0 master is the best one for now. I tested this just over a week ago with 2.2.0-rc11 - I didn't realise that rc12 was out already as have been away on holiday. I'll test with rc12 this week.

Of course it works fine with 2.1.9 also.

I re-created the wav files in the project also. Before, the project provided only the TELEM folder (to be placed inside the OpenTx /SOUNDS/en folder) which contained the additional wav files required for status text messages to be called, but as these files were only provided with the choice of Ava or Samantha voices, it meant that if you had the OpenTx sound pack installed initially, then these additional telemetry voices would not match the OpenTx voices. So to rectify this, I now also provide customised OpenTx sound packs (with some additional voice files - both OpenTx 2.1 and 2.2v6 versions) so that you can have all sounds either in Ava or Samantha. I just checked and can see that in rc12, they have released yet another sound pack version (v7), so I will need to check the differences and fix any changes to the standard voice files that have been introduced.

Cheers, Paul

Hi Paul

I flew my quad yesterday W/ arducopter 3.4 and open TX 2.0... not sure what the triangular shaped thing is called on the far right in the main screen but anyway it works great except it managed to get almost %100 out of the screen. It does aim 'home' correctly. Any ideas?? Thanks

Richard, my solution is only provided for Opentx 2.1 and 2.2. The older Clooney82 repo has a 2.0 version. I wasn't involved in the project at that time Sorry.

I'm sorry my mistake yes 2.1.9   perhaps if I just waited it would have migrated back within the screen I haven't had time to try it again.... 

No worries Richard. I'll check this on 2.1.9 myself and see if I can reproduce the issue. Cheers, Paul


Richard Kennedy said:

I'm sorry my mistake yes 2.1.9   perhaps if I just waited it would have migrated back within the screen I haven't had time to try it again.... 

Tim,

I have attached a spreadsheet containing details of the telemetry sensors and values contained in each, which are produced by using the passthru protocol you refer to. Thanks to Luis Vale for providing these to me and allowing me to share here. Hopefully this will be of help in writing LUA script etc.

Best wishes, Paul

 
Tim Painter said:

Hi Paul.

     Thanks for the comprehensive reply .

   I have  been "out of the loop "  for some time how quickly things change.

I am using a inverter to get data directly from pixhawk into Sport.

the main reason for doing this was to save £20 on a teensy but the cost of craft and theory lua would cancel this out

arducopter 3.4  also seems to directly output "repurposed " telemetry.

I think this would be easier to use with a lua script with a few tweeks.

Thanks again for the information

Tim

Attachments:

Richard, I have tested this tonight, and I can get the arrow outside the box, but only under extreme circumstances - like when the latitude changes vastly during the flight - simulating the craft having flown 40+km. I do agree that the arrow should never leave the box by design so will attempt to have a look at this, but as this bit was written by someone with a much higher grasp of trigonometry than me, it could take some time for me to figure this all out. It would be good to know the details of the flight which resulted in your findings. Such as the lat/long and vehicle heading prior to arming, (I.e. the home position/bearing), and then the lat/long and heading when you saw the arrow out of the box. Any ideas?

Thanks, Paul


Paul Atherton said:

No worries Richard. I'll check this on 2.1.9 myself and see if I can reproduce the issue. Cheers, Paul


Richard Kennedy said:

I'm sorry my mistake yes 2.1.9   perhaps if I just waited it would have migrated back within the screen I haven't had time to try it again.... 

Well... as a matter of fact I did note that going with a stiff breeze I was going 60 mph with my quad. That's probably a bit faster than normal however not exceptionally unusual for a plane. Thanks for looking into it.  

Paul Atherton said:

Richard, I have tested this tonight, and I can get the arrow outside the box, but only under extreme circumstances - like when the latitude changes vastly during the flight - simulating the craft having flown 40+km. I do agree that the arrow should never leave the box by design so will attempt to have a look at this, but as this bit was written by someone with a much higher grasp of trigonometry than me, it could take some time for me to figure this all out. It would be good to know the details of the flight which resulted in your findings. Such as the lat/long and vehicle heading prior to arming, (I.e. the home position/bearing), and then the lat/long and heading when you saw the arrow out of the box. Any ideas?

Thanks, Paul


Paul Atherton said:

No worries Richard. I'll check this on 2.1.9 myself and see if I can reproduce the issue. Cheers, Paul


Richard Kennedy said:

I'm sorry my mistake yes 2.1.9   perhaps if I just waited it would have migrated back within the screen I haven't had time to try it again.... 

Richard, the arrow inside the radar box has nothing to do with speed. It is purely based on the change of lat/long (position coordinates from GPS) and change in bearing (Hdg) after the craft is armed compared to before.


Richard Kennedy said:

Well... as a matter of fact I did note that going with a stiff breeze I was going 60 mph with my quad. That's probably a bit faster than normal however not exceptionally unusual for a plane. Thanks for looking into it.  

Reply to Discussion

RSS

Groups

Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2017   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service