Re: [Paparazzi-devel] Support for multiple communication links

[Cameron Lee]

So I've started my project to add support for multiple links in order to provide redundancy. So far I've mostly been looking at the code and trying to understand the system. I think I've got a good grasp of things and am going to start implementing my changes. I have a few questions though.

So my plan is to do pretty much what Chris suggested. The Link process will have a command line argument to specify it's id/name and so one Link process can be run for each link. The messages sent over the ivy bus to the server will contain this link id and the other ground segment processes will all need to be changed to support this change. This way, the GCS can display the status of each link, the messages process can display messages of both links, and many other advantages.

My questions for right now are:

1. The format of the messages sent over the ivy bus by the Link process seems to be (I'm using ivyprobe to look at them):

<Process_name> <Message>

where Message is:

<aircraft_id> <message_name> <value1> <value2> <value3> ...

for example:

Link sent  '1 DOWNLINK_STATUS 98 96 6 610 0.0 0.0 -1362023310933.28'

What I'm wondering is, where in here should I include the link id? Should I change the process name? ex:

Link_primary sent  '1 DOWNLINK_STATUS 98 96 6 610 0.0 0.0 -1362023310933.28'

or add a new field before the message name? ex:

Link sent  '1 primary DOWNLINK_STATUS 98 96 6 610 0.0 0.0 -1362023310933.28'

I'm going to start looking into how the server reads these messages to try and answer my own question, but any advice would be great.

2. The processes that I know I need to change are: Link, GCS, Server, Messages, Messages (Python), Real Time Plotter. Are there others? I figure that the logging (in the Server process, right?) and Log File Player probably need to be changed as well. Anything else? Also, the above is the order I would start changing things.

Thanks for any help,

Cameron

On Mon, Oct 29, 2012 at 11:05 PM, Cameron Lee <address@hidden> wrote:

Thanks for your comments Chris. I haven't looked into this much yet so I'm not sure exactly what will need to be done. There will be a significant learning curve for me, which is partly why I'm asking for advice and suggestions.

I heard that there is a new messaging system being developed. Would this change things at all? Should I look at adding this functionality to the existing system, or the new system?

Cameron

On Sun, Oct 28, 2012 at 9:32 PM, Chris Gough <address@hidden> wrote:

Hi Cameron,

On Mon, Oct 29, 2012 at 11:52 AM, Cameron Lee <> wrote:
> I mean two links from the autopilot to the GCS but only one link from the
> GCS to the autopilot. New software at the GCS would listen to both incoming
> links and pass the data on to the GCS itself if either incoming link has
> valid data. The new software I would write for the autopilot wouldn't be
> used in this setup.

Ah, I was getting things mixed up.

Rather than making a "virtual link" that aggregates the modems behind
another process, have you looked into modifying the existing server,
GCS and link programs to support multiple links natively? Maybe there
are already features there I don't know about - the comments in
link.ml tantalisingly suggest that multiple concurrent links are
supported, but reading through the code it's not clear to me how
(link_id is always 0?).

server.ml sends TELEMETRY_STATUS and TELEMETRY_ERROR messages with an
aircraft_id but not any kind of link_id. Either these messages would
need to have a link_id added, or some new messages would be required.

The GCS  would need to be modified to do something with the multiple
links described in TELEMETRY_* messages, and I think link.ml would
need to be modified to get/use a link_id, maybe assigned by a new
command line option

Maybe some new TELEMETRY_INFO messages ("link 2 down" etc). It would
be nice to know how many links there are to a given aircraft, and/or
how many aircraft are visible on a certain link.

Is this a sensible approach (anyone)?

> What I was wondering most is if the Lisa M could easily be set up to allow
> multiple links.

I suspect it could be, but am not the best person to help with that.

Chris Gough

> On Oct 28, 2012 6:34 PM, "Chris Gough" <address@hidden>
> wrote:
>>
>> > Whatever the case, for us, the primary use would be to have two links
>> > from
>> > the autopilot the the groups station but only one from the ground
>> > station to
>> > the autopilot. We can split the Tx of the TWOG in two and send one over
>> > 900
>> > MHz and the other over WiFi.
>>
>> Do you mean only one link (from GCS->autoplot) at a time, but with the
>> ability to change? Otherwise, like you said, you can just splice Tx
>> from the autopilot to both modems (and connect autopilot Rx from the
>> one you chose).
>>
>> > Also, future hardware could have more UARTs for this, couldn't it?
>>
>> I guess so.
>>
>> Chris Gough
>>
>> > Cameron
>> >
>> > On Oct 28, 2012 5:20 PM, "Chris Gough" <address@hidden>
>> > wrote:
>> >>
>> >> Hi Cameron,
>> >>
>> >> If you going to add multiple serial modems directly to an existing
>> >> autopilot, you might need to find a way to free up some serial IO (i2c
>> >> GPS?).
>> >>
>> >> We did this by cheating; inserting a linux computer between the
>> >> autopilot and modems. This was required because our ubiquity link
>> >> (bullet/rocket) is only accessible via ethernet, but it would allow an
>> >> arbitrary number of serial modems to be added (we use one or two).
>> >>
>> >> It's not a very elegant solution though (or cheap, or light, or
>> >> compact), ethernet/usb connectors don't tolerate vibrations very well
>> >> so the whole thing requires a lot of hot glue to make it reliable.
>> >>
>> >> Chris Gough
>> >>
>> >>
>> >> On Mon, Oct 29, 2012 at 6:58 AM, Cameron Lee <address@hidden>
>> >> wrote:
>> >> > Hello everyone,
>> >> >
>> >> > I'm a fourth year Electrical Engineering student interested in
>> >> > working
>> >> > on an
>> >> > aspect of Paparazzi for a class of mine. I'm planning on adding
>> >> > support
>> >> > for
>> >> > multiple communication links at both the GCS and on the autopilot.
>> >> > Similar
>> >> > to item 6 in the wishlist
>> >> > (http://paparazzi.enac.fr/wiki/Software_Wish_List):
>> >> >
>> >> >
>> >> > The possibility to use multiple ground modem connected to a single
>> >> > ground
>> >> > station. The RSSI could be use to dynamically choose which currently
>> >> > has
>> >> > the
>> >> > best signal. This would allow the use of different antennas on each
>> >> > of
>> >> > the
>> >> > modems or have antenna pointing in different directions(?Possibly
>> >> > more
>> >> > hardware related)
>> >> >
>> >> >
>> >> >
>> >> > Here's a description I've written up:
>> >> >
>> >> > The goal is to improve the open source Paparazzi autopilot by adding
>> >> > support
>> >> > for multiple communication links to provide redundancy and increased
>> >> > flexibility. Currently, a single bi-directional serial data link
>> >> > enables
>> >> > the
>> >> > autopilot to provide telemetry to the ground station and the ground
>> >> > station
>> >> > to provide commands to the autopilot. This serial data link is
>> >> > usually
>> >> > created using RF radios and if it’s lost for any reason, all
>> >> > communication
>> >> > with the autopilot is lost. If two data links can be created, then
>> >> > communication can be maintained even if one of the links is lost.
>> >> > Typically,
>> >> > the two links would be of different varieties: two different
>> >> > frequencies, or
>> >> > a short-range high-throughput link and a long-range low-throughput
>> >> > link,
>> >> > or
>> >> > the same type of radio, but with different types of antennas, other
>> >> > combination.
>> >> > This project will involve enabling the autopilot and the ground
>> >> > station
>> >> > to
>> >> > each transmit their data through multiple links as well as receive
>> >> > data
>> >> > through multiple links. Receiving data through multiple links will
>> >> > involve
>> >> > deciding which link to take as correct based on the data coming in
>> >> > through
>> >> > all available links.
>> >> >
>> >> >
>> >> >
>> >> > Before I start working on this, I figured that I should ask for
>> >> > feedback
>> >> > -
>> >> > is this functionality indeed useful? Is this the best way to go about
>> >> > it? Is
>> >> > this project achievable (in particular on the autopilot side - will
>> >> > it
>> >> > take
>> >> > too much system resources)? Any tips or advice would be appreciated.
>> >> > Also,
>> >> > how difficult would it be to have different telemetry sent out over
>> >> > each
>> >> > link?
>> >> >
>> >> > Thanks,
>> >> >
>> >> > Cameron
>> >> >
>> >> > _______________________________________________
>> >> > Paparazzi-devel mailing list
>> >> > address@hidden
>> >> > https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> .
>> >>
>> >> _______________________________________________
>> >> Paparazzi-devel mailing list
>> >> address@hidden
>> >> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>> >>
>> >
>> > _______________________________________________
>> > Paparazzi-devel mailing list
>> > address@hidden
>> > https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>> >
>>
>>
>>
>> --
>> .
>>
>> _______________________________________________
>> Paparazzi-devel mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>
>
> _______________________________________________
> Paparazzi-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>



--
.

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel