Frsky bidirectional telemetry implementation

Development Team
22

mhmm I think that as library maintainer his focus is on not “braking things up” which is ok I guess
:thinking:

23

I’m trying to add frsky support to ardupilot’s AP_Scripting library in order to have true LUA to LUA bidirectional telemetry.

It will have many limits, at least in the first releases mainly due to low memory, low speed and limited telemetry rates

Some ideas:

  • push packets from AP_Scripting into the passthrough stream.
    This would let’s end users extend the passtrough protocol without touching the ardupilot implementation.
  • push packets from the AP_Scripting into the “mavlite” stream.
    This would let users interact with a ground system that can speak mavlite
  • push custom packets into the frsky stream.
    This would let users create their own telemetry protocol or send to OpenTX custom sensor values straight from the air.
  • pop incoming packets from the uplink stream and process them locally from AP_Scripting
    This would allow true bidirectional LUA to LUA communication.
24

Great great job, as usual i must say.

Corrado

1 Like
25

Eric,

Right now your Mavlink to Passthrough is one way, right? Will it be bi-directional at any point? This is not a request but I am just curious if this is envisioned.

Marc

26

Marc it is inherently bi-directional for Mavlink traffic between the FC and GCS. Also the FrSky module reads and writes PT telemetry. Right now the FrSky module does not read and decode into meaningful data to pass back to the FC. As it happens I do have an old project that does that. Are you envisioning a multipurpose board?

27

@Eric_Stockenstrom , @Marc_Dornan it would also be pretty simple to add the 2 way message parsers on top of Eric’s mavToPT code in order to have the same 2 way light messagges and enable parameters and commands from LUA code to be fed to the FC via Mavlink.
This would allow, just as an example, to configure the mav2PT at runtime via LUA, set parameters and execute simple commands like compass calibration or airspeed calibration…

28

Ah, I see where you are going with this. Might need SSL/SSH no?

29

I should have specified “mavlink commands” not “generic commands”, the flow I was thinking about is:

LUA -> new mavlink like message -> msg chunked on sport -> sport bus -> mav2PT -> sport chunk decoded -> msg decoded -> convert msg to mavlink -> forward to FC via mavlink and vice versa

30

I would be happy to participate,

31

Eric I’m sorry lately my ideas end up in you having to do some coding :slight_smile:

anyway, the steps to integrate it would be:

RX

  • add an sport packet decoder to feed the queue, I guess you already have one for your frskyToMavlink project but if not mine is here
  • add a queue for incoming s.port packets
  • whenever the decoder finds a msg chunk invoke the message parser (just like mavlink), mine is here
  • add message handlers, mine are here and limited at handling mavlink parameters messages (except for parameters list)

TX

  • add a new packet type in your scheduler to send msg chunks
  • add a msg encoder, mine is here and here

it’s not that much work in the end.

EDIT: this for AIR mode, in GROUND mode mav2PT also needs to generate the polling for OpenTX otherwise packets do not leave the radio and having both to poll AND read incoming packets might complicate things a bit

32

Alex, sorry for being missing in action. I’ll get back to you on this.

33

No problem Eric, this will require some time from the both of us :slight_smile:

34

Hi Alex

Nice work on the code! I’m ready to tackle this. Do you have an S.Port frame layout for me, just to be sure I have it correct. :slight_smile:

EDIT: I guess it’s in mavlite.h

35

sport packet is here

mavlite_message_t is in mavlite.h, you’ll find the structure really trivial, it’s a cut down version of mavlink :slight_smile:

36

Alex, where can I get a copy of your LUA for this project?

Do you have a diagram of the data flow, and perhaps the mapping of params to S.Port payload?

37

Eric, I don’t have much, I really need to update the blog with detailed info.

I also have to write custom versions of my bidirectional lua for dev purposes, for instance a version that periodically sends uplink packets every 2000ms and prints the exact bytes sent up the s.port link.

Same thing for the downlink, a script that logs all received packets at a byte level, you’ll have to wait a couple days for these :frowning:

38

Ok I was hoping for some test data. I’m still just looking at the S.Port end.

On Tuesday we are off to Australia for about a month, but I can do some more work from there.

39

S.Port uplink or downlink?

40

uplink now, but both really

41

ok, later today I should be able to get you a lua script that decodes downlink and periodically sends uplink with full logging