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
hi manuel,
the README.md at https://github.com/rotcehdnih/Mavlink2Frsky give you the answer. the main difference is that a pro mini have only one serial port. and this fork use software serial to get the two needed serial connections. in this case the s.port serial is the software serial and is connected to pin 9 on pro mini.
you cannot compile the teensy code for a pro mini. this will fail. but you can use other telemetry scripts with the hector pro mini firmware. for example laves telem1.lua script ore others.
/g
wolke
Hi Wolke,
I know that we cant compile teensy code for a pro mini, that's why I've changed the code to be similar to Hector's code (his code compiles for pro mini, but I want the features of the Luis Vale Gonçalves's version!)
I cloned this version ( https://github.com/lvale/MavLink_FrSkySPort ) and began to change just the MavLink_FrSkySPort.ino ,
you can see what i've changed here : http://pastebin.com/LbpnEekK
It was just the Serial, so it can work with pro mini (like the Hector's one does)
but the function _MavLink_receive() is somehow getting stuck, because i dont receive any packets from apm
however, if i change just that _MavLink_receive() to the one that Hector has on his code, it starts to receive packets and works
http://pastebin.com/VhH5t31u (this is the MavLink_FrSkySPort.ino of Luis Vale Gonçalves, and i just changed it to Serial and put the Mavlink receive function of Hector... it receives data!!! )
tiptop,
you got it work:). that is great.
I'll reply here too since I finally got all working flawlesssly including network :)
I'm wondering though (havent been able to test yet, rain rain and rain) is the code for the teensy updated for the ARM = quad startpoint or is it as it first was, first lock = starting point?
Not 100% unfortunately :/
this is the part of the _MavLink_receive() function that is refusing to work:
case MAVLINK_MSG_ID_STATUSTEXT: //253
mavlink_msg_statustext_decode(&msg,&statustext);
ap_status_severity = statustext.severity;
ap_status_send_count = 5;
// parseStatusText(statustext.severity, statustext.text);
break;
if i uncomment that parseStatusText function, the entire_MavLink_receive() function stops working... no blinking led no nothing. But i cant find any logical reason for that
Also, for some reason I only get telemetry data displayed on the Taranis after a minute or two after connecting the battery to the quad , any reason for this ?
I followed the same steps you did getting Luis Vale Gonçalves's version going on the Pro Mini by using the SoftSerial implementation Hector provided. Had exactly the same problem with parseStatusText. Everything else worked as long as you commented that out. Hmmm....
Digging a little further, found that by including just that one method takes the compiled sketch size from 12,202 bytes up to 19,696 bytes. It's been written to use the String object for all comparisons, which doing a little reading is very inefficient memory wise. (see: http://forums.adafruit.com/viewtopic.php?f=25&t=26033)
Am in the process of converting it to use standard c byte array based strings doing the comparisons using standard c routines like strcmp and so far it looks like the compiled code is about half the size (just for the parseStatusText method). I have only converted a subset of that method right now, but that same subset was crashing using String and does not crash using char[].
Guess that's the downside of using a lower spec chip... Gotta keep it efficient.
Hi Ben Govett,
I've changed string to char[] and still get almost the same sketch size.
You mind sharing yours (like on github or pastebin.com ) ?
Kind Regards
The final result of string to char[] wasn't as successful as I'd hoped, although it is still a minor improvement. It would work with a larger number of strings, but not all of them as hoped.
Am working on getting it to check the length of the string first, and only compare to strings of the correct length using a switch statement before any string comparisons. That way you only compare to strings of a matching length, decreasing the memory allocations required in each cycle.
This requires quite a bit of reformatting, so am moving the strings to metadata and writing a code generator to write the method for me. The resulting code is FAR more efficient, but the mappings are then out of order / harder to read and maintain. The generator gives you the best of both worlds.
Will post when I finish playing as right now it's in a state of flux (aka: a mess). If I manage to get this going, the GPS co-ordinates will be next. I will probably divert to a pure GPS to FrSky S-Port implementation to learn more about embedded systems with a far less complex codeset, then come back to this project.
I have a proposed feature which should be easy to implement:
Landing gear trigger based on mavlink altitude, RTL, failsafe and error messages.
I have that running as a model script.
Currently it can be overridden manually by a radio switch, and it's working like this:
If vertical speed is up and height more than 10 meters it checks if the LG chanel is up, otherwise changes it to Up position.
When vertical speed is down calculates if at the current vertical speed plus 10 seconds (the time my Landing Gear takes to Full Down position) the height will be more than 10 meters, If not it lowers the Landing Gear.
I will soon make it also respond to some flight modes and failsafes (specially radio failsafe).
-
102
-
103
-
104
-
105
-
106
of 186 Next