http://wiki.paparazziuav.org/w/api.php?action=feedcontributions&feedformat=atom&user=CamleePaparazziUAV - User contributions [en]2026-05-19T13:54:50ZUser contributionsMediaWiki 1.37.1http://wiki.paparazziuav.org/w/index.php?title=Redundant_Communication&diff=15189Redundant Communication2013-05-31T03:50:17Z<p>Camlee: </p>
<hr />
<div><div style="float: right; width: 15%"><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Tools</categorytree></div><br />
<div style="float: right; width: 45%; overflow: hidden">[[Image:link_page.png|center|397px|Link Page in GCS]]</div><br />
<div style="float: right; width: 40%">__TOC__</div><br />
<br />
This goal of this project is to allow multiple radio modems or other links be used between the aircraft and the ground station in a redundant fashion so that even if one link is lost, communication can be maintained. So far, the aircraft to ground component has been created and tested in the lab. The ground to aircraft component has not been created yet.<br />
<br />
===Reasons to Use Redundant Links===<br />
Communication from the aircraft to the ground is called telemetry. This communication allows the status of the aircraft such as location, altitude, airspeed, battery level, current flight block, and much more to be monitored in real time. Communication from the ground to the aircraft is called datalink. This communication allows commands to be sent to the aircraft from the ground. This includes telling the aircraft what navigation to perform: fly to a waypoint, start the search area, come in for a landing. If a single link is used, as was always the case before this project, then if the aircraft goes out of range, or that link is otherwise lost, no telemetry information can be displayed in the GCS and commands sent from the GCS won't be received by the aircraft. Using the following redundant link system allows multiple links to be used in an effort to avoid this. Typically, you would introduce diversity when adding links. For example:<br />
* If you have an on-board computer, you could tunnel messages through Wi-Fi over UDP in addition to a traditional 900 MHz XBee radio modem.<br />
* You could use a satellite modem for long-range monitoring in addition to a radio modem.<br />
* You could use a cellular modem in addition to a radio modem.<br />
* With additional ground infrastructure, you could have radio modems located at different locations.<br />
* You could use radio modems at different frequencies or with different antenna gains or orientations.<br />
* You could use this system to evaluate different types of radio modems or antenna placements - you'll get real time info on each such as the ping time, received messages rate, and more information could easily be added.<br />
<br />
There are undoubtedly many more possibilities.<br />
<br />
== Aircraft to Ground ==<br />
<br />
===Compatibility===<br />
This project was made to be fully backwards compatible and support the awesome functionality that Paparazzi already has. This includes:<br />
* Completely backwards compatible - includes aircraft configuration files, previous flight logs, existing sessions, etc...<br />
* Logging and replay - if multiple links are used, data received through either link is recorded. Also, replays will include the status of each link as it was during the flight.<br />
* Link features such as USB-serial, audio, UDP, different transport layers, etc...<br />
* Multi-aircraft sessions - also, you can use redundant links for one aircraft, but not for another if desired.<br />
* Multiple aircraft connected to the same link - such as might come up in a mesh configuration where one aircraft relays data from another aircraft.<br />
<br />
===Features===<br />
Enabling redundant communication from the aircraft to the ground enables the following features:<br />
* Redundancy - as long as one link is receiving data, it will be logged and displayed on the GCS.<br />
* Monitoring - the status, ping time, and rate of receiving messages for each link is shown (this makes it useful even if you're only using one link).<br />
* Alerts - new alerts are added to the console in the GCS to alert you when a link has been connected for the first time, lost, or re-gained.<br />
<br />
===Future Improvements===<br />
Several different improvements can be made to this system to improve it's performance and help satisfy future needs that may arise:<br />
* Additional information can easily be added to the Link page of the GCS for each link. For example: errors, % uptime, or a scrolling graph of Rx messages/s.<br />
* The ability to mark different links as either critical or backup. The idea here is that not all links should necessarily be treated equal. Maybe only one link is able to send datalink data to the aircraft (actually, this is the case right now) and so that link should be considered critical. If any other link is lost, then the overall telemetry can be counted as OK. But if the critical link is lost, then the GCS should change the link indicator light to red and start counting up even if the other link(s) are OK.<br />
* The Link Combiner algorithm currently employs a simple circular buffer. This could be improved on by adding a time-stamp to each element of the buffer and only counting two buffer elements to be the same if their timestamps are close enough (say within 2 seconds - this could be configured)<br />
* The Link Combiner algorithm could be improved by making the buffer size adjust automatically with the ping time and Rx messages/s rate. Or if the timestamp improvement is implemented, then the maximum time difference could be adjusted.<br />
* A performance and resource use analysis could be done to optimize the Link Combiner. The circular buffer is currently implemented using Python lists which could probably be improved upon. Also, significantly more ivy messages are sent and received. This might make optimizations to the regex or other parts of the ivybus worthwhile.<br />
<br />
===How to Use===<br />
<br />
For an example using two USB-serial adaptors, see the '''Flight USB-serial Redundant''' session saved in the example control_panel.xml configuration (on master branch, once the pull request has been accepted).<br />
<br />
For the details, keep reading:<br />
In order to implement redundant links using this code, there are three simple steps to follow:<br />
<br />
* Connect the hardware - on the airborne side, connect the Rx pin of the autopilot's UART port to multiple radio modems or whatever other device which will get the information to the ground. On the ground side, connect multiple modems as normal (using USB to serial adapters, a UDP connection, or whatever). (note: Once the ground to aircraft redundancy has been implemented, you won't have to split the Rx signal and can just plug each modem into a UART port)<br />
* Launch a Link agent for each modem (in Paparazzi Center, select it from the tools menu). Configure the agents as you would have before (serial port, baud rate, UDP, etc...). None of these features have been modified or removed. Then, use two new command line arguments: -redlink and -id. The -redlink flag tells Link that it's one of multiple links. The -id flag lets you specify an integer number as the id of that particular link.<br />
* Launch the Link Combiner agent (again, from the tools menu). This agent listens to all of the Link agents that have their -redlink set and combines the data.<br />
<br />
The following screenshot shows a session with two links, connected to serial ports ttyUSB0 and ttyUSB1, and with id's 1 and 2:<br />
<br />
[[File:redundant_session.png|alt=Agents in Redundant Link Session|700px|thumb|center|The Agents Running in a Redundant Link Setup]]<br />
<br style="clear:both"><br />
<br />
* Test the system and make sure that it works correctly under all circumstances. Do this before flying. In particular, make sure that the buffer size if appropriate. Take a look at the [[#Algorithm Considerations|Algorithm Considerations]] section for details.<br />
<br />
===Interface===<br />
Once the redundant link system is started (even if only one Link is used), several changes appear in the GCS. This is achieved by the new message LINK_STATUS which is sent by the Link Combiner. These new features are designed to allow closer monitoring and better management of the link(s) between the aircraft and the ground station.<br />
<br />
The following screenshot clearly shows these changes:<br />
[[File:redundant_link_gcs.png|alt=Changes to the GCS when redundant links are used|1000px|thumb|center|Screenshot of the GCS with multiple links]]<br />
<br style="clear:both"><br />
<br />
Firstly, we can see that there is a new page in the notebook named Link. This page contains critical information for each link. More information can easily be added, but for now, it shows the status of the link (just like the main Link status indicator in the strip), the current ping time, and the rate of received messages. So if one link is lost, it's status indicator will turn red and start counting up just like link 2 in the above screenshot.<br />
<br />
Next, we can see that the main Link status indicator that's located in the strip has been modified slightly. It now shows the ratio of connected links to the total number of links. I.e. 3/4 means that there are four links and one of them has been lost. Furthermore, the indicator will be green if all links are connected, yellow if one or more are lost, and red if all links are lost. Once all links are lost, the indicator will count up just like before.<br />
<br />
Lastly, alerts have been added to the console. Whenever a link is lost or reconnected, a message will appear in the console stating so. Messages also appear when a new link is added.<br />
<br />
===Design===<br />
====Implementation====<br />
Here's a block diagram showing how the aircraft talks to the various ground segment programs (also known as agents) when not using the redundant link system:<br />
<br />
[[File:ground_segment_block_diagram.png|alt=Block diagram of agents in the ground segment|500px|thumb|center|Paparazzi Ground Segment]]<br />
<br style="clear:both"><br />
<br />
The ivy bus lets the programs talk to each other through the use of short messages. Pay close attention to the coloured arrows, which show the main flow of these messages. Next we have a block diagram of the redundant link system:<br />
<br />
[[File:redundant_links_block_diagram.png|alt=Block diagram of agents in the ground segment when redundant links are used|800px|thumb|center|Paparazzi Ground Segment with Redundant Links]]<br />
<br style="clear:both"><br />
<br />
<br />
Here we can see the new agent, the Link Combiner. We also see multiple occurrences of the Link agent. When operating in redundant mode, each occurrence of Link transmits the data it receives from the aircraft to the Link Combiner instead of the Server. It does this by transmitting the received telemetry messages within the TELEMETRY_MESSAGE message which the Server doesn't listen to. The Link Combiner on the other hand does. TELEMETRY_MESSAGE messages are sent by each link and include the id of that link. The Link Combiner listens to all of them and then transmits a single set of messages to the Server with the combined data. This results in the Server and all other ground segment agents (such as Messages and the Real Time Plotter) getting their telemetry data from Link Combiner as if it was coming from a single occurrence of Link.<br />
<br />
====Link Combiner====<br />
The Link Combiner agent is written in Python. It receives messages from all of the Links (when they're in redundant mode: -redlink), and outputs messages to the Server and other ground segment agents. There is a bit involved however since the Server and GCS shouldn't be sent identical messages. I.e. if the aircraft sends a message and it's received successfully by more than one link, then that particular message should only sent by Link Combiner once. This is a somewhat tricky requirement since there is no guarantee that the message will be received by all of the links, and it's possible that the aircraft actually sends a second message that's exactly the same as the first. No extra info (such as a time-stamp or counter) is added to the messages sent from the aircraft to the ground, so the Link Combiner employs an algorithm to detect duplicate messages. Testing has shown that for typical links, this algorithm performs extremely well.<br />
<br />
The algorithm gives each link a circular buffer to store the last N messages. When a new message comes in on a particular link, the algorithm first checks if it's already in that link's buffer. If it is, then it's obviously a new message, so its removed from all of the other buffers if it's in any of them. Then, the message is sent to the other agents. If the message isn't already in the link's buffer, then it's added to the buffer. After that, all of the other link's buffers are checked for the message. If it's in any of them, then the message was already received by another link, so isn't sent. If it's not in any of them, then the message is sent. The following flowchart depicts this algorithm:<br />
<br />
[[File:link_combiner_flowchart.png|alt=Flowchart of the Link Combiner|500px|thumb|center|Algorithm to prevent duplicate messages]]<br />
<br style="clear:both"><br />
<br />
====Algorithm Considerations====<br />
As the aircraft sends various messages, possibly with the exact same data, and the links gain and lose connection, there is no guarantee that this algorithm will do a perfect job of filtering out identical and only identical messages. However, in typical operation, it seems to work very well. And for the application of displaying aircraft data, the occasional missing or duplicate message is acceptable. There are only a few scenarios where the Link Combiner won't produce perfect results, and they should come up infrequently:<br />
<br />
* A message will be sent twice if the buffer size is too small to hold all of the messages received from one link between that link receiving the message and another link receiving the identical message. When the second link receives the message that has already been received, if the original isn't in the buffer anymore, than the algorithm won't know it's a duplicate message. This scenario should be considered whenever implementing a redundant link system. Partly because it is the most likely to come up, but also because if it does occur, then all messages will be duplicated. In order to avoid this scenario, you can set the buffer size as a command line argument of Link Combiner. To know what a good value would be, you can observer the Ping time and Rx messages/s of the links in the new Link page of the notebook. Calculate the minimum buffer size by taking the difference between the largest ping time and the smallest ping time and multiplying it by the largest Rx messages/s. Then apply a safety factor when setting the buffer size - 10 times the calculated value should be good.<br />
* A message won't be sent when it should be if the autopilot sends a message that's the same as one it already sent (same name and exact same values) AND one or more links were lost between the first message and the second AND the link that's receiving the second message doesn't have the first message in it's buffer still. That's three conditions. If this happens, then the Link Combiner will see the second message as a duplicate of the first and will skip it. Only this one message will be missed though - it won't start happening to all messages. Also, the data will have been data that was already received. So if it's for example the battery voltage message, then it's not a big deal to miss it. As long as there aren't links rapidly being lost and gained, then this shouldn't happen often. Note that as the buffer size is increased, it is believed that this becomes more likely to happen.<br />
<br />
== Ground to Aircraft ==<br />
<br />
This part of the redundant communication system hasn't been implemented yet. All information here is what it is envisioned to look like.<br />
<br />
===Features===<br />
* Enable multiple datalink links to be used for communicating with the autopilot.<br />
* Let different telemetry be sent out each link.<br />
* Let the choice of what telemetry is sent be moved from the settings page of the GCS to the Link page, since it can be different for each link.<br />
* Add a link status indicator (this is the light that turns red when the link is lost) for the datalink to the Link page. This will allow better monitoring of the links by not assuming that if one direction is good, the other direction is good as well.<br />
* Let each link be configured as telemetry only, datalink only, or by-directional.<br />
<br />
===Compatibility===<br />
Communication in the autopilot is enabled with the ground by including the telemetry subsystem in the airframe file. For example:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing or rotorcraft"><br />
...<br />
<subsystem name="telemetry" type="transparent"/><br />
</firmware><br />
</source><br />
}}<br />
<br />
In order to use multiple links, changes should be made to allow a telemetry subsystem for each link. Related to this, would it be advantageous to have multiple instances be supported for each different subsystem? Once the design for this is determined, would actual support for each subsystem have to be added one at a time? Because of the logic for how multiple subsystems should behave together is dependent on the subsystem, this might be the case. The telemetry subsystem for example should default to sending telemetry out each one and combining the telemetry received.<br />
<br />
===Hardware===<br />
Unlike aircraft to ground redundancy, ground to aircraft redundancy requires multiple UART ports in the hardware of the autopilot. The author is not particularly familiar with this, but believes that there are ways to get multiple UART ports for this purpose:<br />
* Telemetry can be sent out over USB by specifying the telemetry type to be "transparent_usb".<br />
* For the Lisa/M, the USB port can actually be used as a UART port with some hardware modifications.<br />
* Using an I2C GPS instead of a UART one can free up a UART port on most autopilots.<br />
* For the Lisa/M, can UART 1 and 5 be used if Spektrum Satellite receivers aren't used? If so, where are the Tx pins?<br />
<br />
In addition, future hardware designs could includes more UART ports for redundant communications or any other purpose.<br />
<br />
===Design===<br />
Unlike the aircraft to ground communication, for ground to aircraft communication it is not acceptable to have the same message be acted on twice. This could cause the aircraft to behave unexpectedly. In order to implement a 100% guaranteed link combiner for the aircraft, the author proposes a system that adds a counter to each message sent to the aircraft. This would allow the autopilot to easily ignore identical messages - they'll have the same value for the counter. Also, since minimal data is sent from the ground to the aircraft, adding the extra bytes to the payload will have a minimal impact on performance - this is not the case for the telemetry.<br />
<br />
The challenging part of this design will be integrating it properly into the existing systems.<br />
<br />
[[Category:Tools]]</div>Camleehttp://wiki.paparazziuav.org/w/index.php?title=Software_Wish_List&diff=14984Software Wish List2013-04-29T02:22:06Z<p>Camlee: Added link to an existing solution to a wish list item</p>
<hr />
<div>{|<br />
|-valign="top"<br />
|__TOC__<br />
|Please use the [[Talk:Software_Wish_List|Discussion]] tab at the top of the page, as appropriate.<br />
|}<br />
<br />
'''This page is only kept for reference!'''<br />
<br />
'''Please use our [https://github.com/paparazzi/paparazzi/issues issue tracker] for reporting bugs, requesting new features or to list things currently in progress (or planned).'''<br />
== Introduction ==<br />
<br />
After you played around with the GCS, the Airborne code, tested it and used all it's possibilities, sometimes you get this feeling... "''I would like to have '''more'''!''". The first thing to do is to ask in the mailinglist if it is already possible. The next great thing would be to create what you think is lacking and give it back to the community so it could be part of the project in the future. If you are not that gifted yet, you could present your ideas here. Other enthusiastic Paparazzi developers could read this and think: "''YEAH, now that is a really cool idea and I will start working on it right away!''". Therefore, since everyone can improve a part of the project, note here what you would like to see added or improved in the software.<br />
<br />
== Ground Station Suggestions ==<br />
<br />
# Module to make papazzi messages available in QGroundControl http://qgroundcontrol.org/ [[User:OpenUAS|(Suggested by OpenUAS)]]<br />
# Integration with module for OpenJAUS, see for already available code http://code.google.com/p/openjaus/ [[User:OpenUAS|(Suggested by OpenUAS)]]<br />
# Support for stanag 4586 compliance, see http://www.innuvativesystems.com/stanag_4586_primer.html [[User:OpenUAS|(Suggested by OpenUAS)]]<br />
# Support for standard map files like GeoTiff, .tab and .map. Using the .xml method manually is rather time consuming and frustrating when you already have standard georeferenced images.<br />
# Divide the flight plan into 3 separate files [[User:Jeremy|(Suggested by Jeremy)]]<br />
#* Takeoff/Landing - flight plan blocks describing the complex routines and using altitudes and waypoints from the ''User'' file<br />
#* Generic - a file that users should never need to edit, containing circles, rectangles, figure-8's, and surveys that appear on command when GCS buttons are pressed. Altitude/locations could be relative to the ''User'' file<br />
#* User - Here we can specify fixed or dynamic ''Home'' point and add complex routines or simply save certain basic routines. <br />
#*('''NOTE:''' All of this is already possible, investigate time in discovering what paparazzi already can do now e.g. see [http://paparazzi.enac.fr/wiki/Flight_Plans#Procedures Flight Plan Procedures])<br />
# 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) - Something similar, but with more flexibility, has been created. See [http://paparazzi.enac.fr/wiki/Redundant_Communication Redundant_Communication].<br />
# PFD - the horizon and the sky shouldn't move only the main line. Because we are on the '''ground''' and we really need to see the roll angle of the UAS and not the real PFD like on a real airplane. And we could also see, the pitch angle, to see if the UAS is climbing or going down. Another way this could be done is to use a 3D model of the plane like procerus does on there ap. For those unfamiliar with this it is like you are in the view point of like 5m behind the plane. This might give the user just enough of a model to help fly back under manual control or at least have a better understanding of the orientation. This idea is good one but it should not replace the current pfd but rather be an option to use in the gcs. ('''NOTE:''' Already possible, via [http://paparazzi.enac.fr/wiki/GCS#Papgets Papgets] it is possible to add all kinds of such types of information. Also for a 3D plane view this is already possible, just bind you output to [http://paparazzi.enac.fr/wiki/Simulation#View_the_simulation_in_Flight_Gear FlightGear])<br />
# Language packs for the GCS - English, French, German, Italian, Spanish, Portuguese, ... (azoreanuav(at)gmail.comI would like to make the portuguese pack, but I neet help how to do it.)<br />
# Flashing via modems - ('''NOTE:''' Already [http://lists.gnu.org/archive/html/paparazzi-devel/2010-06/msg00138.html possible])<br />
<br />
== Airborne Software Suggestions ==<br />
<br />
Add your ideas here what you would like to see added or improved in the airborne software<br />
<br />
=== Stability ===<br />
* Auto-tuning of gains<br />
*: It would make paparazzi very user friendly if the airframe could tune itself. It should be possible to set the gains on the ground to some generic value and let the autopilot do the tuning in the air. The autopilot would give step functions on different inputs (actuators, target values) and measure the response of the airframe. One at a time, of course. Based on this response measurement the autopilot can tune the control gains itself. For safety reasons this auto-tuning function would run only on safe flight altitude.<br />
<br />
=== Navigation ===<br />
* Flight plan stage sensing <br />
*: Carrot should continue past the waypoint toward the next point, but the point should not be officially acknowledged until the plane has passed it. This way we can have smooth, intelligent navigation while still considering waypoint triggers such as still-photo, sensor drop, or throttle off. <br />
'''NOTE:''' Can already be done by setting the approaching_time attribute. This value helps to decide when the target is reached. It can be set to 0 to go over the target waypoint. see [http://paparazzi.enac.fr/wiki/Flight_Plans#Go Flightplan documentation]<br />
<br />
=== Other ===<br />
# '''Revised autopilot modes''' [[User:Jeremy|(Jeremy)]]<br />
#* I propose a restructuring of the modes as follows - create 3 top-level modes: '''Man, Stab,'''and '''Auto''', each with an appended autonomous sub-mode (i.e. '''Man'''/''Climb'', '''Stab'''/''Kill'', '''Auto'''/''Landing'', etc.) This will give the operator much more information and a much better indication of what the plane will do when switched to autonomous mode in a concise manner. Furthermore, I see an advantage in having simple behaviors like ''Climb, Landing'', etc. be defined as sub-modes so that operator is always alerted of changes such as ''Descent'' or can easily configure trim, gains, and payload options in the airframe file (i.e. if mode = ''Landing'' then retract camera, turn off video system, use landing trim, etc.)<br />
#* ''Sub-modes''<br />
#* ''Ground'' - The default boot mode. In this mode the throttle is locked at 0% or not armed at all (no PWM signal), stability is disabled (servos locked in neutral position), and video power is off, but flight plan blocks are processed. This will improve safety and aid in lost plane retreival as the servos, and video will not drain the battery if landing detection is implemented. ''Ground'' mode should exit '''only''' if ''Takeoff'' is manually triggered.<br />
#* ''Takeoff'' - 3 possible triggers: GCS button, GPIO button, or R/C throttle. Checks for error modes and desired climb, then arms/unlocks throttle, initates "Takeoff" flight plan block, and instantly deroutes to ''Climb'' mode. Deroutes to ''Descent'' mode without unlocking throttle if not OK. ''Takeoff'' could simply be a flag rather than a "mode".<br />
#* ''Climb'' - Triggered anytime "aggressive climb" is active<br />
#* ''Descent'' - Triggered anytime "aggressive descent" is active<br />
#* ''Nav'' - Normal level flight<br />
#* ''Landing'' - Same as ''Nav'' but using the "Landing" flight plan block and any airframe gains/trims/payload options as defined in airframe.xml<br />
#* ''Kill'' - Triggered manually - locks throttle at 0% and uses pitch/roll settings from Airframe.xml. <br />
# ''Error sub-modes''<br />
#* ''No GPS'' - A temporary mode using pitch/roll settings from airframe.xml<br />
#* ''Home'' - Triggered by distance in '''Auto''' mode or by distance/RC loss in '''Stab''' mode (after ''n'' seconds, as defined in airframe.xml). Exits upon manual block/mode change requests from the GCS and cannot be re-initiated for 30 seconds.<br />
# '''Continually broadcast last known location'''<br />
#* AP should continue to broadcast the last known GPS coordinate in the event of GPS loss. (i.e. upside-down crashed plane should continue to send last known position in case it was out of data range prior to the crash.)<br />
#* ('''NOTE:''' Possible by adding for example a module that ''grabs'' current coordinates at e.g. .1 Hz and if in flightplan <while cond="!GpsFixValid()"/> send whatever you want)<br />
# '''Ability to upload waypoints in flight'''<br />
#* I know this has been discussed a few times but it would be nice to at least have the option to upload waypoints and blocks and be able to change blocks in flight. This is risky but most Autopilot's do have this feature now and it would be nice if the user could make this decision. <br />
#* ('''NOTE:''' A possible current solution is by adding duplicate waypoints very close and if needed move these while in flight.)<br />
# '''Radio Control of UAS through Data Link'''<br />
#* This simply means that instead of hacking an RC receiver to output it to the autopilot board why not hook your RC transmitter up through your computer and use the data link for RC. This would be nice especially with all the new RC range issues the 2 layer tiny 2.11 has brought on. Also it would be nice because RC interference would be eliminated. Please comment on this and tell me what you think<br />
#* ('''NOTE:''' Already possible)<br />
#* ('''Response:''' Sort of possible. The only work that has been done in this direction is by Martin and was done with a Joystick which only worked in Auto1 mode (setting the set points for the AP). This is not a full solution. What i am proposing is that the RC Radio is plugged into the GCS directly and then sends the command (PPM) signals directly to the AP. This would allow for the user to control the aircraft in manual and AUTO1. Consult any commercial AP and you will notice that this is the one glaring feature which is missing from PPRZ. In addition adding this feature would allow for longer range FPV flying. Please correct me (with links) if i am wrong. <br />
<br />
# '''Precision Surveying'''<br />
#* It would be nice to have a survey function that could survey a sector and also be told what coordinates to begin the survey on. Another useful feature would be to have the plane sense when it is done surveying the whole area so it could move to the next block. I know that the entering the survey can be done in a roundabout method by defining a waypoint at the entry point and then going to it but defining it in the survey function would allow for more precise survey since that first sweep would already be defined and then would not be affected by if the plane went into the survey function at weird spot or something.<br />
#* ('''NOTE:''' Already possible, see the [http://paparazzi.enac.fr/wiki/Advanced_Navigation_Routines '''Polygon Survey'''] and use it smartly<br />
<br />
== Current Code and Build ==<br />
<br />
If you have any suggestions to improve the current:<br />
<br />
* Sourcecode<br />
* Build process<br />
* Code repository<br />
* Tools used<br />
<br />
...give your suggestions here. Better still, start working on what you can, and add your information to the Wiki and start a discussion in the mailing list.<br />
<br />
== JAUS Support ==<br />
<br />
The Joint Architecture for Unmanned Systems (JAUS) is the premiere interoperability standard for unmanned systems. This standard originated in the Joint Robotics Program, a U. S. Department of Defense Office in 1998 and since has migrated to an open, commercial standard. JAUS has been adopted by the Society of Automotive Engineers, Aerospace Standards Division. Use of the standard is required in major Department of Defense programs and it is used in a variety of commercial and industrial applications worldwide.<br />
<br />
It would be good to investigate how we could add a compatibility layer.<br />
<br />
== X-plane HITL Support ==<br />
<br />
For an example las on<br />
http://code.google.com/p/gentlenav/wiki/HardwareInLoop<br />
<br />
Hector: I used X-Plane in the past for HITL porposes. You have to be carefull as I have not read the next in anywhere.<br />
<br />
As far as I know, simulation time step is not fixed in X-Plane and it depends on<br />
your fps. If you are performing navigation and control algorithms with a time-step fixed, this issue can ruin the behaviour of your avionics.<br />
<br />
I was talking in the IRC with experienced users in X-Plane, and they have written a pluggin to setup the time-stamp (or limiting the fps, X-Plane does not do that by default, only to monitor refreshment), and it does not work as expected always. Also X-Plane physics introduces "artifacts" sometimes ruining your inertial measurements.<br />
<br />
Resuming, X-Plane (commercial version) is not aimed for HITL, for this question, they have the FAA certified version (more expensive of course :P).<br />
<br />
<br />
[[Category:Software]]</div>Camleehttp://wiki.paparazziuav.org/w/index.php?title=Redundant_Communication&diff=14983Redundant Communication2013-04-29T02:07:15Z<p>Camlee: </p>
<hr />
<div><div style="float: right; width: 15%"><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Tools</categorytree></div><br />
<div style="float: right; width: 45%; overflow: hidden">[[Image:link_page.png|center|397px|Link Page in GCS]]</div><br />
<div style="float: right; width: 40%">__TOC__</div><br />
<br />
There is currently a pull request to integrate a redundant communication system into the existing ground segment agents: [https://github.com/paparazzi/paparazzi/pull/429 github.com/paparazzi/paparazzi/pull/429]. The goal of this project is to allow multiple radio modems or other links be used between the aircraft and the ground station in a redundant fashion so that even if one link is lost, communication can be maintained. So far, the aircraft to ground component has been created and tested in the lab. More comprehensive testing should be performed before the system is considered to be stable. The ground to aircraft component has not been created yet.<br />
<br />
===Reasons to Use Redundant Links===<br />
Communication from the aircraft to the ground is called telemetry. This communication allows the status of the aircraft such as location, altitude, airspeed, battery level, current flight block, and much more to be monitored in real time. Communication from the ground to the aircraft is called datalink. This communication allows commands to be sent to the aircraft from the ground. This includes telling the aircraft what navigation to perform: fly to a waypoint, start the search area, come in for a landing. If a single link is used, as was always the case before this project, then if the aircraft goes out of range, or that link is otherwise lost, no telemetry information can be displayed in the GCS and commands sent from the GCS won't be received by the aircraft. Using the following redundant link system allows multiple links to be used in an effort to avoid this. Typically, you would introduce diversity when adding links. For example:<br />
* If you have an on-board computer, you could tunnel messages through Wi-Fi over UDP in addition to a traditional 900 MHz XBee radio modem.<br />
* You could use a satellite modem for long-range monitoring in addition to a radio modem.<br />
* You could use a cellular modem in addition to a radio modem.<br />
* With additional ground infrastructure, you could have radio modems located at different locations.<br />
* You could use radio modems at different frequencies or with different antenna gains or orientations.<br />
* You could use this system to evaluate different types of radio modems or antenna placements - you'll get real time info on each such as the ping time, received messages rate, and more information could easily be added.<br />
<br />
There are undoubtedly many more possibilities.<br />
<br />
== Aircraft to Ground ==<br />
<br />
===Compatibility===<br />
This project was made to be fully backwards compatible and support the awesome functionality that Paparazzi already has. This includes:<br />
* Completely backwards compatible - includes aircraft configuration files, previous flight logs, existing sessions, etc...<br />
* Logging and replay - if multiple links are used, data received through either link is recorded. Also, replays will include the status of each link as it was during the flight.<br />
* Link features such as USB-serial, audio, UDP, different transport layers, etc...<br />
* Multi-aircraft sessions - also, you can use redundant links for one aircraft, but not for another if desired.<br />
* Multiple aircraft connected to the same link - such as might come up in a mesh configuration where one aircraft relays data from another aircraft.<br />
<br />
===Features===<br />
Enabling redundant communication from the aircraft to the ground enables the following features:<br />
* Redundancy - as long as one link is receiving data, it will be logged and displayed on the GCS.<br />
* Monitoring - the status, ping time, and rate of receiving messages for each link is shown (this makes it useful even if you're only using one link).<br />
* Alerts - new alerts are added to the console in the GCS to alert you when a link has been connected for the first time, lost, or re-gained.<br />
<br />
===Future Improvements===<br />
Several different improvements can be made to this system to improve it's performance and help satisfy future needs that may arise:<br />
* Additional information can easily be added to the Link page of the GCS for each link. For example: errors, % uptime, or a scrolling graph of Rx messages/s.<br />
* The ability to mark different links as either critical or backup. The idea here is that not all links should necessarily be treated equal. Maybe only one link is able to send datalink data to the aircraft (actually, this is the case right now) and so that link should be considered critical. If any other link is lost, then the overall telemetry can be counted as OK. But if the critical link is lost, then the GCS should change the link indicator light to red and start counting up even if the other link(s) are OK.<br />
* The Link Combiner algorithm currently employs a simple circular buffer. This could be improved on by adding a time-stamp to each element of the buffer and only counting two buffer elements to be the same if their timestamps are close enough (say within 2 seconds - this could be configured)<br />
* The Link Combiner algorithm could be improved by making the buffer size adjust automatically with the ping time and Rx messages/s rate. Or if the timestamp improvement is implemented, then the maximum time difference could be adjusted.<br />
* A performance and resource use analysis could be done to optimize the Link Combiner. The circular buffer is currently implemented using Python lists which could probably be improved upon. Also, significantly more ivy messages are sent and received. This might make optimizations to the regex or other parts of the ivybus worthwhile.<br />
<br />
===How to Use===<br />
<br />
For an example using two USB-serial adaptors, see the '''Flight USB-serial Redundant''' session saved in the example control_panel.xml configuration (on master branch, once the pull request has been accepted).<br />
<br />
For the details, keep reading:<br />
In order to implement redundant links using this code, there are three simple steps to follow:<br />
<br />
* Connect the hardware - on the airborne side, connect the Rx pin of the autopilot's UART port to multiple radio modems or whatever other device which will get the information to the ground. On the ground side, connect multiple modems as normal (using USB to serial adapters, a UDP connection, or whatever). (note: Once the ground to aircraft redundancy has been implemented, you won't have to split the Rx signal and can just plug each modem into a UART port)<br />
* Launch a Link agent for each modem (in Paparazzi Center, select it from the tools menu). Configure the agents as you would have before (serial port, baud rate, UDP, etc...). None of these features have been modified or removed. Then, use two new command line arguments: -redlink and -id. The -redlink flag tells Link that it's one of multiple links. The -id flag lets you specify an integer number as the id of that particular link.<br />
* Launch the Link Combiner agent (again, from the tools menu). This agent listens to all of the Link agents that have their -redlink set and combines the data.<br />
<br />
The following screenshot shows a session with two links, connected to serial ports ttyUSB0 and ttyUSB1, and with id's 1 and 2:<br />
<br />
[[File:redundant_session.png|alt=Agents in Redundant Link Session|700px|thumb|center|The Agents Running in a Redundant Link Setup]]<br />
<br style="clear:both"><br />
<br />
* Test the system and make sure that it works correctly under all circumstances. Do this before flying. In particular, make sure that the buffer size if appropriate. Take a look at the [[#Algorithm Considerations|Algorithm Considerations]] section for details.<br />
<br />
===Interface===<br />
Once the redundant link system is started (even if only one Link is used), several changes appear in the GCS. This is achieved by the new message LINK_STATUS which is sent by the Link Combiner. These new features are designed to allow closer monitoring and better management of the link(s) between the aircraft and the ground station.<br />
<br />
The following screenshot clearly shows these changes:<br />
[[File:redundant_link_gcs.png|alt=Changes to the GCS when redundant links are used|1000px|thumb|center|Screenshot of the GCS with multiple links]]<br />
<br style="clear:both"><br />
<br />
Firstly, we can see that there is a new page in the notebook named Link. This page contains critical information for each link. More information can easily be added, but for now, it shows the status of the link (just like the main Link status indicator in the strip), the current ping time, and the rate of received messages. So if one link is lost, it's status indicator will turn red and start counting up just like link 2 in the above screenshot.<br />
<br />
Next, we can see that the main Link status indicator that's located in the strip has been modified slightly. It now shows the ratio of connected links to the total number of links. I.e. 3/4 means that there are four links and one of them has been lost. Furthermore, the indicator will be green if all links are connected, yellow if one or more are lost, and red if all links are lost. Once all links are lost, the indicator will count up just like before.<br />
<br />
Lastly, alerts have been added to the console. Whenever a link is lost or reconnected, a message will appear in the console stating so. Messages also appear when a new link is added.<br />
<br />
===Design===<br />
====Implementation====<br />
Here's a block diagram showing how the aircraft talks to the various ground segment programs (also known as agents) when not using the redundant link system:<br />
<br />
[[File:ground_segment_block_diagram.png|alt=Block diagram of agents in the ground segment|500px|thumb|center|Paparazzi Ground Segment]]<br />
<br style="clear:both"><br />
<br />
The ivy bus lets the programs talk to each other through the use of short messages. Pay close attention to the coloured arrows, which show the main flow of these messages. Next we have a block diagram of the redundant link system:<br />
<br />
[[File:redundant_links_block_diagram.png|alt=Block diagram of agents in the ground segment when redundant links are used|800px|thumb|center|Paparazzi Ground Segment with Redundant Links]]<br />
<br style="clear:both"><br />
<br />
<br />
Here we can see the new agent, the Link Combiner. We also see multiple occurrences of the Link agent. When operating in redundant mode, each occurrence of Link transmits the data it receives from the aircraft to the Link Combiner instead of the Server. It does this by transmitting the received telemetry messages within the TELEMETRY_MESSAGE message which the Server doesn't listen to. The Link Combiner on the other hand does. TELEMETRY_MESSAGE messages are sent by each link and include the id of that link. The Link Combiner listens to all of them and then transmits a single set of messages to the Server with the combined data. This results in the Server and all other ground segment agents (such as Messages and the Real Time Plotter) getting their telemetry data from Link Combiner as if it was coming from a single occurrence of Link.<br />
<br />
====Link Combiner====<br />
The Link Combiner agent is written in Python. It receives messages from all of the Links (when they're in redundant mode: -redlink), and outputs messages to the Server and other ground segment agents. There is a bit involved however since the Server and GCS shouldn't be sent identical messages. I.e. if the aircraft sends a message and it's received successfully by more than one link, then that particular message should only sent by Link Combiner once. This is a somewhat tricky requirement since there is no guarantee that the message will be received by all of the links, and it's possible that the aircraft actually sends a second message that's exactly the same as the first. No extra info (such as a time-stamp or counter) is added to the messages sent from the aircraft to the ground, so the Link Combiner employs an algorithm to detect duplicate messages. Testing has shown that for typical links, this algorithm performs extremely well.<br />
<br />
The algorithm gives each link a circular buffer to store the last N messages. When a new message comes in on a particular link, the algorithm first checks if it's already in that link's buffer. If it is, then it's obviously a new message, so its removed from all of the other buffers if it's in any of them. Then, the message is sent to the other agents. If the message isn't already in the link's buffer, then it's added to the buffer. After that, all of the other link's buffers are checked for the message. If it's in any of them, then the message was already received by another link, so isn't sent. If it's not in any of them, then the message is sent. The following flowchart depicts this algorithm:<br />
<br />
[[File:link_combiner_flowchart.png|alt=Flowchart of the Link Combiner|500px|thumb|center|Algorithm to prevent duplicate messages]]<br />
<br style="clear:both"><br />
<br />
====Algorithm Considerations====<br />
As the aircraft sends various messages, possibly with the exact same data, and the links gain and lose connection, there is no guarantee that this algorithm will do a perfect job of filtering out identical and only identical messages. However, in typical operation, it seems to work very well. And for the application of displaying aircraft data, the occasional missing or duplicate message is acceptable. There are only a few scenarios where the Link Combiner won't produce perfect results, and they should come up infrequently:<br />
<br />
* A message will be sent twice if the buffer size is too small to hold all of the messages received from one link between that link receiving the message and another link receiving the identical message. When the second link receives the message that has already been received, if the original isn't in the buffer anymore, than the algorithm won't know it's a duplicate message. This scenario should be considered whenever implementing a redundant link system. Partly because it is the most likely to come up, but also because if it does occur, then all messages will be duplicated. In order to avoid this scenario, you can set the buffer size as a command line argument of Link Combiner. To know what a good value would be, you can observer the Ping time and Rx messages/s of the links in the new Link page of the notebook. Calculate the minimum buffer size by taking the difference between the largest ping time and the smallest ping time and multiplying it by the largest Rx messages/s. Then apply a safety factor when setting the buffer size - 10 times the calculated value should be good.<br />
* A message won't be sent when it should be if the autopilot sends a message that's the same as one it already sent (same name and exact same values) AND one or more links were lost between the first message and the second AND the link that's receiving the second message doesn't have the first message in it's buffer still. That's three conditions. If this happens, then the Link Combiner will see the second message as a duplicate of the first and will skip it. Only this one message will be missed though - it won't start happening to all messages. Also, the data will have been data that was already received. So if it's for example the battery voltage message, then it's not a big deal to miss it. As long as there aren't links rapidly being lost and gained, then this shouldn't happen often. Note that as the buffer size is increased, it is believed that this becomes more likely to happen.<br />
<br />
== Ground to Aircraft ==<br />
<br />
This part of the redundant communication system hasn't been implemented yet. All information here is what it is envisioned to look like.<br />
<br />
===Features===<br />
* Enable multiple datalink links to be used for communicating with the autopilot.<br />
* Let different telemetry be sent out each link.<br />
* Let the choice of what telemetry is sent be moved from the settings page of the GCS to the Link page, since it can be different for each link.<br />
* Add a link status indicator (this is the light that turns red when the link is lost) for the datalink to the Link page. This will allow better monitoring of the links by not assuming that if one direction is good, the other direction is good as well.<br />
* Let each link be configured as telemetry only, datalink only, or by-directional.<br />
<br />
===Compatibility===<br />
Communication in the autopilot is enabled with the ground by including the telemetry subsystem in the airframe file. For example:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing or rotorcraft"><br />
...<br />
<subsystem name="telemetry" type="transparent"/><br />
</firmware><br />
</source><br />
}}<br />
<br />
In order to use multiple links, changes should be made to allow a telemetry subsystem for each link. Related to this, would it be advantageous to have multiple instances be supported for each different subsystem? Once the design for this is determined, would actual support for each subsystem have to be added one at a time? Because of the logic for how multiple subsystems should behave together is dependent on the subsystem, this might be the case. The telemetry subsystem for example should default to sending telemetry out each one and combining the telemetry received.<br />
<br />
===Hardware===<br />
Unlike aircraft to ground redundancy, ground to aircraft redundancy requires multiple UART ports in the hardware of the autopilot. The author is not particularly familiar with this, but believes that there are ways to get multiple UART ports for this purpose:<br />
* Telemetry can be sent out over USB by specifying the telemetry type to be "transparent_usb".<br />
* For the Lisa/M, the USB port can actually be used as a UART port with some hardware modifications.<br />
* Using an I2C GPS instead of a UART one can free up a UART port on most autopilots.<br />
* For the Lisa/M, can UART 1 and 5 be used if Spektrum Satellite receivers aren't used? If so, where are the Tx pins?<br />
<br />
In addition, future hardware designs could includes more UART ports for redundant communications or any other purpose.<br />
<br />
===Design===<br />
Unlike the aircraft to ground communication, for ground to aircraft communication it is not acceptable to have the same message be acted on twice. This could cause the aircraft to behave unexpectedly. In order to implement a 100% guaranteed link combiner for the aircraft, the author proposes a system that adds a counter to each message sent to the aircraft. This would allow the autopilot to easily ignore identical messages - they'll have the same value for the counter. Also, since minimal data is sent from the ground to the aircraft, adding the extra bytes to the payload will have a minimal impact on performance - this is not the case for the telemetry.<br />
<br />
The challenging part of this design will be integrating it properly into the existing systems.<br />
<br />
[[Category:Tools]]</div>Camleehttp://wiki.paparazziuav.org/w/index.php?title=Redundant_Communication&diff=14982Redundant Communication2013-04-28T05:33:42Z<p>Camlee: </p>
<hr />
<div><div style="float: right; width: 15%"><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Tools</categorytree></div><br />
<div style="float: right; width: 45%; overflow: hidden">[[Image:link_page.png|center|397px|Link Page in GCS]]</div><br />
<div style="float: right; width: 40%">__TOC__</div><br />
<br />
There is currently a pull request to integrate a redundant communication system into the existing ground segment agents: [https://github.com/paparazzi/paparazzi/pull/429 github.com/paparazzi/paparazzi/pull/429]. The goal of this project is to allow multiple radio modems or other links be used between the aircraft and the ground station in a redundant fashion so that even if one link is lost, communication can be maintained. So far, the aircraft to ground component has been created and tested in the lab. More comprehensive testing should be performed before the system is considered to be stable. The ground to aircraft component has not been created yet.<br />
<br />
===Reasons to redundant links===<br />
Communication from the aircraft to the ground is called telemetry. This communication allows the status of the aircraft such as location, altitude, airspeed, battery level, current flight block, and much more to be monitored in real time. Communication from the ground to the aircraft is called datalink. This communication allows commands to be sent to the aircraft from the ground. This includes telling the aircraft what navigation to perform: fly to a waypoint, start the search area, come in for a landing. If a single link is used, as was always the case before this project, then if the aircraft goes out of range, or that link is otherwise lost, no telemetry information can be displayed in the GCS and commands sent from the GCS won't be received by the aircraft. Using the following redundant link system allows multiple links to be used in an effort to avoid this. Typically, you would introduce diversity when adding links. For example:<br />
* If you have an on-board computer, you could tunnel messages through Wi-Fi over UDP in addition to a traditional 900 MHz XBee radio modem.<br />
* You could use a satellite modem for long-range monitoring in addition to a radio modem.<br />
* You could use a cellular modem in addition to a radio modem.<br />
* With additional ground infrastructure, you could have radio modems located at different locations.<br />
* You could use radio modems at different frequencies or with different antenna gains or orientations.<br />
* You could use this system to evaluate different types of radio modems or antenna placements - you'll get real time info on each such as the ping time, received messages rate, and more information could easily be added.<br />
<br />
There are undoubtedly many more possibilities.<br />
<br />
== Aircraft to Ground ==<br />
<br />
===Compatibility===<br />
This project was made to be fully backwards compatible and support the awesome functionality that Paparazzi already has. This includes:<br />
* Completely backwards compatible - includes aircraft configuration files, previous flight logs, existing sessions, etc...<br />
* Logging and replay - if multiple links are used, data received through either link is recorded. Also, replays will include the status of each link as it was during the flight.<br />
* Link features such as USB-serial, audio, UDP, different transport layers, etc...<br />
* Multi-aircraft sessions - also, you can use redundant links for one aircraft, but not for another if desired.<br />
* Multiple aircraft connected to the same link - such as might come up in a mesh configuration where one aircraft relays data from another aircraft.<br />
<br />
===Features===<br />
Enabling redundant communication from the aircraft to the ground enables the following features:<br />
* Redundancy - as long as one link is receiving data, it will be logged and displayed on the GCS.<br />
* Monitoring - the status, ping time, and rate of receiving messages for each link is shown (this makes it useful even if you're only using one link).<br />
* Alerts - new alerts are added to the console in the GCS to alert you when a link has been connected for the first time, lost, or re-gained.<br />
<br />
===Future Improvements===<br />
Several different improvements can be made to this system to improve it's performance and help satisfy future needs that may arise:<br />
* Additional information can easily be added to the Link page of the GCS for each link. For example: errors, % uptime, or a scrolling graph of Rx messages/s.<br />
* The ability to mark different links as either critical or backup. The idea here is that not all links should necessarily be treated equal. Maybe only one link is able to send datalink data to the aircraft (actually, this is the case right now) and so that link should be considered critical. If any other link is lost, then the overall telemetry can be counted as OK. But if the critical link is lost, then the GCS should change the link indicator light to red and start counting up even if the other link(s) are OK.<br />
* The Link Combiner algorithm currently employs a simple circular buffer. This could be improved on by adding a time-stamp to each element of the buffer and only counting two buffer elements to be the same if their timestamps are close enough (say within 2 seconds - this could be configured)<br />
* The Link Combiner algorithm could be improved by making the buffer size adjust automatically with the ping time and Rx messages/s rate. Or if the timestamp improvement is implemented, then the maximum time difference could be adjusted.<br />
* A performance and resource use analysis could be done to optimize the Link Combiner. The circular buffer is currently implemented using Python lists which could probably be improved upon. Also, significantly more ivy messages are sent and received. This might make optimizations to the regex or other parts of the ivybus worthwhile.<br />
<br />
===How to use===<br />
<br />
For an example using two USB-serial adaptors, see the '''Flight USB-serial Redundant''' session saved in the example control_panel.xml configuration (on master branch, once the pull request has been accepted).<br />
<br />
For the details, keep reading:<br />
In order to implement redundant links using this code, there are three simple steps to follow:<br />
<br />
* Connect the hardware - on the airborne side, connect the Rx pin of the autopilot's UART port to multiple radio modems or whatever other device which will get the information to the ground. On the ground side, connect multiple modems as normal (using USB to serial adapters, a UDP connection, or whatever). (note: Once the ground to aircraft redundancy has been implemented, you won't have to split the Rx signal and can just plug each modem into a UART port)<br />
* Launch a Link agent for each modem (in Paparazzi Center, select it from the tools menu). Configure the agents as you would have before (serial port, baud rate, UDP, etc...). None of these features have been modified or removed. Then, use two new command line arguments: -redlink and -id. The -redlink flag tells Link that it's one of multiple links. The -id flag lets you specify an integer number as the id of that particular link.<br />
* Launch the Link Combiner agent (again, from the tools menu). This agent listens to all of the Link agents that have their -redlink set and combines the data.<br />
<br />
The following screenshot shows a session with two links, connected to serial ports ttyUSB0 and ttyUSB1, and with id's 1 and 2:<br />
<br />
[[File:redundant_session.png|alt=Agents in Redundant Link Session|700px|thumb|center|The Agents Running in a Redundant Link Setup]]<br />
<br style="clear:both"><br />
<br />
* Test the system and make sure that it works correctly under all circumstances. Do this before flying. In particular, make sure that the buffer size if appropriate. Take a look at the [[#Algorithm Considerations|Algorithm Considerations]] section for details.<br />
<br />
===Interface===<br />
Once the redundant link system is started (even if only one Link is used), several changes appear in the GCS. This is achieved by the new message LINK_STATUS which is sent by the Link Combiner. These new features are designed to allow closer monitoring and better management of the link(s) between the aircraft and the ground station.<br />
<br />
The following screenshot clearly shows these changes:<br />
[[File:redundant_link_gcs.png|alt=Changes to the GCS when redundant links are used|1000px|thumb|center|Screenshot of the GCS with multiple links]]<br />
<br style="clear:both"><br />
<br />
Firstly, we can see that there is a new page in the notebook named Link. This page contains critical information for each link. More information can easily be added, but for now, it shows the status of the link (just like the main Link status indicator in the strip), the current ping time, and the rate of received messages. So if one link is lost, it's status indicator will turn red and start counting up just like link 2 in the above screenshot.<br />
<br />
Next, we can see that the main Link status indicator that's located in the strip has been modified slightly. It now shows the ratio of connected links to the total number of links. I.e. 3/4 means that there are four links and one of them has been lost. Furthermore, the indicator will be green if all links are connected, yellow if one or more are lost, and red if all links are lost. Once all links are lost, the indicator will count up just like before.<br />
<br />
Lastly, alerts have been added to the console. Whenever a link is lost or reconnected, a message will appear in the console stating so. Messages also appear when a new link is added.<br />
<br />
===Design===<br />
====Implementation====<br />
Here's a block diagram showing how the aircraft talks to the various ground segment programs (also known as agents) when not using the redundant link system:<br />
<br />
[[File:ground_segment_block_diagram.png|alt=Block diagram of agents in the ground segment|500px|thumb|center|Paparazzi Ground Segment]]<br />
<br style="clear:both"><br />
<br />
The ivy bus lets the programs talk to each other through the use of short messages. Pay close attention to the coloured arrows, which show the main flow of these messages. Next we have a block diagram of the redundant link system:<br />
<br />
[[File:redundant_links_block_diagram.png|alt=Block diagram of agents in the ground segment when redundant links are used|800px|thumb|center|Paparazzi Ground Segment with Redundant Links]]<br />
<br style="clear:both"><br />
<br />
<br />
Here we can see the new agent, the Link Combiner. We also see multiple occurrences of the Link agent. When operating in redundant mode, each occurrence of Link transmits the data it receives from the aircraft to the Link Combiner instead of the Server. It does this by transmitting the received telemetry messages within the TELEMETRY_MESSAGE message which the Server doesn't listen to. The Link Combiner on the other hand does. TELEMETRY_MESSAGE messages are sent by each link and include the id of that link. The Link Combiner listens to all of them and then transmits a single set of messages to the Server with the combined data. This results in the Server and all other ground segment agents (such as Messages and the Real Time Plotter) getting their telemetry data from Link Combiner as if it was coming from a single occurrence of Link.<br />
<br />
====Link Combiner====<br />
The Link Combiner agent is written in Python. It receives messages from all of the Links (when they're in redundant mode: -redlink), and outputs messages to the Server and other ground segment agents. There is a bit involved however since the Server and GCS shouldn't be sent identical messages. I.e. if the aircraft sends a message and it's received successfully by more than one link, then that particular message should only sent by Link Combiner once. This is a somewhat tricky requirement since there is no guarantee that the message will be received by all of the links, and it's possible that the aircraft actually sends a second message that's exactly the same as the first. No extra info (such as a time-stamp or counter) is added to the messages sent from the aircraft to the ground, so the Link Combiner employs an algorithm to detect duplicate messages. Testing has shown that for typical links, this algorithm performs extremely well.<br />
<br />
The algorithm gives each link a circular buffer to store the last N messages. When a new message comes in on a particular link, the algorithm first checks if it's already in that link's buffer. If it is, then it's obviously a new message, so its removed from all of the other buffers if it's in any of them. Then, the message is sent to the other agents. If the message isn't already in the link's buffer, then it's added to the buffer. After that, all of the other link's buffers are checked for the message. If it's in any of them, then the message was already received by another link, so isn't sent. If it's not in any of them, then the message is sent. The following flowchart depicts this algorithm:<br />
<br />
[[File:link_combiner_flowchart.png|alt=Flowchart of the Link Combiner|500px|thumb|center|Algorithm to prevent duplicate messages]]<br />
<br style="clear:both"><br />
<br />
====Algorithm Considerations====<br />
As the aircraft sends various messages, possibly with the exact same data, and the links gain and lose connection, there is no guarantee that this algorithm will do a perfect job of filtering out identical and only identical messages. However, in typical operation, it seems to work very well. And for the application of displaying aircraft data, the occasional missing or duplicate message is acceptable. There are only a few scenarios where the Link Combiner won't produce perfect results, and they should come up infrequently:<br />
<br />
* A message will be sent twice if the buffer size is too small to hold all of the messages received from one link between that link receiving the message and another link receiving the identical message. When the second link receives the message that has already been received, if the original isn't in the buffer anymore, than the algorithm won't know it's a duplicate message. This scenario should be considered whenever implementing a redundant link system. Partly because it is the most likely to come up, but also because if it does occur, then all messages will be duplicated. In order to avoid this scenario, you can set the buffer size as a command line argument of Link Combiner. To know what a good value would be, you can observer the Ping time and Rx messages/s of the links in the new Link page of the notebook. Calculate the minimum buffer size by taking the difference between the largest ping time and the smallest ping time and multiplying it by the largest Rx messages/s. Then apply a safety factor when setting the buffer size - 10 times the calculated value should be good.<br />
* A message won't be sent when it should be if the autopilot sends a message that's the same as one it already sent (same name and exact same values) AND one or more links were lost between the first message and the second AND the link that's receiving the second message doesn't have the first message in it's buffer still. That's three conditions. If this happens, then the Link Combiner will see the second message as a duplicate of the first and will skip it. Only this one message will be missed though - it won't start happening to all messages. Also, the data will have been data that was already received. So if it's for example the battery voltage message, then it's not a big deal to miss it. As long as there aren't links rapidly being lost and gained, then this shouldn't happen often. Note that as the buffer size is increased, it is believed that this becomes more likely to happen.<br />
<br />
== Ground to Aircraft ==<br />
<br />
This part of the redundant communication system hasn't been implemented yet. All information here is what it is envisioned to look like.<br />
<br />
===Features===<br />
* Enable multiple datalink links to be used for communicating with the autopilot.<br />
* Let different telemetry be sent out each link.<br />
* Let the choice of what telemetry is sent be moved from the settings page of the GCS to the Link page, since it can be different for each link.<br />
* Add a link status indicator (this is the light that turns red when the link is lost) for the datalink to the Link page. This will allow better monitoring of the links by not assuming that if one direction is good, the other direction is good as well.<br />
* Let each link be configured as telemetry only, datalink only, or by-directional.<br />
<br />
===Compatibility===<br />
Communication in the autopilot is enabled with the ground by including the telemetry subsystem in the airframe file. For example:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing or rotorcraft"><br />
...<br />
<subsystem name="telemetry" type="transparent"/><br />
</firmware><br />
</source><br />
}}<br />
<br />
In order to use multiple links, changes should be made to allow a telemetry subsystem for each link. Related to this, would it be advantageous to have multiple instances be supported for each different subsystem? Once the design for this is determined, would actual support for each subsystem have to be added one at a time? Because of the logic for how multiple subsystems should behave together is dependent on the subsystem, this might be the case. The telemetry subsystem for example should default to sending telemetry out each one and combining the telemetry received.<br />
<br />
===Hardware===<br />
Unlike aircraft to ground redundancy, ground to aircraft redundancy requires multiple UART ports in the hardware of the autopilot. The author is not particularly familiar with this, but believes that there are ways to get multiple UART ports for this purpose:<br />
* Telemetry can be sent out over USB by specifying the telemetry type to be "transparent_usb".<br />
* For the Lisa/M, the USB port can actually be used as a UART port with some hardware modifications.<br />
* Using an I2C GPS instead of a UART one can free up a UART port on most autopilots.<br />
* For the Lisa/M, can UART 1 and 5 be used if Spektrum Satellite receivers aren't used? If so, where are the Tx pins?<br />
<br />
In addition, future hardware designs could includes more UART ports for redundant communications or any other purpose.<br />
<br />
===Design===<br />
Unlike the aircraft to ground communication, for ground to aircraft communication it is not acceptable to have the same message be acted on twice. This could cause the aircraft to behave unexpectedly. In order to implement a 100% guaranteed link combiner for the aircraft, the author proposes a system that adds a counter to each message sent to the aircraft. This would allow the autopilot to easily ignore identical messages - they'll have the same value for the counter. Also, since minimal data is sent from the ground to the aircraft, adding the extra bytes to the payload will have a minimal impact on performance - this is not the case for the telemetry.<br />
<br />
The challenging part of this design will be integrating it properly into the existing systems.<br />
<br />
[[Category:Tools]]</div>Camleehttp://wiki.paparazziuav.org/w/index.php?title=Redundant_Communication&diff=14981Redundant Communication2013-04-28T05:31:20Z<p>Camlee: </p>
<hr />
<div><div style="float: right; width: 15%"><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Tools</categorytree></div><br />
<div style="float: right; width: 45%; overflow: hidden">[[Image:link_page.png|center|397px|Link Page in GCS]]</div><br />
<div style="float: right; width: 40%">__TOC__</div><br />
<br />
There is currently a pull request to integrate a redundant communication system into the existing ground segment agents: [https://github.com/paparazzi/paparazzi/pull/429 github.com/paparazzi/paparazzi/pull/429]. The goal of this project is to allow multiple radio modems or other links be used between the aircraft and the ground station in a redundant fashion so that even if one link is lost, communication can be maintained. So far, the aircraft to ground component has been created and tested in the lab. More comprehensive testing should be performed before the system is considered to be stable. The ground to aircraft component has not been created yet.<br />
<br />
===Reasons to redundant links===<br />
Communication from the aircraft to the ground is called telemetry. This communication allows the status of the aircraft such as location, altitude, airspeed, battery level, current flight block, and much more to be monitored in real time. Communication from the ground to the aircraft is called datalink. This communication allows commands to be sent to the aircraft from the ground. This includes telling the aircraft what navigation to perform: fly to a waypoint, start the search area, come in for a landing. If a single link is used, as was always the case before this project, then if the aircraft goes out of range, or that link is otherwise lost, no telemetry information can be displayed in the GCS and commands sent from the GCS won't be received by the aircraft. Using the following redundant link system allows multiple links to be used in an effort to avoid this. Typically, you would introduce diversity when adding links. For example:<br />
* If you have an on-board computer, you could tunnel messages through Wi-Fi over UDP in addition to a traditional 900 MHz XBee radio modem.<br />
* You could use a satellite modem for long-range monitoring in addition to a radio modem.<br />
* You could use a cellular modem in addition to a radio modem.<br />
* With additional ground infrastructure, you could have radio modems located at different locations.<br />
* You could use radio modems at different frequencies or with different antenna gains or orientations.<br />
* You could use this system to evaluate different types of radio modems or antenna placements - you'll get real time info on each such as the ping time, received messages rate, and more information could easily be added.<br />
<br />
There are undoubtedly many more possibilities.<br />
<br />
== Aircraft to Ground ==<br />
<br />
===Compatibility===<br />
This project was made to be fully backwards compatible and support the awesome functionality that Paparazzi already has. This includes:<br />
* Completely backwards compatible - includes aircraft configuration files, previous flight logs, existing sessions, etc...<br />
* Logging and replay - if multiple links are used, data received through either link is recorded. Also, replays will include the status of each link as it was during the flight.<br />
* Link features such as USB-serial, audio, UDP, different transport layers, etc...<br />
* Multi-aircraft sessions - also, you can use redundant links for one aircraft, but not for another if desired.<br />
* Multiple aircraft connected to the same link - such as might come up in a mesh configuration where one aircraft relays data from another aircraft.<br />
<br />
===Features===<br />
Enabling redundant communication from the aircraft to the ground enables the following features:<br />
* Redundancy - as long as one link is receiving data, it will be logged and displayed on the GCS.<br />
* Monitoring - the status, ping time, and rate of receiving messages for each link is shown (this makes it useful even if you're only using one link).<br />
* Alerts - new alerts are added to the console in the GCS to alert you when a link has been connected for the first time, lost, or re-gained.<br />
<br />
===Future Improvements===<br />
Several different improvements can be made to this system to improve it's performance and help satisfy future needs that may arise:<br />
* Additional information can easily be added to the Link page of the GCS for each link. For example: errors, % uptime, or a scrolling graph of Rx messages/s.<br />
* The ability to mark different links as either critical or backup. The idea here is that not all links should necessarily be treated equal. Maybe only one link is able to send datalink data to the aircraft (actually, this is the case right now) and so that link should be considered critical. If any other link is lost, then the overall telemetry can be counted as OK. But if the critical link is lost, then the GCS should change the link indicator light to red and start counting up even if the other link(s) are OK.<br />
* The Link Combiner algorithm currently employs a simple circular buffer. This could be improved on by adding a time-stamp to each element of the buffer and only counting two buffer elements to be the same if their timestamps are close enough (say within 2 seconds - this could be configured)<br />
* The Link Combiner algorithm could be improved by making the buffer size adjust automatically with the ping time and Rx messages/s rate. Or if the timestamp improvement is implemented, then the maximum time difference could be adjusted.<br />
* A performance and resource use analysis could be done to optimize the Link Combiner. The circular buffer is currently implemented using Python lists which could probably be improved upon. Also, significantly more ivy messages are sent and received. This might make optimizations to the regex or other parts of the ivybus worthwhile.<br />
<br />
===How to use===<br />
<br />
For an example using two USB-serial adaptors, see the '''Flight USB-serial Redundant''' session saved in the example control_panel.xml configuration (on master branch, once the pull request has been accepted).<br />
<br />
For the details, keep reading:<br />
In order to implement redundant links using this code, there are three simple steps to follow:<br />
<br />
* Connect the hardware - on the airborne side, connect the Rx pin of the autopilot's UART port to multiple radio modems or whatever other device which will get the information to the ground. On the ground side, connect multiple modems as normal (using USB to serial adapters, a UDP connection, or whatever). (note: Once the ground to aircraft redundancy has been implemented, you won't have to split the Rx signal and can just plug each modem into a UART port)<br />
* Launch a Link agent for each modem (in Paparazzi Center, select it from the tools menu). Configure the agents as you would have before (serial port, baud rate, UDP, etc...). None of these features have been modified or removed. Then, use two new command line arguments: -redlink and -id. The -redlink flag tells Link that it's one of multiple links. The -id flag lets you specify an integer number as the id of that particular link.<br />
* Launch the Link Combiner agent (again, from the tools menu). This agent listens to all of the Link agents that have their -redlink set and combines the data.<br />
<br />
The following screenshot shows a session with two links, connected to serial ports ttyUSB0 and ttyUSB1, and with id's 1 and 2:<br />
<br />
[[File:redundant_session.png|alt=Agents in Redundant Link Session|700px|thumb|center|The Agents Running in a Redundant Link Setup]]<br />
<br style="clear:both"><br />
<br />
* Test the system and make sure that it works correctly under all circumstances. Do this before flying. In particular, make sure that the buffer size if appropriate. Take a look at the [[#Algorithm Considerations|Algorithm Considerations]] section for details.<br />
<br />
===Interface===<br />
Once the redundant link system is started (even if only one Link is used), several changes appear in the GCS. This is achieved by the new message LINK_STATUS which is sent by the Link Combiner. These new features are designed to allow closer monitoring and better management of the link(s) between the aircraft and the ground station.<br />
<br />
The following screenshot clearly shows these changes:<br />
[[File:redundant_link_gcs.png|alt=Changes to the GCS when redundant links are used|1000px|thumb|center|Screenshot of the GCS with multiple links]]<br />
<br style="clear:both"><br />
<br />
Firstly, we can see that there is a new page in the notebook named Link. This page contains critical information for each link. More information can easily be added, but for now, it shows the status of the link (just like the main Link status indicator in the strip), the current ping time, and the rate of received messages. So if one link is lost, it's status indicator will turn red and start counting up just like link 2 in the above screenshot.<br />
<br />
Next, we can see that the main Link status indicator that's located in the strip has been modified slightly. It now shows the ratio of connected links to the total number of links. I.e. 3/4 means that there are four links and one of them has been lost. Furthermore, the indicator will be green if all links are connected, yellow if one or more are lost, and red if all links are lost. Once all links are lost, the indicator will count up just like before.<br />
<br />
Lastly, alerts have been added to the console. Whenever a link is lost or reconnected, a message will appear in the console stating so. Messages also appear when a new link is added.<br />
<br />
===Design===<br />
====Implementation====<br />
Here's a block diagram showing how the aircraft talks to the various ground segment programs (also known as agents) when not using the redundant link system:<br />
<br />
[[File:ground_segment_block_diagram.png|alt=Block diagram of agents in the ground segment|500px|thumb|center|Paparazzi Ground Segment]]<br />
<br style="clear:both"><br />
<br />
The ivy bus lets the programs talk to each other through the use of short messages. Pay close attention to the coloured arrows, which show the main flow of these messages. Next we have a block diagram of the redundant link system:<br />
<br />
[[File:redundant_links_block_diagram.png|alt=Block diagram of agents in the ground segment when redundant links are used|800px|thumb|center|Paparazzi Ground Segment with Redundant Links]]<br />
<br style="clear:both"><br />
<br />
<br />
Here we can see the new agent, the Link Combiner. We also see multiple occurrences of the Link agent. When operating in redundant mode, each occurrence of Link transmits the data it receives from the aircraft to the Link Combiner instead of the Server. It does this by transmitting the received telemetry messages within the TELEMETRY_MESSAGE message which the Server doesn't listen to. The Link Combiner on the other hand does. TELEMETRY_MESSAGE messages are sent by each link and include the id of that link. The Link Combiner listens to all of them and then transmits a single set of messages to the Server with the combined data. This results in the Server and all other ground segment agents (such as Messages and the Real Time Plotter) getting their telemetry data from Link Combiner as if it was coming from a single occurrence of Link.<br />
<br />
====Link Combiner====<br />
The Link Combiner agent is written in Python. It receives messages from all of the Links (when they're in redundant mode: -redlink), and outputs messages to the Server and other ground segment agents. There is a bit involved however since the Server and GCS shouldn't be sent identical messages. I.e. if the aircraft sends a message and it's received successfully by more than one link, then that particular message should only sent by Link Combiner once. This is a somewhat tricky requirement since there is no guarantee that the message will be received by all of the links, and it's possible that the aircraft actually sends a second message that's exactly the same as the first. No extra info (such as a time-stamp or counter) is added to the messages sent from the aircraft to the ground, so the Link Combiner employs an algorithm to detect duplicate messages. Testing has shown that for typical links, this algorithm performs extremely well.<br />
<br />
The algorithm gives each link a circular buffer to store the last N messages. When a new message comes in on a particular link, the algorithm first checks if it's already in that link's buffer. If it is, then it's obviously a new message, so its removed from all of the other buffers if it's in any of them. Then, the message is sent to the other agents. If the message isn't already in the link's buffer, then it's added to the buffer. After that, all of the other link's buffers are checked for the message. If it's in any of them, then the message was already received by another link, so isn't sent. If it's not in any of them, then the message is sent. The following flowchart depicts this algorithm:<br />
<br />
[[File:link_combiner_flowchart.png|alt=Flowchart of the Link Combiner|500px|thumb|center|Algorithm to prevent duplicate messages]]<br />
<br style="clear:both"><br />
<br />
====Algorithm Considerations====<br />
As the aircraft sends various messages, possibly with the exact same data, and the links gain and lose connection, there is no guarantee that this algorithm will do a perfect job of filtering out identical and only identical messages. However, in typical operation, it seems to work very well. And for the application of displaying aircraft data, the occasional missing or duplicate message is acceptable. There are only a few scenarios where the Link Combiner won't produce perfect results, and they should come up infrequently:<br />
<br />
* A message will be sent twice if the buffer size is too small to hold all of the messages received from one link between that link receiving the message and another link receiving the identical message. When the second link receives the message that has already been received, if the original isn't in the buffer anymore, than the algorithm won't know it's a duplicate message. This scenario should be considered whenever implementing a redundant link system. Partly because it is the most likely to come up, but also because if it does occur, then all messages will be duplicated. In order to avoid this scenario, you can set the buffer size as a command line argument of Link Combiner. To know what a good value would be, you can observer the Ping time and Rx messages/s of the links in the new Link page of the notebook. Calculate the minimum buffer size by taking the difference between the largest ping time and the smallest ping time and multiplying it by the largest Rx messages/s. Then apply a safety factor when setting the buffer size - 10 times the calculated value should be good.<br />
* A message won't be sent when it should be if the autopilot sends a message that's the same as one it already sent (same name and exact same values) AND one or more links were lost between the first message and the second AND the link that's receiving the second message doesn't have the first message in it's buffer still. That's three conditions. If this happens, then the Link Combiner will see the second message as a duplicate of the first and will skip it. Only this one message will be missed though - it won't start happening to all messages. Also, the data will have been data that was already received. So if it's for example the battery voltage message, then it's not a big deal to miss it. As long as there aren't links rapidly being lost and gained, then this shouldn't happen often. Note that as the buffer size is increased, it is believed that this becomes more likely to happen.<br />
<br />
== Ground to Aircraft ==<br />
<br />
This part of the redundant communication system hasn't been implemented yet. All information here is what it is envisioned to look like.<br />
<br />
===Features===<br />
* Enable multiple datalink links to be used for communicating with the autopilot.<br />
* Let different telemetry be sent out each link.<br />
* Let the choice of what telemetry is sent be moved from the settings page of the GCS to the Link page, since it can be different for each link.<br />
* Add a link status indicator (this is the light that turns red when the link is lost) for the datalink to the Link page. This will allow better monitoring of the links by not assuming that if one direction is good, the other direction is good as well.<br />
* Let each link be configured as telemetry only, datalink only, or by-directional.<br />
<br />
===Compatibility===<br />
Communication in the autopilot is enabled with the ground by including the telemetry subsystem in the airframe file. For example:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing or rotorcraft"><br />
...<br />
<subsystem name="telemetry" type="transparent"/><br />
</firmware><br />
</source><br />
}}<br />
<br />
In order to use multiple links, changes should be made to allow a telemetry subsystem for each link. Related to this, would it be advantageous to have multiple instances be supported for each different subsystem? Once the design for this is determined, would actual support for each subsystem have to be added one at a time? Because of the logic for how multiple subsystems should behave together is dependent on the subsystem, this might be the case. The telemetry subsystem for example should default to sending telemetry out each one and combining the telemetry received.<br />
<br />
===Hardware===<br />
Unlike aircraft to ground redundancy, ground to aircraft redundancy requires multiple UART ports in the hardware of the autopilot. The author is not particularly familiar with this, but believes that there are ways to get multiple UART ports for this purpose:<br />
* Telemetry can be sent out over USB by specifying the telemetry type to be "transparent_usb".<br />
* For the Lisa/M, the USB port can actually be used as a UART port with some hardware modifications.<br />
* Using an I2C GPS instead of a UART one can free up a UART port on most autopilots.<br />
* For the Lisa/M, can UART 1 and 5 be used if Spektrum Satellite receivers aren't used? If so, where are the Tx pins?<br />
<br />
In addition, future hardware designs could includes more UART ports for redundant communications or any other purpose.<br />
<br />
===Design===<br />
Unlike the aircraft to ground communication, for ground to aircraft communication it is not acceptable to have the same message be acted on twice. This could cause the aircraft to behave unexpectedly. In order to implement a 100% guaranteed link combiner for the aircraft, the author proposes a system that adds a counter to each message sent to the aircraft. This would allow the autopilot to easily ignore identical messages - they'll have the same value for the counter. Also, since minimal data is sent from the ground to the aircraft, adding the extra bytes to the payload will have a minimal impact on performance - this is not the case for the telemetry.<br />
<br />
The challenging part of this design will be integrating it properly into the existing systems.</div>Camleehttp://wiki.paparazziuav.org/w/index.php?title=Redundant_Communication&diff=14980Redundant Communication2013-04-28T05:25:18Z<p>Camlee: </p>
<hr />
<div><div style="float: right; width: 15%"><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Tools</categorytree></div><br />
<div style="float: right; width: 45%; overflow: hidden">[[Image:link_page.png|center|397px|Link Page in GCS]]</div><br />
<div style="float: right; width: 40%">__TOC__</div><br />
<br />
There is currently a pull request to integrate a redundant communication system into the existing ground segment agents: [https://github.com/paparazzi/paparazzi/pull/429 github.com/paparazzi/paparazzi/pull/429]. The goal of this project is to allow multiple radio modems or other links be used between the aircraft and the ground station in a redundant fashion so that even if one link is lost, communication can be maintained. So far, the aircraft to ground component has been created and tested in the lab. More comprehensive testing should be performed before the system is considered to be stable. The ground to aircraft component has not been created yet.<br />
<br />
===Reasons to redundant links===<br />
Communication from the aircraft to the ground is called telemetry. This communication allows the status of the aircraft such as location, altitude, airspeed, battery level, current flight block, and much more to be monitored in real time. Communication from the ground to the aircraft is called datalink. This communication allows commands to be sent to the aircraft from the ground. This includes telling the aircraft what navigation to perform: fly to a waypoint, start the search area, come in for a landing. If a single link is used, as was always the case before this project, then if the aircraft goes out of range, or that link is otherwise lost, no telemetry information can be displayed in the GCS and commands sent from the GCS won't be received by the aircraft. Using the following redundant link system allows multiple links to be used in an effort to avoid this. Typically, you would introduce diversity when adding links. For example:<br />
* If you have an on-board computer, you could tunnel messages through Wi-Fi over UDP in addition to a traditional 900 MHz XBee radio modem.<br />
* You could use a satellite modem for long-range monitoring in addition to a radio modem.<br />
* You could use a cellular modem in addition to a radio modem.<br />
* With additional ground infrastructure, you could have radio modems located at different locations.<br />
* You could use radio modems at different frequencies or with different antenna gains or orientations.<br />
* You could use this system to evaluate different types of radio modems or antenna placements - you'll get real time info on each such as the ping time, received messages rate, and more information could easily be added.<br />
<br />
There are undoubtedly many more possibilities.<br />
<br />
== Aircraft to Ground ==<br />
<br />
===Compatibility===<br />
This project was made to be fully backwards compatible and support the awesome functionality that Paparazzi already has. This includes:<br />
* Completely backwards compatible - includes aircraft configuration files, previous flight logs, existing sessions, etc...<br />
* Logging and replay - if multiple links are used, data received through either link is recorded. Also, replays will include the status of each link as it was during the flight.<br />
* Link features such as USB-serial, audio, UDP, different transport layers, etc...<br />
* Multi-aircraft sessions - also, you can use redundant links for one aircraft, but not for another if desired.<br />
* Multiple aircraft connected to the same link - such as might come up in a mesh configuration where one aircraft relays data from another aircraft.<br />
<br />
===Features===<br />
Enabling redundant communication from the aircraft to the ground enables the following features:<br />
* Redundancy - as long as one link is receiving data, it will be logged and displayed on the GCS.<br />
* Monitoring - the status, ping time, and rate of receiving messages for each link is shown (this makes it useful even if you're only using one link).<br />
* Alerts - new alerts are added to the console in the GCS to alert you when a link has been connected for the first time, lost, or re-gained.<br />
<br />
===Future Improvements===<br />
Several different improvements can be made to this system to improve it's performance and help satisfy future needs that may arise:<br />
* Additional information can easily be added to the Link page of the GCS for each link. For example: errors, % uptime, or a scrolling graph of Rx messages/s.<br />
* The ability to mark different links as either critical or backup. The idea here is that not all links should necessarily be treated equal. Maybe only one link is able to send datalink data to the aircraft (actually, this is the case right now) and so that link should be considered critical. If any other link is lost, then the overall telemetry can be counted as OK. But if the critical link is lost, then the GCS should change the link indicator light to red and start counting up even if the other link(s) are OK.<br />
* The Link Combiner algorithm currently employs a simple circular buffer. This could be improved on by adding a time-stamp to each element of the buffer and only counting two buffer elements to be the same if their timestamps are close enough (say within 2 seconds - this could be configured)<br />
* The Link Combiner algorithm could be improved by making the buffer size adjust automatically with the ping time and Rx messages/s rate. Or if the timestamp improvement is implemented, then the maximum time difference could be adjusted.<br />
* A performance and resource use analysis could be done to optimize the Link Combiner. The circular buffer is currently implemented using Python lists which could probably be improved upon. Also, significantly more ivy messages are sent and received. This might make optimizations to the regex or other parts of the ivybus worthwhile.<br />
<br />
===How to use===<br />
<br />
For an example using two USB-serial adaptors, see the '''Flight USB-serial Redundant''' session saved in the example control_panel.xml configuration (on master branch, once the pull request has been accepted).<br />
<br />
For the details, keep reading:<br />
In order to implement redundant links using this code, there are three simple steps to follow:<br />
<br />
* Connect the hardware - on the airborne side, connect the Rx pin of the autopilot's UART port to multiple radio modems or whatever other device which will get the information to the ground. On the ground side, connect multiple modems as normal (using USB to serial adapters, a UDP connection, or whatever). (note: Once the ground to aircraft redundancy has been implemented, you won't have to split the Rx signal and can just plug each modem into a UART port)<br />
* Launch a Link agent for each modem (in Paparazzi Center, select it from the tools menu). Configure the agents as you would have before (serial port, baud rate, UDP, etc...). None of these features have been modified or removed. Then, use two new command line arguments: -redlink and -id. The -redlink flag tells Link that it's one of multiple links. The -id flag lets you specify an integer number as the id of that particular link.<br />
* Launch the Link Combiner agent (again, from the tools menu). This agent listens to all of the Link agents that have their -redlink set and combines the data.<br />
<br />
The following screenshot shows a session with two links, connected to serial ports ttyUSB0 and ttyUSB1, and with id's 1 and 2:<br />
<br />
[[File:redundant_session.png|alt=Agents in Redundant Link Session|700px|The Agents Running in a Redundant Link Setup]]<br />
<br />
* Test the system and make sure that it works correctly under all circumstances. Do this before flying. In particular, make sure that the buffer size if appropriate. Take a look at the [[#Algorithm Considerations|Algorithm Considerations]] section for details.<br />
<br />
===Interface===<br />
Once the redundant link system is started (even if only one Link is used), several changes appear in the GCS. This is achieved by the new message LINK_STATUS which is sent by the Link Combiner. These new features are designed to allow closer monitoring and better management of the link(s) between the aircraft and the ground station.<br />
<br />
The following screenshot clearly shows these changes:<br />
[[File:redundant_link_gcs.png|alt=Changes to the GCS when redundant links are used|1000px]]<br />
<br />
Firstly, we can see that there is a new page in the notebook named Link. This page contains critical information for each link. More information can easily be added, but for now, it shows the status of the link (just like the main Link status indicator in the strip), the current ping time, and the rate of received messages. So if one link is lost, it's status indicator will turn red and start counting up just like link 2 in the above screenshot.<br />
<br />
Next, we can see that the main Link status indicator that's located in the strip has been modified slightly. It now shows the ratio of connected links to the total number of links. I.e. 3/4 means that there are four links and one of them has been lost. Furthermore, the indicator will be green if all links are connected, yellow if one or more are lost, and red if all links are lost. Once all links are lost, the indicator will count up just like before.<br />
<br />
Lastly, alerts have been added to the console. Whenever a link is lost or reconnected, a message will appear in the console stating so. Messages also appear when a new link is added.<br />
<br />
===Design===<br />
====Implementation====<br />
Here's a block diagram showing how the aircraft talks to the various ground segment programs (also known as agents) when not using the redundant link system:<br />
<br />
[[File:ground_segment_block_diagram.png|alt=Block diagram of agents in the ground segment|500px|Paparazzi Ground Segment]]<br />
<br />
The ivy bus lets the programs talk to each other through the use of short messages. Pay close attention to the coloured arrows, which show the main flow of these messages. Next we have a block diagram of the redundant link system:<br />
<br />
[[File:redundant_links_block_diagram.png|alt=Block diagram of agents in the ground segment when redundant links are used|800px|Paparazzi Ground Segment with Redundant Links]]<br />
<br />
<br />
Here we can see the new agent, the Link Combiner. We also see multiple occurrences of the Link agent. When operating in redundant mode, each occurrence of Link transmits the data it receives from the aircraft to the Link Combiner instead of the Server. It does this by transmitting the received telemetry messages within the TELEMETRY_MESSAGE message which the Server doesn't listen to. The Link Combiner on the other hand does. TELEMETRY_MESSAGE messages are sent by each link and include the id of that link. The Link Combiner listens to all of them and then transmits a single set of messages to the Server with the combined data. This results in the Server and all other ground segment agents (such as Messages and the Real Time Plotter) getting their telemetry data from Link Combiner as if it was coming from a single occurrence of Link.<br />
<br />
====Link Combiner====<br />
The Link Combiner agent is written in Python. It receives messages from all of the Links (when they're in redundant mode: -redlink), and outputs messages to the Server and other ground segment agents. There is a bit involved however since the Server and GCS shouldn't be sent identical messages. I.e. if the aircraft sends a message and it's received successfully by more than one link, then that particular message should only sent by Link Combiner once. This is a somewhat tricky requirement since there is no guarantee that the message will be received by all of the links, and it's possible that the aircraft actually sends a second message that's exactly the same as the first. No extra info (such as a time-stamp or counter) is added to the messages sent from the aircraft to the ground, so the Link Combiner employs an algorithm to detect duplicate messages. Testing has shown that for typical links, this algorithm performs extremely well.<br />
<br />
The algorithm gives each link a circular buffer to store the last N messages. When a new message comes in on a particular link, the algorithm first checks if it's already in that link's buffer. If it is, then it's obviously a new message, so its removed from all of the other buffers if it's in any of them. Then, the message is sent to the other agents. If the message isn't already in the link's buffer, then it's added to the buffer. After that, all of the other link's buffers are checked for the message. If it's in any of them, then the message was already received by another link, so isn't sent. If it's not in any of them, then the message is sent. The following flowchart depicts this algorithm:<br />
<br />
[[File:link_combiner_flowchart.png|alt=Flowchart of the Link Combiner|500px|Algorithm to prevent duplicate messages]]<br />
<br />
====Algorithm Considerations====<br />
As the aircraft sends various messages, possibly with the exact same data, and the links gain and lose connection, there is no guarantee that this algorithm will do a perfect job of filtering out identical and only identical messages. However, in typical operation, it seems to work very well. And for the application of displaying aircraft data, the occasional missing or duplicate message is acceptable. There are only a few scenarios where the Link Combiner won't produce perfect results, and they should come up infrequently:<br />
<br />
* A message will be sent twice if the buffer size is too small to hold all of the messages received from one link between that link receiving the message and another link receiving the identical message. When the second link receives the message that has already been received, if the original isn't in the buffer anymore, than the algorithm won't know it's a duplicate message. This scenario should be considered whenever implementing a redundant link system. Partly because it is the most likely to come up, but also because if it does occur, then all messages will be duplicated. In order to avoid this scenario, you can set the buffer size as a command line argument of Link Combiner. To know what a good value would be, you can observer the Ping time and Rx messages/s of the links in the new Link page of the notebook. Calculate the minimum buffer size by taking the difference between the largest ping time and the smallest ping time and multiplying it by the largest Rx messages/s. Then apply a safety factor when setting the buffer size - 10 times the calculated value should be good.<br />
* A message won't be sent when it should be if the autopilot sends a message that's the same as one it already sent (same name and exact same values) AND one or more links were lost between the first message and the second AND the link that's receiving the second message doesn't have the first message in it's buffer still. That's three conditions. If this happens, then the Link Combiner will see the second message as a duplicate of the first and will skip it. Only this one message will be missed though - it won't start happening to all messages. Also, the data will have been data that was already received. So if it's for example the battery voltage message, then it's not a big deal to miss it. As long as there aren't links rapidly being lost and gained, then this shouldn't happen often. Note that as the buffer size is increased, it is believed that this becomes more likely to happen.<br />
<br />
== Ground to Aircraft ==<br />
<br />
This part of the redundant communication system hasn't been implemented yet. All information here is what it is envisioned to look like.<br />
<br />
===Features===<br />
* Enable multiple datalink links to be used for communicating with the autopilot.<br />
* Let different telemetry be sent out each link.<br />
* Let the choice of what telemetry is sent be moved from the settings page of the GCS to the Link page, since it can be different for each link.<br />
* Add a link status indicator (this is the light that turns red when the link is lost) for the datalink to the Link page. This will allow better monitoring of the links by not assuming that if one direction is good, the other direction is good as well.<br />
* Let each link be configured as telemetry only, datalink only, or by-directional.<br />
<br />
===Compatibility===<br />
Communication in the autopilot is enabled with the ground by including the telemetry subsystem in the airframe file. For example:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing or rotorcraft"><br />
...<br />
<subsystem name="telemetry" type="transparent"/><br />
</firmware><br />
</source><br />
}}<br />
<br />
In order to use multiple links, changes should be made to allow a telemetry subsystem for each link. Related to this, would it be advantageous to have multiple instances be supported for each different subsystem? Once the design for this is determined, would actual support for each subsystem have to be added one at a time? Because of the logic for how multiple subsystems should behave together is dependent on the subsystem, this might be the case. The telemetry subsystem for example should default to sending telemetry out each one and combining the telemetry received.<br />
<br />
===Hardware===<br />
Unlike aircraft to ground redundancy, ground to aircraft redundancy requires multiple UART ports in the hardware of the autopilot. The author is not particularly familiar with this, but believes that there are ways to get multiple UART ports for this purpose:<br />
* Telemetry can be sent out over USB by specifying the telemetry type to be "transparent_usb".<br />
* For the Lisa/M, the USB port can actually be used as a UART port with some hardware modifications.<br />
* Using an I2C GPS instead of a UART one can free up a UART port on most autopilots.<br />
* For the Lisa/M, can UART 1 and 5 be used if Spektrum Satellite receivers aren't used? If so, where are the Tx pins?<br />
<br />
In addition, future hardware designs could includes more UART ports for redundant communications or any other purpose.<br />
<br />
===Design===<br />
Unlike the aircraft to ground communication, for ground to aircraft communication it is not acceptable to have the same message be acted on twice. This could cause the aircraft to behave unexpectedly. In order to implement a 100% guaranteed link combiner for the aircraft, the author proposes a system that adds a counter to each message sent to the aircraft. This would allow the autopilot to easily ignore identical messages - they'll have the same value for the counter. Also, since minimal data is sent from the ground to the aircraft, adding the extra bytes to the payload will have a minimal impact on performance - this is not the case for the telemetry.<br />
<br />
The challenging part of this design will be integrating it properly into the existing systems.</div>Camleehttp://wiki.paparazziuav.org/w/index.php?title=Redundant_Communication&diff=14979Redundant Communication2013-04-28T05:22:23Z<p>Camlee: </p>
<hr />
<div><div style="float: right; width: 15%"><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Tools</categorytree></div><br />
<div style="float: right; width: 45%; overflow: hidden">[[Image:link_page.png|center|397px|Link Page in GCS]]</div><br />
<div style="float: right; width: 40%">__TOC__</div><br />
<br />
There is currently a pull request to integrate a redundant communication system into the existing ground segment agents: [https://github.com/paparazzi/paparazzi/pull/429 github.com/paparazzi/paparazzi/pull/429]. The goal of this project is to allow multiple radio modems or other links be used between the aircraft and the ground station in a redundant fashion so that even if one link is lost, communication can be maintained. So far, the aircraft to ground component has been created and tested in the lab. More comprehensive testing should be performed before the system is considered to be stable. The ground to aircraft component has not been created yet.<br />
<br />
===Reasons to redundant links===<br />
Communication from the aircraft to the ground is called telemetry. This communication allows the status of the aircraft such as location, altitude, airspeed, battery level, current flight block, and much more to be monitored in real time. Communication from the ground to the aircraft is called datalink. This communication allows commands to be sent to the aircraft from the ground. This includes telling the aircraft what navigation to perform: fly to a waypoint, start the search area, come in for a landing. If a single link is used, as was always the case before this project, then if the aircraft goes out of range, or that link is otherwise lost, no telemetry information can be displayed in the GCS and commands sent from the GCS won't be received by the aircraft. Using the following redundant link system allows multiple links to be used in an effort to avoid this. Typically, you would introduce diversity when adding links. For example:<br />
* If you have an on-board computer, you could tunnel messages through Wi-Fi over UDP in addition to a traditional 900 MHz XBee radio modem.<br />
* You could use a satellite modem for long-range monitoring in addition to a radio modem.<br />
* You could use a cellular modem in addition to a radio modem.<br />
* With additional ground infrastructure, you could have radio modems located at different locations.<br />
* You could use radio modems at different frequencies or with different antenna gains or orientations.<br />
* You could use this system to evaluate different types of radio modems or antenna placements - you'll get real time info on each such as the ping time, received messages rate, and more information could easily be added.<br />
<br />
There are undoubtedly many more possibilities.<br />
<br />
== Aircraft to Ground ==<br />
<br />
===Compatibility===<br />
This project was made to be fully backwards compatible and support the awesome functionality that Paparazzi already has. This includes:<br />
* Completely backwards compatible - includes aircraft configuration files, previous flight logs, existing sessions, etc...<br />
* Logging and replay - if multiple links are used, data received through either link is recorded. Also, replays will include the status of each link as it was during the flight.<br />
* Link features such as USB-serial, audio, UDP, different transport layers, etc...<br />
* Multi-aircraft sessions - also, you can use redundant links for one aircraft, but not for another if desired.<br />
* Multiple aircraft connected to the same link - such as might come up in a mesh configuration where one aircraft relays data from another aircraft.<br />
<br />
===Features===<br />
Enabling redundant communication from the aircraft to the ground enables the following features:<br />
* Redundancy - as long as one link is receiving data, it will be logged and displayed on the GCS.<br />
* Monitoring - the status, ping time, and rate of receiving messages for each link is shown (this makes it useful even if you're only using one link).<br />
* Alerts - new alerts are added to the console in the GCS to alert you when a link has been connected for the first time, lost, or re-gained.<br />
<br />
===Future Improvements===<br />
Several different improvements can be made to this system to improve it's performance and help satisfy future needs that may arise:<br />
* Additional information can easily be added to the Link page of the GCS for each link. For example: errors, % uptime, or a scrolling graph of Rx messages/s.<br />
* The ability to mark different links as either critical or backup. The idea here is that not all links should necessarily be treated equal. Maybe only one link is able to send datalink data to the aircraft (actually, this is the case right now) and so that link should be considered critical. If any other link is lost, then the overall telemetry can be counted as OK. But if the critical link is lost, then the GCS should change the link indicator light to red and start counting up even if the other link(s) are OK.<br />
* The Link Combiner algorithm currently employs a simple circular buffer. This could be improved on by adding a time-stamp to each element of the buffer and only counting two buffer elements to be the same if their timestamps are close enough (say within 2 seconds - this could be configured)<br />
* The Link Combiner algorithm could be improved by making the buffer size adjust automatically with the ping time and Rx messages/s rate. Or if the timestamp improvement is implemented, then the maximum time difference could be adjusted.<br />
* A performance and resource use analysis could be done to optimize the Link Combiner. The circular buffer is currently implemented using Python lists which could probably be improved upon. Also, significantly more ivy messages are sent and received. This might make optimizations to the regex or other parts of the ivybus worthwhile.<br />
<br />
===How to use===<br />
<br />
For an example using two USB-serial adaptors, see the '''Flight USB-serial Redundant''' session saved in the example control_panel.xml configuration (on master branch, once the pull request has been accepted).<br />
<br />
For the details, keep reading:<br />
In order to implement redundant links using this code, there are three simple steps to follow:<br />
<br />
* Connect the hardware - on the airborne side, connect the Rx pin of the autopilot's UART port to multiple radio modems or whatever other device which will get the information to the ground. On the ground side, connect multiple modems as normal (using USB to serial adapters, a UDP connection, or whatever). (note: Once the ground to aircraft redundancy has been implemented, you won't have to split the Rx signal and can just plug each modem into a UART port)<br />
* Launch a Link agent for each modem (in Paparazzi Center, select it from the tools menu). Configure the agents as you would have before (serial port, baud rate, UDP, etc...). None of these features have been modified or removed. Then, use two new command line arguments: -redlink and -id. The -redlink flag tells Link that it's one of multiple links. The -id flag lets you specify an integer number as the id of that particular link.<br />
* Launch the Link Combiner agent (again, from the tools menu). This agent listens to all of the Link agents that have their -redlink set and combines the data.<br />
<br />
The following screenshot shows a session with two links, connected to serial ports ttyUSB0 and ttyUSB1, and with id's 1 and 2:<br />
<br />
[[File:redundant_session.png|alt=Agents in Redundant Link Session|700px]]<br />
<br />
The Agents Running in a Redundant Link Setup<br />
<br />
* Test the system and make sure that it works correctly under all circumstances. Do this before flying. In particular, make sure that the buffer size if appropriate. Take a look at the [[#Algorithm Considerations|Algorithm Considerations]] section for details.<br />
<br />
===Interface===<br />
Once the redundant link system is started (even if only one Link is used), several changes appear in the GCS. This is achieved by the new message LINK_STATUS which is sent by the Link Combiner. These new features are designed to allow closer monitoring and better management of the link(s) between the aircraft and the ground station.<br />
<br />
The following screenshot clearly shows these changes:<br />
[[File:redundant_link_gcs.png|alt=Changes to the GCS when redundant links are used|1000px]]<br />
<br />
Firstly, we can see that there is a new page in the notebook named Link. This page contains critical information for each link. More information can easily be added, but for now, it shows the status of the link (just like the main Link status indicator in the strip), the current ping time, and the rate of received messages. So if one link is lost, it's status indicator will turn red and start counting up just like link 2 in the above screenshot.<br />
<br />
Next, we can see that the main Link status indicator that's located in the strip has been modified slightly. It now shows the ratio of connected links to the total number of links. I.e. 3/4 means that there are four links and one of them has been lost. Furthermore, the indicator will be green if all links are connected, yellow if one or more are lost, and red if all links are lost. Once all links are lost, the indicator will count up just like before.<br />
<br />
Lastly, alerts have been added to the console. Whenever a link is lost or reconnected, a message will appear in the console stating so. Messages also appear when a new link is added.<br />
<br />
===Design===<br />
====Implementation====<br />
Here's a block diagram showing how the aircraft talks to the various ground segment programs (also known as agents) when not using the redundant link system:<br />
<br />
[[File:ground_segment_block_diagram.png|alt=Block diagram of agents in the ground segment|500px]]<br />
<br />
Paparazzi Ground Segment<br />
<br />
The ivy bus lets the programs talk to each other through the use of short messages. Pay close attention to the coloured arrows, which show the main flow of these messages. Next we have a block diagram of the redundant link system:<br />
<br />
[[File:redundant_links_block_diagram.png|alt=Block diagram of agents in the ground segment when redundant links are used|800px]]<br />
Paparazzi Ground Segment with Redundant Links<br />
<br />
Here we can see the new agent, the Link Combiner. We also see multiple occurrences of the Link agent. When operating in redundant mode, each occurrence of Link transmits the data it receives from the aircraft to the Link Combiner instead of the Server. It does this by transmitting the received telemetry messages within the TELEMETRY_MESSAGE message which the Server doesn't listen to. The Link Combiner on the other hand does. TELEMETRY_MESSAGE messages are sent by each link and include the id of that link. The Link Combiner listens to all of them and then transmits a single set of messages to the Server with the combined data. This results in the Server and all other ground segment agents (such as Messages and the Real Time Plotter) getting their telemetry data from Link Combiner as if it was coming from a single occurrence of Link.<br />
<br />
====Link Combiner====<br />
The Link Combiner agent is written in Python. It receives messages from all of the Links (when they're in redundant mode: -redlink), and outputs messages to the Server and other ground segment agents. There is a bit involved however since the Server and GCS shouldn't be sent identical messages. I.e. if the aircraft sends a message and it's received successfully by more than one link, then that particular message should only sent by Link Combiner once. This is a somewhat tricky requirement since there is no guarantee that the message will be received by all of the links, and it's possible that the aircraft actually sends a second message that's exactly the same as the first. No extra info (such as a time-stamp or counter) is added to the messages sent from the aircraft to the ground, so the Link Combiner employs an algorithm to detect duplicate messages. Testing has shown that for typical links, this algorithm performs extremely well.<br />
<br />
The algorithm gives each link a circular buffer to store the last N messages. When a new message comes in on a particular link, the algorithm first checks if it's already in that link's buffer. If it is, then it's obviously a new message, so its removed from all of the other buffers if it's in any of them. Then, the message is sent to the other agents. If the message isn't already in the link's buffer, then it's added to the buffer. After that, all of the other link's buffers are checked for the message. If it's in any of them, then the message was already received by another link, so isn't sent. If it's not in any of them, then the message is sent. The following flowchart depicts this algorithm:<br />
<br />
[[File:link_combiner_flowchart.png|alt=Flowchart of the Link Combiner|500px]]<br />
<br />
Algorithm to prevent duplicate messages<br />
<br />
====Algorithm Considerations====<br />
As the aircraft sends various messages, possibly with the exact same data, and the links gain and lose connection, there is no guarantee that this algorithm will do a perfect job of filtering out identical and only identical messages. However, in typical operation, it seems to work very well. And for the application of displaying aircraft data, the occasional missing or duplicate message is acceptable. There are only a few scenarios where the Link Combiner won't produce perfect results, and they should come up infrequently:<br />
<br />
* A message will be sent twice if the buffer size is too small to hold all of the messages received from one link between that link receiving the message and another link receiving the identical message. When the second link receives the message that has already been received, if the original isn't in the buffer anymore, than the algorithm won't know it's a duplicate message. This scenario should be considered whenever implementing a redundant link system. Partly because it is the most likely to come up, but also because if it does occur, then all messages will be duplicated. In order to avoid this scenario, you can set the buffer size as a command line argument of Link Combiner. To know what a good value would be, you can observer the Ping time and Rx messages/s of the links in the new Link page of the notebook. Calculate the minimum buffer size by taking the difference between the largest ping time and the smallest ping time and multiplying it by the largest Rx messages/s. Then apply a safety factor when setting the buffer size - 10 times the calculated value should be good.<br />
* A message won't be sent when it should be if the autopilot sends a message that's the same as one it already sent (same name and exact same values) AND one or more links were lost between the first message and the second AND the link that's receiving the second message doesn't have the first message in it's buffer still. That's three conditions. If this happens, then the Link Combiner will see the second message as a duplicate of the first and will skip it. Only this one message will be missed though - it won't start happening to all messages. Also, the data will have been data that was already received. So if it's for example the battery voltage message, then it's not a big deal to miss it. As long as there aren't links rapidly being lost and gained, then this shouldn't happen often. Note that as the buffer size is increased, it is believed that this becomes more likely to happen.<br />
<br />
== Ground to Aircraft ==<br />
<br />
This part of the redundant communication system hasn't been implemented yet. All information here is what it is envisioned to look like.<br />
<br />
===Features===<br />
* Enable multiple datalink links to be used for communicating with the autopilot.<br />
* Let different telemetry be sent out each link.<br />
* Let the choice of what telemetry is sent be moved from the settings page of the GCS to the Link page, since it can be different for each link.<br />
* Add a link status indicator (this is the light that turns red when the link is lost) for the datalink to the Link page. This will allow better monitoring of the links by not assuming that if one direction is good, the other direction is good as well.<br />
* Let each link be configured as telemetry only, datalink only, or by-directional.<br />
<br />
===Compatibility===<br />
Communication in the autopilot is enabled with the ground by including the telemetry subsystem in the airframe file. For example:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing or rotorcraft"><br />
...<br />
<subsystem name="telemetry" type="transparent"/><br />
</firmware><br />
</source><br />
}}<br />
<br />
In order to use multiple links, changes should be made to allow a telemetry subsystem for each link. Related to this, would it be advantageous to have multiple instances be supported for each different subsystem? Once the design for this is determined, would actual support for each subsystem have to be added one at a time? Because of the logic for how multiple subsystems should behave together is dependent on the subsystem, this might be the case. The telemetry subsystem for example should default to sending telemetry out each one and combining the telemetry received.<br />
<br />
===Hardware===<br />
Unlike aircraft to ground redundancy, ground to aircraft redundancy requires multiple UART ports in the hardware of the autopilot. The author is not particularly familiar with this, but believes that there are ways to get multiple UART ports for this purpose:<br />
* Telemetry can be sent out over USB by specifying the telemetry type to be "transparent_usb".<br />
* For the Lisa/M, the USB port can actually be used as a UART port with some hardware modifications.<br />
* Using an I2C GPS instead of a UART one can free up a UART port on most autopilots.<br />
* For the Lisa/M, can UART 1 and 5 be used if Spektrum Satellite receivers aren't used? If so, where are the Tx pins?<br />
<br />
In addition, future hardware designs could includes more UART ports for redundant communications or any other purpose.<br />
<br />
===Design===<br />
Unlike the aircraft to ground communication, for ground to aircraft communication it is not acceptable to have the same message be acted on twice. This could cause the aircraft to behave unexpectedly. In order to implement a 100% guaranteed link combiner for the aircraft, the author proposes a system that adds a counter to each message sent to the aircraft. This would allow the autopilot to easily ignore identical messages - they'll have the same value for the counter. Also, since minimal data is sent from the ground to the aircraft, adding the extra bytes to the payload will have a minimal impact on performance - this is not the case for the telemetry.<br />
<br />
The challenging part of this design will be integrating it properly into the existing systems.</div>Camleehttp://wiki.paparazziuav.org/w/index.php?title=Redundant_Communication&diff=14978Redundant Communication2013-04-28T05:20:33Z<p>Camlee: </p>
<hr />
<div><div style="float: right; width: 15%"><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Tools</categorytree></div><br />
<div style="float: right; width: 45%; overflow: hidden">[[Image:link_page.png|center|397px|Link Page in GCS]]</div><br />
<div style="float: right; width: 40%">__TOC__</div><br />
<br />
There is currently a pull request to integrate a redundant communication system into the existing ground segment agents: [https://github.com/paparazzi/paparazzi/pull/429 github.com/paparazzi/paparazzi/pull/429]. The goal of this project is to allow multiple radio modems or other links be used between the aircraft and the ground station in a redundant fashion so that even if one link is lost, communication can be maintained. So far, the aircraft to ground component has been created and tested in the lab. More comprehensive testing should be performed before the system is considered to be stable. The ground to aircraft component has not been created yet.<br />
<br />
===Reasons to redundant links===<br />
Communication from the aircraft to the ground is called telemetry. This communication allows the status of the aircraft such as location, altitude, airspeed, battery level, current flight block, and much more to be monitored in real time. Communication from the ground to the aircraft is called datalink. This communication allows commands to be sent to the aircraft from the ground. This includes telling the aircraft what navigation to perform: fly to a waypoint, start the search area, come in for a landing. If a single link is used, as was always the case before this project, then if the aircraft goes out of range, or that link is otherwise lost, no telemetry information can be displayed in the GCS and commands sent from the GCS won't be received by the aircraft. Using the following redundant link system allows multiple links to be used in an effort to avoid this. Typically, you would introduce diversity when adding links. For example:<br />
* If you have an on-board computer, you could tunnel messages through Wi-Fi over UDP in addition to a traditional 900 MHz XBee radio modem.<br />
* You could use a satellite modem for long-range monitoring in addition to a radio modem.<br />
* You could use a cellular modem in addition to a radio modem.<br />
* With additional ground infrastructure, you could have radio modems located at different locations.<br />
* You could use radio modems at different frequencies or with different antenna gains or orientations.<br />
* You could use this system to evaluate different types of radio modems or antenna placements - you'll get real time info on each such as the ping time, received messages rate, and more information could easily be added.<br />
<br />
There are undoubtedly many more possibilities.<br />
<br />
== Aircraft to Ground ==<br />
<br />
===Compatibility===<br />
This project was made to be fully backwards compatible and support the awesome functionality that Paparazzi already has. This includes:<br />
* Completely backwards compatible - includes aircraft configuration files, previous flight logs, existing sessions, etc...<br />
* Logging and replay - if multiple links are used, data received through either link is recorded. Also, replays will include the status of each link as it was during the flight.<br />
* Link features such as USB-serial, audio, UDP, different transport layers, etc...<br />
* Multi-aircraft sessions - also, you can use redundant links for one aircraft, but not for another if desired.<br />
* Multiple aircraft connected to the same link - such as might come up in a mesh configuration where one aircraft relays data from another aircraft.<br />
<br />
===Features===<br />
Enabling redundant communication from the aircraft to the ground enables the following features:<br />
* Redundancy - as long as one link is receiving data, it will be logged and displayed on the GCS.<br />
* Monitoring - the status, ping time, and rate of receiving messages for each link is shown (this makes it useful even if you're only using one link).<br />
* Alerts - new alerts are added to the console in the GCS to alert you when a link has been connected for the first time, lost, or re-gained.<br />
<br />
===Future Improvements===<br />
Several different improvements can be made to this system to improve it's performance and help satisfy future needs that may arise:<br />
* Additional information can easily be added to the Link page of the GCS for each link. For example: errors, % uptime, or a scrolling graph of Rx messages/s.<br />
* The ability to mark different links as either critical or backup. The idea here is that not all links should necessarily be treated equal. Maybe only one link is able to send datalink data to the aircraft (actually, this is the case right now) and so that link should be considered critical. If any other link is lost, then the overall telemetry can be counted as OK. But if the critical link is lost, then the GCS should change the link indicator light to red and start counting up even if the other link(s) are OK.<br />
* The Link Combiner algorithm currently employs a simple circular buffer. This could be improved on by adding a time-stamp to each element of the buffer and only counting two buffer elements to be the same if their timestamps are close enough (say within 2 seconds - this could be configured)<br />
* The Link Combiner algorithm could be improved by making the buffer size adjust automatically with the ping time and Rx messages/s rate. Or if the timestamp improvement is implemented, then the maximum time difference could be adjusted.<br />
* A performance and resource use analysis could be done to optimize the Link Combiner. The circular buffer is currently implemented using Python lists which could probably be improved upon. Also, significantly more ivy messages are sent and received. This might make optimizations to the regex or other parts of the ivybus worthwhile.<br />
<br />
===How to use===<br />
<br />
For an example using two USB-serial adaptors, see the '''Flight USB-serial Redundant''' session saved in the example control_panel.xml configuration (on master branch, once the pull request has been accepted).<br />
<br />
For the details, keep reading:<br />
In order to implement redundant links using this code, there are three simple steps to follow:<br />
<br />
* Connect the hardware - on the airborne side, connect the Rx pin of the autopilot's UART port to multiple radio modems or whatever other device which will get the information to the ground. On the ground side, connect multiple modems as normal (using USB to serial adapters, a UDP connection, or whatever). (note: Once the ground to aircraft redundancy has been implemented, you won't have to split the Rx signal and can just plug each modem into a UART port)<br />
* Launch a Link agent for each modem (in Paparazzi Center, select it from the tools menu). Configure the agents as you would have before (serial port, baud rate, UDP, etc...). None of these features have been modified or removed. Then, use two new command line arguments: -redlink and -id. The -redlink flag tells Link that it's one of multiple links. The -id flag lets you specify an integer number as the id of that particular link.<br />
* Launch the Link Combiner agent (again, from the tools menu). This agent listens to all of the Link agents that have their -redlink set and combines the data.<br />
<br />
The following screenshot shows a session with two links, connected to serial ports ttyUSB0 and ttyUSB1, and with id's 1 and 2:<br />
<br />
[[File:redundant_session.png|alt=Agents in Redundant Link Session|700px]]<br />
<br />
The Agents Running in a Redundant Link Setup<br />
<br />
* Test the system and make sure that it works correctly under all circumstances. Do this before flying. In particular, make sure that the buffer size if appropriate. Take a look at the [[#Algorithm Considerations|Algorithm Considerations]] section for details.<br />
<br />
===Interface===<br />
Once the redundant link system is started (even if only one Link is used), several changes appear in the GCS. This is achieved by the new message LINK_STATUS which is sent by the Link Combiner. These new features are designed to allow closer monitoring and better management of the link(s) between the aircraft and the ground station.<br />
<br />
The following screenshot clearly shows these changes:<br />
[[File:redundant_link_gcs.png|alt=Changes to the GCS when redundant links are used|1000px]]<br />
<br />
Firstly, we can see that there is a new page in the notebook named Link. This page contains critical information for each link. More information can easily be added, but for now, it shows the status of the link (just like the main Link status indicator in the strip), the current ping time, and the rate of received messages. So if one link is lost, it's status indicator will turn red and start counting up just like link 2 in the above screenshot.<br />
<br />
Next, we can see that the main Link status indicator that's located in the strip has been modified slightly. It now shows the ratio of connected links to the total number of links. I.e. 3/4 means that there are four links and one of them has been lost. Furthermore, the indicator will be green if all links are connected, yellow if one or more are lost, and red if all links are lost. Once all links are lost, the indicator will count up just like before.<br />
<br />
Lastly, alerts have been added to the console. Whenever a link is lost or reconnected, a message will appear in the console stating so. Messages also appear when a new link is added.<br />
<br />
===Design===<br />
====Implementation====<br />
Here's a block diagram showing how the aircraft talks to the various ground segment programs (also known as agents) when not using the redundant link system:<br />
<br />
[[File:ground_segment_block_diagram.png|alt=Block diagram of agents in the ground segment|500px]]<br />
<br />
Paparazzi Ground Segment<br />
<br />
The ivy bus lets the programs talk to each other through the use of short messages. Pay close attention to the coloured arrows, which show the main flow of these messages. Next we have a block diagram of the redundant link system:<br />
<br />
[[File:redundant_links_block_diagram.png|alt=Block diagram of agents in the ground segment when redundant links are used|1000px]]<br />
Paparazzi Ground Segment with Redundant Links<br />
<br />
Here we can see the new agent, the Link Combiner. We also see multiple occurrences of the Link agent. When operating in redundant mode, each occurrence of Link transmits the data it receives from the aircraft to the Link Combiner instead of the Server. It does this by transmitting the received telemetry messages within the TELEMETRY_MESSAGE message which the Server doesn't listen to. The Link Combiner on the other hand does. TELEMETRY_MESSAGE messages are sent by each link and include the id of that link. The Link Combiner listens to all of them and then transmits a single set of messages to the Server with the combined data. This results in the Server and all other ground segment agents (such as Messages and the Real Time Plotter) getting their telemetry data from Link Combiner as if it was coming from a single occurrence of Link.<br />
<br />
====Link Combiner====<br />
The Link Combiner agent is written in Python. It receives messages from all of the Links (when they're in redundant mode: -redlink), and outputs messages to the Server and other ground segment agents. There is a bit involved however since the Server and GCS shouldn't be sent identical messages. I.e. if the aircraft sends a message and it's received successfully by more than one link, then that particular message should only sent by Link Combiner once. This is a somewhat tricky requirement since there is no guarantee that the message will be received by all of the links, and it's possible that the aircraft actually sends a second message that's exactly the same as the first. No extra info (such as a time-stamp or counter) is added to the messages sent from the aircraft to the ground, so the Link Combiner employs an algorithm to detect duplicate messages. Testing has shown that for typical links, this algorithm performs extremely well.<br />
<br />
The algorithm gives each link a circular buffer to store the last N messages. When a new message comes in on a particular link, the algorithm first checks if it's already in that link's buffer. If it is, then it's obviously a new message, so its removed from all of the other buffers if it's in any of them. Then, the message is sent to the other agents. If the message isn't already in the link's buffer, then it's added to the buffer. After that, all of the other link's buffers are checked for the message. If it's in any of them, then the message was already received by another link, so isn't sent. If it's not in any of them, then the message is sent. The following flowchart depicts this algorithm:<br />
<br />
[[File:link_combiner_flowchart.png|alt=Flowchart of the Link Combiner|300px]]<br />
<br />
Algorithm to prevent duplicate messages<br />
<br />
====Algorithm Considerations====<br />
As the aircraft sends various messages, possibly with the exact same data, and the links gain and lose connection, there is no guarantee that this algorithm will do a perfect job of filtering out identical and only identical messages. However, in typical operation, it seems to work very well. And for the application of displaying aircraft data, the occasional missing or duplicate message is acceptable. There are only a few scenarios where the Link Combiner won't produce perfect results, and they should come up infrequently:<br />
<br />
* A message will be sent twice if the buffer size is too small to hold all of the messages received from one link between that link receiving the message and another link receiving the identical message. When the second link receives the message that has already been received, if the original isn't in the buffer anymore, than the algorithm won't know it's a duplicate message. This scenario should be considered whenever implementing a redundant link system. Partly because it is the most likely to come up, but also because if it does occur, then all messages will be duplicated. In order to avoid this scenario, you can set the buffer size as a command line argument of Link Combiner. To know what a good value would be, you can observer the Ping time and Rx messages/s of the links in the new Link page of the notebook. Calculate the minimum buffer size by taking the difference between the largest ping time and the smallest ping time and multiplying it by the largest Rx messages/s. Then apply a safety factor when setting the buffer size - 10 times the calculated value should be good.<br />
* A message won't be sent when it should be if the autopilot sends a message that's the same as one it already sent (same name and exact same values) AND one or more links were lost between the first message and the second AND the link that's receiving the second message doesn't have the first message in it's buffer still. That's three conditions. If this happens, then the Link Combiner will see the second message as a duplicate of the first and will skip it. Only this one message will be missed though - it won't start happening to all messages. Also, the data will have been data that was already received. So if it's for example the battery voltage message, then it's not a big deal to miss it. As long as there aren't links rapidly being lost and gained, then this shouldn't happen often. Note that as the buffer size is increased, it is believed that this becomes more likely to happen.<br />
<br />
== Ground to Aircraft ==<br />
<br />
This part of the redundant communication system hasn't been implemented yet. All information here is what it is envisioned to look like.<br />
<br />
===Features===<br />
* Enable multiple datalink links to be used for communicating with the autopilot.<br />
* Let different telemetry be sent out each link.<br />
* Let the choice of what telemetry is sent be moved from the settings page of the GCS to the Link page, since it can be different for each link.<br />
* Add a link status indicator (this is the light that turns red when the link is lost) for the datalink to the Link page. This will allow better monitoring of the links by not assuming that if one direction is good, the other direction is good as well.<br />
* Let each link be configured as telemetry only, datalink only, or by-directional.<br />
<br />
===Compatibility===<br />
Communication in the autopilot is enabled with the ground by including the telemetry subsystem in the airframe file. For example:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing or rotorcraft"><br />
...<br />
<subsystem name="telemetry" type="transparent"/><br />
</firmware><br />
</source><br />
}}<br />
<br />
In order to use multiple links, changes should be made to allow a telemetry subsystem for each link. Related to this, would it be advantageous to have multiple instances be supported for each different subsystem? Once the design for this is determined, would actual support for each subsystem have to be added one at a time? Because of the logic for how multiple subsystems should behave together is dependent on the subsystem, this might be the case. The telemetry subsystem for example should default to sending telemetry out each one and combining the telemetry received.<br />
<br />
===Hardware===<br />
Unlike aircraft to ground redundancy, ground to aircraft redundancy requires multiple UART ports in the hardware of the autopilot. The author is not particularly familiar with this, but believes that there are ways to get multiple UART ports for this purpose:<br />
* Telemetry can be sent out over USB by specifying the telemetry type to be "transparent_usb".<br />
* For the Lisa/M, the USB port can actually be used as a UART port with some hardware modifications.<br />
* Using an I2C GPS instead of a UART one can free up a UART port on most autopilots.<br />
* For the Lisa/M, can UART 1 and 5 be used if Spektrum Satellite receivers aren't used? If so, where are the Tx pins?<br />
<br />
In addition, future hardware designs could includes more UART ports for redundant communications or any other purpose.<br />
<br />
===Design===<br />
Unlike the aircraft to ground communication, for ground to aircraft communication it is not acceptable to have the same message be acted on twice. This could cause the aircraft to behave unexpectedly. In order to implement a 100% guaranteed link combiner for the aircraft, the author proposes a system that adds a counter to each message sent to the aircraft. This would allow the autopilot to easily ignore identical messages - they'll have the same value for the counter. Also, since minimal data is sent from the ground to the aircraft, adding the extra bytes to the payload will have a minimal impact on performance - this is not the case for the telemetry.<br />
<br />
The challenging part of this design will be integrating it properly into the existing systems.</div>Camleehttp://wiki.paparazziuav.org/w/index.php?title=Redundant_Communication&diff=14977Redundant Communication2013-04-28T05:18:55Z<p>Camlee: </p>
<hr />
<div><div style="float: right; width: 15%"><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Tools</categorytree></div><br />
<div style="float: right; width: 45%; overflow: hidden">[[Image:link_page.png|center|397px|Link Page in GCS]]</div><br />
<div style="float: right; width: 40%">__TOC__</div><br />
<br />
There is currently a pull request to integrate a redundant communication system into the existing ground segment agents: [https://github.com/paparazzi/paparazzi/pull/429 github.com/paparazzi/paparazzi/pull/429]. The goal of this project is to allow multiple radio modems or other links be used between the aircraft and the ground station in a redundant fashion so that even if one link is lost, communication can be maintained. So far, the aircraft to ground component has been created and tested in the lab. More comprehensive testing should be performed before the system is considered to be stable. The ground to aircraft component has not been created yet.<br />
<br />
===Reasons to redundant links===<br />
Communication from the aircraft to the ground is called telemetry. This communication allows the status of the aircraft such as location, altitude, airspeed, battery level, current flight block, and much more to be monitored in real time. Communication from the ground to the aircraft is called datalink. This communication allows commands to be sent to the aircraft from the ground. This includes telling the aircraft what navigation to perform: fly to a waypoint, start the search area, come in for a landing. If a single link is used, as was always the case before this project, then if the aircraft goes out of range, or that link is otherwise lost, no telemetry information can be displayed in the GCS and commands sent from the GCS won't be received by the aircraft. Using the following redundant link system allows multiple links to be used in an effort to avoid this. Typically, you would introduce diversity when adding links. For example:<br />
* If you have an on-board computer, you could tunnel messages through Wi-Fi over UDP in addition to a traditional 900 MHz XBee radio modem.<br />
* You could use a satellite modem for long-range monitoring in addition to a radio modem.<br />
* You could use a cellular modem in addition to a radio modem.<br />
* With additional ground infrastructure, you could have radio modems located at different locations.<br />
* You could use radio modems at different frequencies or with different antenna gains or orientations.<br />
* You could use this system to evaluate different types of radio modems or antenna placements - you'll get real time info on each such as the ping time, received messages rate, and more information could easily be added.<br />
<br />
There are undoubtedly many more possibilities.<br />
<br />
== Aircraft to Ground ==<br />
<br />
===Compatibility===<br />
This project was made to be fully backwards compatible and support the awesome functionality that Paparazzi already has. This includes:<br />
* Completely backwards compatible - includes aircraft configuration files, previous flight logs, existing sessions, etc...<br />
* Logging and replay - if multiple links are used, data received through either link is recorded. Also, replays will include the status of each link as it was during the flight.<br />
* Link features such as USB-serial, audio, UDP, different transport layers, etc...<br />
* Multi-aircraft sessions - also, you can use redundant links for one aircraft, but not for another if desired.<br />
* Multiple aircraft connected to the same link - such as might come up in a mesh configuration where one aircraft relays data from another aircraft.<br />
<br />
===Features===<br />
Enabling redundant communication from the aircraft to the ground enables the following features:<br />
* Redundancy - as long as one link is receiving data, it will be logged and displayed on the GCS.<br />
* Monitoring - the status, ping time, and rate of receiving messages for each link is shown (this makes it useful even if you're only using one link).<br />
* Alerts - new alerts are added to the console in the GCS to alert you when a link has been connected for the first time, lost, or re-gained.<br />
<br />
===Future Improvements===<br />
Several different improvements can be made to this system to improve it's performance and help satisfy future needs that may arise:<br />
* Additional information can easily be added to the Link page of the GCS for each link. For example: errors, % uptime, or a scrolling graph of Rx messages/s.<br />
* The ability to mark different links as either critical or backup. The idea here is that not all links should necessarily be treated equal. Maybe only one link is able to send datalink data to the aircraft (actually, this is the case right now) and so that link should be considered critical. If any other link is lost, then the overall telemetry can be counted as OK. But if the critical link is lost, then the GCS should change the link indicator light to red and start counting up even if the other link(s) are OK.<br />
* The Link Combiner algorithm currently employs a simple circular buffer. This could be improved on by adding a time-stamp to each element of the buffer and only counting two buffer elements to be the same if their timestamps are close enough (say within 2 seconds - this could be configured)<br />
* The Link Combiner algorithm could be improved by making the buffer size adjust automatically with the ping time and Rx messages/s rate. Or if the timestamp improvement is implemented, then the maximum time difference could be adjusted.<br />
* A performance and resource use analysis could be done to optimize the Link Combiner. The circular buffer is currently implemented using Python lists which could probably be improved upon. Also, significantly more ivy messages are sent and received. This might make optimizations to the regex or other parts of the ivybus worthwhile.<br />
<br />
===How to use===<br />
<br />
For an example using two USB-serial adaptors, see the '''Flight USB-serial Redundant''' session saved in the example control_panel.xml configuration (on master branch, once the pull request has been accepted).<br />
<br />
For the details, keep reading:<br />
In order to implement redundant links using this code, there are three simple steps to follow:<br />
<br />
* Connect the hardware - on the airborne side, connect the Rx pin of the autopilot's UART port to multiple radio modems or whatever other device which will get the information to the ground. On the ground side, connect multiple modems as normal (using USB to serial adapters, a UDP connection, or whatever). (note: Once the ground to aircraft redundancy has been implemented, you won't have to split the Rx signal and can just plug each modem into a UART port)<br />
* Launch a Link agent for each modem (in Paparazzi Center, select it from the tools menu). Configure the agents as you would have before (serial port, baud rate, UDP, etc...). None of these features have been modified or removed. Then, use two new command line arguments: -redlink and -id. The -redlink flag tells Link that it's one of multiple links. The -id flag lets you specify an integer number as the id of that particular link.<br />
* Launch the Link Combiner agent (again, from the tools menu). This agent listens to all of the Link agents that have their -redlink set and combines the data.<br />
<br />
The following screenshot shows a session with two links, connected to serial ports ttyUSB0 and ttyUSB1, and with id's 1 and 2:<br />
<br />
[[File:redundant_session.png|alt=Agents in Redundant Link Session|1000px]]<br />
<br />
The Agents Running in a Redundant Link Setup<br />
<br />
* Test the system and make sure that it works correctly under all circumstances. Do this before flying. In particular, make sure that the buffer size if appropriate. Take a look at the [[#Algorithm Considerations|Algorithm Considerations]] section for details.<br />
<br />
===Interface===<br />
Once the redundant link system is started (even if only one Link is used), several changes appear in the GCS. This is achieved by the new message LINK_STATUS which is sent by the Link Combiner. These new features are designed to allow closer monitoring and better management of the link(s) between the aircraft and the ground station.<br />
<br />
The following screenshot clearly shows these changes:<br />
[[File:redundant_link_gcs.png|alt=Changes to the GCS when redundant links are used|1000px]]<br />
<br />
Firstly, we can see that there is a new page in the notebook named Link. This page contains critical information for each link. More information can easily be added, but for now, it shows the status of the link (just like the main Link status indicator in the strip), the current ping time, and the rate of received messages. So if one link is lost, it's status indicator will turn red and start counting up just like link 2 in the above screenshot.<br />
<br />
Next, we can see that the main Link status indicator that's located in the strip has been modified slightly. It now shows the ratio of connected links to the total number of links. I.e. 3/4 means that there are four links and one of them has been lost. Furthermore, the indicator will be green if all links are connected, yellow if one or more are lost, and red if all links are lost. Once all links are lost, the indicator will count up just like before.<br />
<br />
Lastly, alerts have been added to the console. Whenever a link is lost or reconnected, a message will appear in the console stating so. Messages also appear when a new link is added.<br />
<br />
===Design===<br />
====Implementation====<br />
Here's a block diagram showing how the aircraft talks to the various ground segment programs (also known as agents) when not using the redundant link system:<br />
<br />
[[File:ground_segment_block_diagram.png|alt=Block diagram of agents in the ground segment|1000px]]<br />
Paparazzi Ground Segment<br />
<br />
The ivy bus lets the programs talk to each other through the use of short messages. Pay close attention to the coloured arrows, which show the main flow of these messages. Next we have a block diagram of the redundant link system:<br />
<br />
[[File:redundant_links_block_diagram.png|alt=Block diagram of agents in the ground segment when redundant links are used|1000px]]<br />
Paparazzi Ground Segment with Redundant Links<br />
<br />
Here we can see the new agent, the Link Combiner. We also see multiple occurrences of the Link agent. When operating in redundant mode, each occurrence of Link transmits the data it receives from the aircraft to the Link Combiner instead of the Server. It does this by transmitting the received telemetry messages within the TELEMETRY_MESSAGE message which the Server doesn't listen to. The Link Combiner on the other hand does. TELEMETRY_MESSAGE messages are sent by each link and include the id of that link. The Link Combiner listens to all of them and then transmits a single set of messages to the Server with the combined data. This results in the Server and all other ground segment agents (such as Messages and the Real Time Plotter) getting their telemetry data from Link Combiner as if it was coming from a single occurrence of Link.<br />
<br />
====Link Combiner====<br />
The Link Combiner agent is written in Python. It receives messages from all of the Links (when they're in redundant mode: -redlink), and outputs messages to the Server and other ground segment agents. There is a bit involved however since the Server and GCS shouldn't be sent identical messages. I.e. if the aircraft sends a message and it's received successfully by more than one link, then that particular message should only sent by Link Combiner once. This is a somewhat tricky requirement since there is no guarantee that the message will be received by all of the links, and it's possible that the aircraft actually sends a second message that's exactly the same as the first. No extra info (such as a time-stamp or counter) is added to the messages sent from the aircraft to the ground, so the Link Combiner employs an algorithm to detect duplicate messages. Testing has shown that for typical links, this algorithm performs extremely well.<br />
<br />
The algorithm gives each link a circular buffer to store the last N messages. When a new message comes in on a particular link, the algorithm first checks if it's already in that link's buffer. If it is, then it's obviously a new message, so its removed from all of the other buffers if it's in any of them. Then, the message is sent to the other agents. If the message isn't already in the link's buffer, then it's added to the buffer. After that, all of the other link's buffers are checked for the message. If it's in any of them, then the message was already received by another link, so isn't sent. If it's not in any of them, then the message is sent. The following flowchart depicts this algorithm:<br />
<br />
[[File:link_combiner_flowchart.png|alt=Flowchart of the Link Combiner|1000px]]<br />
<br />
Algorithm to prevent duplicate messages<br />
<br />
====Algorithm Considerations====<br />
As the aircraft sends various messages, possibly with the exact same data, and the links gain and lose connection, there is no guarantee that this algorithm will do a perfect job of filtering out identical and only identical messages. However, in typical operation, it seems to work very well. And for the application of displaying aircraft data, the occasional missing or duplicate message is acceptable. There are only a few scenarios where the Link Combiner won't produce perfect results, and they should come up infrequently:<br />
<br />
* A message will be sent twice if the buffer size is too small to hold all of the messages received from one link between that link receiving the message and another link receiving the identical message. When the second link receives the message that has already been received, if the original isn't in the buffer anymore, than the algorithm won't know it's a duplicate message. This scenario should be considered whenever implementing a redundant link system. Partly because it is the most likely to come up, but also because if it does occur, then all messages will be duplicated. In order to avoid this scenario, you can set the buffer size as a command line argument of Link Combiner. To know what a good value would be, you can observer the Ping time and Rx messages/s of the links in the new Link page of the notebook. Calculate the minimum buffer size by taking the difference between the largest ping time and the smallest ping time and multiplying it by the largest Rx messages/s. Then apply a safety factor when setting the buffer size - 10 times the calculated value should be good.<br />
* A message won't be sent when it should be if the autopilot sends a message that's the same as one it already sent (same name and exact same values) AND one or more links were lost between the first message and the second AND the link that's receiving the second message doesn't have the first message in it's buffer still. That's three conditions. If this happens, then the Link Combiner will see the second message as a duplicate of the first and will skip it. Only this one message will be missed though - it won't start happening to all messages. Also, the data will have been data that was already received. So if it's for example the battery voltage message, then it's not a big deal to miss it. As long as there aren't links rapidly being lost and gained, then this shouldn't happen often. Note that as the buffer size is increased, it is believed that this becomes more likely to happen.<br />
<br />
== Ground to Aircraft ==<br />
<br />
This part of the redundant communication system hasn't been implemented yet. All information here is what it is envisioned to look like.<br />
<br />
===Features===<br />
* Enable multiple datalink links to be used for communicating with the autopilot.<br />
* Let different telemetry be sent out each link.<br />
* Let the choice of what telemetry is sent be moved from the settings page of the GCS to the Link page, since it can be different for each link.<br />
* Add a link status indicator (this is the light that turns red when the link is lost) for the datalink to the Link page. This will allow better monitoring of the links by not assuming that if one direction is good, the other direction is good as well.<br />
* Let each link be configured as telemetry only, datalink only, or by-directional.<br />
<br />
===Compatibility===<br />
Communication in the autopilot is enabled with the ground by including the telemetry subsystem in the airframe file. For example:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing or rotorcraft"><br />
...<br />
<subsystem name="telemetry" type="transparent"/><br />
</firmware><br />
</source><br />
}}<br />
<br />
In order to use multiple links, changes should be made to allow a telemetry subsystem for each link. Related to this, would it be advantageous to have multiple instances be supported for each different subsystem? Once the design for this is determined, would actual support for each subsystem have to be added one at a time? Because of the logic for how multiple subsystems should behave together is dependent on the subsystem, this might be the case. The telemetry subsystem for example should default to sending telemetry out each one and combining the telemetry received.<br />
<br />
===Hardware===<br />
Unlike aircraft to ground redundancy, ground to aircraft redundancy requires multiple UART ports in the hardware of the autopilot. The author is not particularly familiar with this, but believes that there are ways to get multiple UART ports for this purpose:<br />
* Telemetry can be sent out over USB by specifying the telemetry type to be "transparent_usb".<br />
* For the Lisa/M, the USB port can actually be used as a UART port with some hardware modifications.<br />
* Using an I2C GPS instead of a UART one can free up a UART port on most autopilots.<br />
* For the Lisa/M, can UART 1 and 5 be used if Spektrum Satellite receivers aren't used? If so, where are the Tx pins?<br />
<br />
In addition, future hardware designs could includes more UART ports for redundant communications or any other purpose.<br />
<br />
===Design===<br />
Unlike the aircraft to ground communication, for ground to aircraft communication it is not acceptable to have the same message be acted on twice. This could cause the aircraft to behave unexpectedly. In order to implement a 100% guaranteed link combiner for the aircraft, the author proposes a system that adds a counter to each message sent to the aircraft. This would allow the autopilot to easily ignore identical messages - they'll have the same value for the counter. Also, since minimal data is sent from the ground to the aircraft, adding the extra bytes to the payload will have a minimal impact on performance - this is not the case for the telemetry.<br />
<br />
The challenging part of this design will be integrating it properly into the existing systems.</div>Camleehttp://wiki.paparazziuav.org/w/index.php?title=Redundant_Communication&diff=14976Redundant Communication2013-04-28T05:14:42Z<p>Camlee: </p>
<hr />
<div><div style="float: right; width: 15%"><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Tools</categorytree></div><br />
<div style="float: right; width: 45%; overflow: hidden">[[Image:link_page.png|center|397px|Link Page in GCS]]</div><br />
<div style="float: right; width: 40%">__TOC__</div><br />
<br />
There is currently a pull request to integrate a redundant communication system into the existing ground segment agents: [https://github.com/paparazzi/paparazzi/pull/429 github.com/paparazzi/paparazzi/pull/429]. The goal of this project is to allow multiple radio modems or other links be used between the aircraft and the ground station in a redundant fashion so that even if one link is lost, communication can be maintained. So far, the aircraft to ground component has been created and tested in the lab. More comprehensive testing should be performed before the system is considered to be stable. The ground to aircraft component has not been created yet.<br />
<br />
===Reasons to redundant links===<br />
Communication from the aircraft to the ground is called telemetry. This communication allows the status of the aircraft such as location, altitude, airspeed, battery level, current flight block, and much more to be monitored in real time. Communication from the ground to the aircraft is called datalink. This communication allows commands to be sent to the aircraft from the ground. This includes telling the aircraft what navigation to perform: fly to a waypoint, start the search area, come in for a landing. If a single link is used, as was always the case before this project, then if the aircraft goes out of range, or that link is otherwise lost, no telemetry information can be displayed in the GCS and commands sent from the GCS won't be received by the aircraft. Using the following redundant link system allows multiple links to be used in an effort to avoid this. Typically, you would introduce diversity when adding links. For example:<br />
* If you have an on-board computer, you could tunnel messages through Wi-Fi over UDP in addition to a traditional 900 MHz XBee radio modem.<br />
* You could use a satellite modem for long-range monitoring in addition to a radio modem.<br />
* You could use a cellular modem in addition to a radio modem.<br />
* With additional ground infrastructure, you could have radio modems located at different locations.<br />
* You could use radio modems at different frequencies or with different antenna gains or orientations.<br />
* You could use this system to evaluate different types of radio modems or antenna placements - you'll get real time info on each such as the ping time, received messages rate, and more information could easily be added.<br />
<br />
There are undoubtedly many more possibilities.<br />
<br />
== Aircraft to Ground ==<br />
<br />
===Compatibility===<br />
This project was made to be fully backwards compatible and support the awesome functionality that Paparazzi already has. This includes:<br />
* Completely backwards compatible - includes aircraft configuration files, previous flight logs, existing sessions, etc...<br />
* Logging and replay - if multiple links are used, data received through either link is recorded. Also, replays will include the status of each link as it was during the flight.<br />
* Link features such as USB-serial, audio, UDP, different transport layers, etc...<br />
* Multi-aircraft sessions - also, you can use redundant links for one aircraft, but not for another if desired.<br />
* Multiple aircraft connected to the same link - such as might come up in a mesh configuration where one aircraft relays data from another aircraft.<br />
<br />
===Features===<br />
Enabling redundant communication from the aircraft to the ground enables the following features:<br />
* Redundancy - as long as one link is receiving data, it will be logged and displayed on the GCS.<br />
* Monitoring - the status, ping time, and rate of receiving messages for each link is shown (this makes it useful even if you're only using one link).<br />
* Alerts - new alerts are added to the console in the GCS to alert you when a link has been connected for the first time, lost, or re-gained.<br />
<br />
===Future Improvements===<br />
Several different improvements can be made to this system to improve it's performance and help satisfy future needs that may arise:<br />
* Additional information can easily be added to the Link page of the GCS for each link. For example: errors, % uptime, or a scrolling graph of Rx messages/s.<br />
* The ability to mark different links as either critical or backup. The idea here is that not all links should necessarily be treated equal. Maybe only one link is able to send datalink data to the aircraft (actually, this is the case right now) and so that link should be considered critical. If any other link is lost, then the overall telemetry can be counted as OK. But if the critical link is lost, then the GCS should change the link indicator light to red and start counting up even if the other link(s) are OK.<br />
* The Link Combiner algorithm currently employs a simple circular buffer. This could be improved on by adding a time-stamp to each element of the buffer and only counting two buffer elements to be the same if their timestamps are close enough (say within 2 seconds - this could be configured)<br />
* The Link Combiner algorithm could be improved by making the buffer size adjust automatically with the ping time and Rx messages/s rate. Or if the timestamp improvement is implemented, then the maximum time difference could be adjusted.<br />
* A performance and resource use analysis could be done to optimize the Link Combiner. The circular buffer is currently implemented using Python lists which could probably be improved upon. Also, significantly more ivy messages are sent and received. This might make optimizations to the regex or other parts of the ivybus worthwhile.<br />
<br />
===How to use===<br />
<br />
For an example using two USB-serial adaptors, see the '''Flight USB-serial Redundant''' session saved in the example control_panel.xml configuration (on master branch, once the pull request has been accepted).<br />
<br />
For the details, keep reading:<br />
In order to implement redundant links using this code, there are three simple steps to follow:<br />
<br />
* Connect the hardware - on the airborne side, connect the Rx pin of the autopilot's UART port to multiple radio modems or whatever other device which will get the information to the ground. On the ground side, connect multiple modems as normal (using USB to serial adapters, a UDP connection, or whatever). (note: Once the ground to aircraft redundancy has been implemented, you won't have to split the Rx signal and can just plug each modem into a UART port)<br />
* Launch a Link agent for each modem (in Paparazzi Center, select it from the tools menu). Configure the agents as you would have before (serial port, baud rate, UDP, etc...). None of these features have been modified or removed. Then, use two new command line arguments: -redlink and -id. The -redlink flag tells Link that it's one of multiple links. The -id flag lets you specify an integer number as the id of that particular link.<br />
* Launch the Link Combiner agent (again, from the tools menu). This agent listens to all of the Link agents that have their -redlink set and combines the data.<br />
<br />
The following screenshot shows a session with two links, connected to serial ports ttyUSB0 and ttyUSB1, and with id's 1 and 2:<br />
<br />
[[File:redundant_session.png|alt=Agents in Redundant Link Session|upright=0.2]]<br />
<br />
The Agents Running in a Redundant Link Setup<br />
<br />
* Test the system and make sure that it works correctly under all circumstances. Do this before flying. In particular, make sure that the buffer size if appropriate. Take a look at the [[#Algorithm Considerations|Algorithm Considerations]] section for details.<br />
<br />
===Interface===<br />
Once the redundant link system is started (even if only one Link is used), several changes appear in the GCS. This is achieved by the new message LINK_STATUS which is sent by the Link Combiner. These new features are designed to allow closer monitoring and better management of the link(s) between the aircraft and the ground station.<br />
<br />
The following screenshot clearly shows these changes:<br />
[[File:redundant_link_gcs.png|alt=Changes to the GCS when redundant links are used|upright=0.1]]<br />
<br />
Firstly, we can see that there is a new page in the notebook named Link. This page contains critical information for each link. More information can easily be added, but for now, it shows the status of the link (just like the main Link status indicator in the strip), the current ping time, and the rate of received messages. So if one link is lost, it's status indicator will turn red and start counting up just like link 2 in the above screenshot.<br />
<br />
Next, we can see that the main Link status indicator that's located in the strip has been modified slightly. It now shows the ratio of connected links to the total number of links. I.e. 3/4 means that there are four links and one of them has been lost. Furthermore, the indicator will be green if all links are connected, yellow if one or more are lost, and red if all links are lost. Once all links are lost, the indicator will count up just like before.<br />
<br />
Lastly, alerts have been added to the console. Whenever a link is lost or reconnected, a message will appear in the console stating so. Messages also appear when a new link is added.<br />
<br />
===Design===<br />
====Implementation====<br />
Here's a block diagram showing how the aircraft talks to the various ground segment programs (also known as agents) when not using the redundant link system:<br />
<br />
[[File:ground_segment_block_diagram.png|alt=Block diagram of agents in the ground segment|upright=0.1]]<br />
Paparazzi Ground Segment<br />
<br />
The ivy bus lets the programs talk to each other through the use of short messages. Pay close attention to the coloured arrows, which show the main flow of these messages. Next we have a block diagram of the redundant link system:<br />
<br />
[[File:redundant_links_block_diagram.png|alt=Block diagram of agents in the ground segment when redundant links are used|upright=0.1]]<br />
Paparazzi Ground Segment with Redundant Links<br />
<br />
Here we can see the new agent, the Link Combiner. We also see multiple occurrences of the Link agent. When operating in redundant mode, each occurrence of Link transmits the data it receives from the aircraft to the Link Combiner instead of the Server. It does this by transmitting the received telemetry messages within the TELEMETRY_MESSAGE message which the Server doesn't listen to. The Link Combiner on the other hand does. TELEMETRY_MESSAGE messages are sent by each link and include the id of that link. The Link Combiner listens to all of them and then transmits a single set of messages to the Server with the combined data. This results in the Server and all other ground segment agents (such as Messages and the Real Time Plotter) getting their telemetry data from Link Combiner as if it was coming from a single occurrence of Link.<br />
<br />
====Link Combiner====<br />
The Link Combiner agent is written in Python. It receives messages from all of the Links (when they're in redundant mode: -redlink), and outputs messages to the Server and other ground segment agents. There is a bit involved however since the Server and GCS shouldn't be sent identical messages. I.e. if the aircraft sends a message and it's received successfully by more than one link, then that particular message should only sent by Link Combiner once. This is a somewhat tricky requirement since there is no guarantee that the message will be received by all of the links, and it's possible that the aircraft actually sends a second message that's exactly the same as the first. No extra info (such as a time-stamp or counter) is added to the messages sent from the aircraft to the ground, so the Link Combiner employs an algorithm to detect duplicate messages. Testing has shown that for typical links, this algorithm performs extremely well.<br />
<br />
The algorithm gives each link a circular buffer to store the last N messages. When a new message comes in on a particular link, the algorithm first checks if it's already in that link's buffer. If it is, then it's obviously a new message, so its removed from all of the other buffers if it's in any of them. Then, the message is sent to the other agents. If the message isn't already in the link's buffer, then it's added to the buffer. After that, all of the other link's buffers are checked for the message. If it's in any of them, then the message was already received by another link, so isn't sent. If it's not in any of them, then the message is sent. The following flowchart depicts this algorithm:<br />
<br />
[[File:link_combiner_flowchart.png|alt=Flowchart of the Link Combiner|upright=0.1]]<br />
<br />
Algorithm to prevent duplicate messages<br />
<br />
====Algorithm Considerations====<br />
As the aircraft sends various messages, possibly with the exact same data, and the links gain and lose connection, there is no guarantee that this algorithm will do a perfect job of filtering out identical and only identical messages. However, in typical operation, it seems to work very well. And for the application of displaying aircraft data, the occasional missing or duplicate message is acceptable. There are only a few scenarios where the Link Combiner won't produce perfect results, and they should come up infrequently:<br />
<br />
* A message will be sent twice if the buffer size is too small to hold all of the messages received from one link between that link receiving the message and another link receiving the identical message. When the second link receives the message that has already been received, if the original isn't in the buffer anymore, than the algorithm won't know it's a duplicate message. This scenario should be considered whenever implementing a redundant link system. Partly because it is the most likely to come up, but also because if it does occur, then all messages will be duplicated. In order to avoid this scenario, you can set the buffer size as a command line argument of Link Combiner. To know what a good value would be, you can observer the Ping time and Rx messages/s of the links in the new Link page of the notebook. Calculate the minimum buffer size by taking the difference between the largest ping time and the smallest ping time and multiplying it by the largest Rx messages/s. Then apply a safety factor when setting the buffer size - 10 times the calculated value should be good.<br />
* A message won't be sent when it should be if the autopilot sends a message that's the same as one it already sent (same name and exact same values) AND one or more links were lost between the first message and the second AND the link that's receiving the second message doesn't have the first message in it's buffer still. That's three conditions. If this happens, then the Link Combiner will see the second message as a duplicate of the first and will skip it. Only this one message will be missed though - it won't start happening to all messages. Also, the data will have been data that was already received. So if it's for example the battery voltage message, then it's not a big deal to miss it. As long as there aren't links rapidly being lost and gained, then this shouldn't happen often. Note that as the buffer size is increased, it is believed that this becomes more likely to happen.<br />
<br />
== Ground to Aircraft ==<br />
<br />
This part of the redundant communication system hasn't been implemented yet. All information here is what it is envisioned to look like.<br />
<br />
===Features===<br />
* Enable multiple datalink links to be used for communicating with the autopilot.<br />
* Let different telemetry be sent out each link.<br />
* Let the choice of what telemetry is sent be moved from the settings page of the GCS to the Link page, since it can be different for each link.<br />
* Add a link status indicator (this is the light that turns red when the link is lost) for the datalink to the Link page. This will allow better monitoring of the links by not assuming that if one direction is good, the other direction is good as well.<br />
* Let each link be configured as telemetry only, datalink only, or by-directional.<br />
<br />
===Compatibility===<br />
Communication in the autopilot is enabled with the ground by including the telemetry subsystem in the airframe file. For example:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing or rotorcraft"><br />
...<br />
<subsystem name="telemetry" type="transparent"/><br />
</firmware><br />
</source><br />
}}<br />
<br />
In order to use multiple links, changes should be made to allow a telemetry subsystem for each link. Related to this, would it be advantageous to have multiple instances be supported for each different subsystem? Once the design for this is determined, would actual support for each subsystem have to be added one at a time? Because of the logic for how multiple subsystems should behave together is dependent on the subsystem, this might be the case. The telemetry subsystem for example should default to sending telemetry out each one and combining the telemetry received.<br />
<br />
===Hardware===<br />
Unlike aircraft to ground redundancy, ground to aircraft redundancy requires multiple UART ports in the hardware of the autopilot. The author is not particularly familiar with this, but believes that there are ways to get multiple UART ports for this purpose:<br />
* Telemetry can be sent out over USB by specifying the telemetry type to be "transparent_usb".<br />
* For the Lisa/M, the USB port can actually be used as a UART port with some hardware modifications.<br />
* Using an I2C GPS instead of a UART one can free up a UART port on most autopilots.<br />
* For the Lisa/M, can UART 1 and 5 be used if Spektrum Satellite receivers aren't used? If so, where are the Tx pins?<br />
<br />
In addition, future hardware designs could includes more UART ports for redundant communications or any other purpose.<br />
<br />
===Design===<br />
Unlike the aircraft to ground communication, for ground to aircraft communication it is not acceptable to have the same message be acted on twice. This could cause the aircraft to behave unexpectedly. In order to implement a 100% guaranteed link combiner for the aircraft, the author proposes a system that adds a counter to each message sent to the aircraft. This would allow the autopilot to easily ignore identical messages - they'll have the same value for the counter. Also, since minimal data is sent from the ground to the aircraft, adding the extra bytes to the payload will have a minimal impact on performance - this is not the case for the telemetry.<br />
<br />
The challenging part of this design will be integrating it properly into the existing systems.</div>Camleehttp://wiki.paparazziuav.org/w/index.php?title=Redundant_Communication&diff=14975Redundant Communication2013-04-28T05:13:37Z<p>Camlee: </p>
<hr />
<div><div style="float: right; width: 15%"><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Tools</categorytree></div><br />
<div style="float: right; width: 45%; overflow: hidden">[[Image:link_page.png|center|397px|Link Page in GCS]]</div><br />
<div style="float: right; width: 40%">__TOC__</div><br />
<br />
There is currently a pull request to integrate a redundant communication system into the existing ground segment agents: [https://github.com/paparazzi/paparazzi/pull/429 github.com/paparazzi/paparazzi/pull/429]. The goal of this project is to allow multiple radio modems or other links be used between the aircraft and the ground station in a redundant fashion so that even if one link is lost, communication can be maintained. So far, the aircraft to ground component has been created and tested in the lab. More comprehensive testing should be performed before the system is considered to be stable. The ground to aircraft component has not been created yet.<br />
<br />
===Reasons to redundant links===<br />
Communication from the aircraft to the ground is called telemetry. This communication allows the status of the aircraft such as location, altitude, airspeed, battery level, current flight block, and much more to be monitored in real time. Communication from the ground to the aircraft is called datalink. This communication allows commands to be sent to the aircraft from the ground. This includes telling the aircraft what navigation to perform: fly to a waypoint, start the search area, come in for a landing. If a single link is used, as was always the case before this project, then if the aircraft goes out of range, or that link is otherwise lost, no telemetry information can be displayed in the GCS and commands sent from the GCS won't be received by the aircraft. Using the following redundant link system allows multiple links to be used in an effort to avoid this. Typically, you would introduce diversity when adding links. For example:<br />
* If you have an on-board computer, you could tunnel messages through Wi-Fi over UDP in addition to a traditional 900 MHz XBee radio modem.<br />
* You could use a satellite modem for long-range monitoring in addition to a radio modem.<br />
* You could use a cellular modem in addition to a radio modem.<br />
* With additional ground infrastructure, you could have radio modems located at different locations.<br />
* You could use radio modems at different frequencies or with different antenna gains or orientations.<br />
* You could use this system to evaluate different types of radio modems or antenna placements - you'll get real time info on each such as the ping time, received messages rate, and more information could easily be added.<br />
<br />
There are undoubtedly many more possibilities.<br />
<br />
== Aircraft to Ground ==<br />
<br />
===Compatibility===<br />
This project was made to be fully backwards compatible and support the awesome functionality that Paparazzi already has. This includes:<br />
* Completely backwards compatible - includes aircraft configuration files, previous flight logs, existing sessions, etc...<br />
* Logging and replay - if multiple links are used, data received through either link is recorded. Also, replays will include the status of each link as it was during the flight.<br />
* Link features such as USB-serial, audio, UDP, different transport layers, etc...<br />
* Multi-aircraft sessions - also, you can use redundant links for one aircraft, but not for another if desired.<br />
* Multiple aircraft connected to the same link - such as might come up in a mesh configuration where one aircraft relays data from another aircraft.<br />
<br />
===Features===<br />
Enabling redundant communication from the aircraft to the ground enables the following features:<br />
* Redundancy - as long as one link is receiving data, it will be logged and displayed on the GCS.<br />
* Monitoring - the status, ping time, and rate of receiving messages for each link is shown (this makes it useful even if you're only using one link).<br />
* Alerts - new alerts are added to the console in the GCS to alert you when a link has been connected for the first time, lost, or re-gained.<br />
<br />
===Future Improvements===<br />
Several different improvements can be made to this system to improve it's performance and help satisfy future needs that may arise:<br />
* Additional information can easily be added to the Link page of the GCS for each link. For example: errors, % uptime, or a scrolling graph of Rx messages/s.<br />
* The ability to mark different links as either critical or backup. The idea here is that not all links should necessarily be treated equal. Maybe only one link is able to send datalink data to the aircraft (actually, this is the case right now) and so that link should be considered critical. If any other link is lost, then the overall telemetry can be counted as OK. But if the critical link is lost, then the GCS should change the link indicator light to red and start counting up even if the other link(s) are OK.<br />
* The Link Combiner algorithm currently employs a simple circular buffer. This could be improved on by adding a time-stamp to each element of the buffer and only counting two buffer elements to be the same if their timestamps are close enough (say within 2 seconds - this could be configured)<br />
* The Link Combiner algorithm could be improved by making the buffer size adjust automatically with the ping time and Rx messages/s rate. Or if the timestamp improvement is implemented, then the maximum time difference could be adjusted.<br />
* A performance and resource use analysis could be done to optimize the Link Combiner. The circular buffer is currently implemented using Python lists which could probably be improved upon. Also, significantly more ivy messages are sent and received. This might make optimizations to the regex or other parts of the ivybus worthwhile.<br />
<br />
===How to use===<br />
<br />
For an example using two USB-serial adaptors, see the '''Flight USB-serial Redundant''' session saved in the example control_panel.xml configuration (on master branch, once the pull request has been accepted).<br />
<br />
For the details, keep reading:<br />
In order to implement redundant links using this code, there are three simple steps to follow:<br />
<br />
* Connect the hardware - on the airborne side, connect the Rx pin of the autopilot's UART port to multiple radio modems or whatever other device which will get the information to the ground. On the ground side, connect multiple modems as normal (using USB to serial adapters, a UDP connection, or whatever). (note: Once the ground to aircraft redundancy has been implemented, you won't have to split the Rx signal and can just plug each modem into a UART port)<br />
* Launch a Link agent for each modem (in Paparazzi Center, select it from the tools menu). Configure the agents as you would have before (serial port, baud rate, UDP, etc...). None of these features have been modified or removed. Then, use two new command line arguments: -redlink and -id. The -redlink flag tells Link that it's one of multiple links. The -id flag lets you specify an integer number as the id of that particular link.<br />
* Launch the Link Combiner agent (again, from the tools menu). This agent listens to all of the Link agents that have their -redlink set and combines the data.<br />
<br />
The following screenshot shows a session with two links, connected to serial ports ttyUSB0 and ttyUSB1, and with id's 1 and 2:<br />
<br />
[[File:redundant_session.png|alt=Agents in Redundant Link Session|upright=0.5]]<br />
<br />
The Agents Running in a Redundant Link Setup<br />
<br />
* Test the system and make sure that it works correctly under all circumstances. Do this before flying. In particular, make sure that the buffer size if appropriate. Take a look at the [[#Algorithm Considerations|Algorithm Considerations]] section for details.<br />
<br />
===Interface===<br />
Once the redundant link system is started (even if only one Link is used), several changes appear in the GCS. This is achieved by the new message LINK_STATUS which is sent by the Link Combiner. These new features are designed to allow closer monitoring and better management of the link(s) between the aircraft and the ground station.<br />
<br />
The following screenshot clearly shows these changes:<br />
[[File:redundant_link_gcs.png|alt=Changes to the GCS when redundant links are used|upright=0.25]]<br />
<br />
Firstly, we can see that there is a new page in the notebook named Link. This page contains critical information for each link. More information can easily be added, but for now, it shows the status of the link (just like the main Link status indicator in the strip), the current ping time, and the rate of received messages. So if one link is lost, it's status indicator will turn red and start counting up just like link 2 in the above screenshot.<br />
<br />
Next, we can see that the main Link status indicator that's located in the strip has been modified slightly. It now shows the ratio of connected links to the total number of links. I.e. 3/4 means that there are four links and one of them has been lost. Furthermore, the indicator will be green if all links are connected, yellow if one or more are lost, and red if all links are lost. Once all links are lost, the indicator will count up just like before.<br />
<br />
Lastly, alerts have been added to the console. Whenever a link is lost or reconnected, a message will appear in the console stating so. Messages also appear when a new link is added.<br />
<br />
===Design===<br />
====Implementation====<br />
Here's a block diagram showing how the aircraft talks to the various ground segment programs (also known as agents) when not using the redundant link system:<br />
<br />
[[File:ground_segment_block_diagram.png|alt=Block diagram of agents in the ground segment|upright=0.25]]<br />
Paparazzi Ground Segment<br />
<br />
The ivy bus lets the programs talk to each other through the use of short messages. Pay close attention to the coloured arrows, which show the main flow of these messages. Next we have a block diagram of the redundant link system:<br />
<br />
[[File:redundant_links_block_diagram.png|alt=Block diagram of agents in the ground segment when redundant links are used|upright=0.25]]<br />
Paparazzi Ground Segment with Redundant Links<br />
<br />
Here we can see the new agent, the Link Combiner. We also see multiple occurrences of the Link agent. When operating in redundant mode, each occurrence of Link transmits the data it receives from the aircraft to the Link Combiner instead of the Server. It does this by transmitting the received telemetry messages within the TELEMETRY_MESSAGE message which the Server doesn't listen to. The Link Combiner on the other hand does. TELEMETRY_MESSAGE messages are sent by each link and include the id of that link. The Link Combiner listens to all of them and then transmits a single set of messages to the Server with the combined data. This results in the Server and all other ground segment agents (such as Messages and the Real Time Plotter) getting their telemetry data from Link Combiner as if it was coming from a single occurrence of Link.<br />
<br />
====Link Combiner====<br />
The Link Combiner agent is written in Python. It receives messages from all of the Links (when they're in redundant mode: -redlink), and outputs messages to the Server and other ground segment agents. There is a bit involved however since the Server and GCS shouldn't be sent identical messages. I.e. if the aircraft sends a message and it's received successfully by more than one link, then that particular message should only sent by Link Combiner once. This is a somewhat tricky requirement since there is no guarantee that the message will be received by all of the links, and it's possible that the aircraft actually sends a second message that's exactly the same as the first. No extra info (such as a time-stamp or counter) is added to the messages sent from the aircraft to the ground, so the Link Combiner employs an algorithm to detect duplicate messages. Testing has shown that for typical links, this algorithm performs extremely well.<br />
<br />
The algorithm gives each link a circular buffer to store the last N messages. When a new message comes in on a particular link, the algorithm first checks if it's already in that link's buffer. If it is, then it's obviously a new message, so its removed from all of the other buffers if it's in any of them. Then, the message is sent to the other agents. If the message isn't already in the link's buffer, then it's added to the buffer. After that, all of the other link's buffers are checked for the message. If it's in any of them, then the message was already received by another link, so isn't sent. If it's not in any of them, then the message is sent. The following flowchart depicts this algorithm:<br />
<br />
[[File:link_combiner_flowchart.png|alt=Flowchart of the Link Combiner|upright=0.25]]<br />
<br />
Algorithm to prevent duplicate messages<br />
<br />
====Algorithm Considerations====<br />
As the aircraft sends various messages, possibly with the exact same data, and the links gain and lose connection, there is no guarantee that this algorithm will do a perfect job of filtering out identical and only identical messages. However, in typical operation, it seems to work very well. And for the application of displaying aircraft data, the occasional missing or duplicate message is acceptable. There are only a few scenarios where the Link Combiner won't produce perfect results, and they should come up infrequently:<br />
<br />
* A message will be sent twice if the buffer size is too small to hold all of the messages received from one link between that link receiving the message and another link receiving the identical message. When the second link receives the message that has already been received, if the original isn't in the buffer anymore, than the algorithm won't know it's a duplicate message. This scenario should be considered whenever implementing a redundant link system. Partly because it is the most likely to come up, but also because if it does occur, then all messages will be duplicated. In order to avoid this scenario, you can set the buffer size as a command line argument of Link Combiner. To know what a good value would be, you can observer the Ping time and Rx messages/s of the links in the new Link page of the notebook. Calculate the minimum buffer size by taking the difference between the largest ping time and the smallest ping time and multiplying it by the largest Rx messages/s. Then apply a safety factor when setting the buffer size - 10 times the calculated value should be good.<br />
* A message won't be sent when it should be if the autopilot sends a message that's the same as one it already sent (same name and exact same values) AND one or more links were lost between the first message and the second AND the link that's receiving the second message doesn't have the first message in it's buffer still. That's three conditions. If this happens, then the Link Combiner will see the second message as a duplicate of the first and will skip it. Only this one message will be missed though - it won't start happening to all messages. Also, the data will have been data that was already received. So if it's for example the battery voltage message, then it's not a big deal to miss it. As long as there aren't links rapidly being lost and gained, then this shouldn't happen often. Note that as the buffer size is increased, it is believed that this becomes more likely to happen.<br />
<br />
== Ground to Aircraft ==<br />
<br />
This part of the redundant communication system hasn't been implemented yet. All information here is what it is envisioned to look like.<br />
<br />
===Features===<br />
* Enable multiple datalink links to be used for communicating with the autopilot.<br />
* Let different telemetry be sent out each link.<br />
* Let the choice of what telemetry is sent be moved from the settings page of the GCS to the Link page, since it can be different for each link.<br />
* Add a link status indicator (this is the light that turns red when the link is lost) for the datalink to the Link page. This will allow better monitoring of the links by not assuming that if one direction is good, the other direction is good as well.<br />
* Let each link be configured as telemetry only, datalink only, or by-directional.<br />
<br />
===Compatibility===<br />
Communication in the autopilot is enabled with the ground by including the telemetry subsystem in the airframe file. For example:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing or rotorcraft"><br />
...<br />
<subsystem name="telemetry" type="transparent"/><br />
</firmware><br />
</source><br />
}}<br />
<br />
In order to use multiple links, changes should be made to allow a telemetry subsystem for each link. Related to this, would it be advantageous to have multiple instances be supported for each different subsystem? Once the design for this is determined, would actual support for each subsystem have to be added one at a time? Because of the logic for how multiple subsystems should behave together is dependent on the subsystem, this might be the case. The telemetry subsystem for example should default to sending telemetry out each one and combining the telemetry received.<br />
<br />
===Hardware===<br />
Unlike aircraft to ground redundancy, ground to aircraft redundancy requires multiple UART ports in the hardware of the autopilot. The author is not particularly familiar with this, but believes that there are ways to get multiple UART ports for this purpose:<br />
* Telemetry can be sent out over USB by specifying the telemetry type to be "transparent_usb".<br />
* For the Lisa/M, the USB port can actually be used as a UART port with some hardware modifications.<br />
* Using an I2C GPS instead of a UART one can free up a UART port on most autopilots.<br />
* For the Lisa/M, can UART 1 and 5 be used if Spektrum Satellite receivers aren't used? If so, where are the Tx pins?<br />
<br />
In addition, future hardware designs could includes more UART ports for redundant communications or any other purpose.<br />
<br />
===Design===<br />
Unlike the aircraft to ground communication, for ground to aircraft communication it is not acceptable to have the same message be acted on twice. This could cause the aircraft to behave unexpectedly. In order to implement a 100% guaranteed link combiner for the aircraft, the author proposes a system that adds a counter to each message sent to the aircraft. This would allow the autopilot to easily ignore identical messages - they'll have the same value for the counter. Also, since minimal data is sent from the ground to the aircraft, adding the extra bytes to the payload will have a minimal impact on performance - this is not the case for the telemetry.<br />
<br />
The challenging part of this design will be integrating it properly into the existing systems.</div>Camleehttp://wiki.paparazziuav.org/w/index.php?title=File:Link_combiner_flowchart.png&diff=14974File:Link combiner flowchart.png2013-04-28T05:07:21Z<p>Camlee: Algorithm used by the Link Combiner to combine messages when using multiple links.</p>
<hr />
<div>Algorithm used by the Link Combiner to combine messages when using multiple links.</div>Camleehttp://wiki.paparazziuav.org/w/index.php?title=File:Redundant_links_block_diagram.png&diff=14973File:Redundant links block diagram.png2013-04-28T05:06:14Z<p>Camlee: uploaded a new version of "File:Redundant links block diagram.png":&#32;Block diagram of the redundant link system.</p>
<hr />
<div></div>Camleehttp://wiki.paparazziuav.org/w/index.php?title=File:Redundant_links_block_diagram.png&diff=14972File:Redundant links block diagram.png2013-04-28T05:05:28Z<p>Camlee: </p>
<hr />
<div></div>Camleehttp://wiki.paparazziuav.org/w/index.php?title=File:Ground_segment_block_diagram.png&diff=14971File:Ground segment block diagram.png2013-04-28T05:04:41Z<p>Camlee: </p>
<hr />
<div></div>Camleehttp://wiki.paparazziuav.org/w/index.php?title=File:Redundant_link_gcs.png&diff=14970File:Redundant link gcs.png2013-04-28T05:03:27Z<p>Camlee: Screenshot of the GCS with multiple, redundant links running.</p>
<hr />
<div>Screenshot of the GCS with multiple, redundant links running.</div>Camleehttp://wiki.paparazziuav.org/w/index.php?title=File:Redundant_session.png&diff=14969File:Redundant session.png2013-04-28T05:02:21Z<p>Camlee: Agents running the Paparazzi Center when using redundant links.</p>
<hr />
<div>Agents running the Paparazzi Center when using redundant links.</div>Camleehttp://wiki.paparazziuav.org/w/index.php?title=Redundant_Communication&diff=14968Redundant Communication2013-04-28T05:00:50Z<p>Camlee: </p>
<hr />
<div><div style="float: right; width: 15%"><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Tools</categorytree></div><br />
<div style="float: right; width: 45%; overflow: hidden">[[Image:link_page.png|center|397px|Link Page in GCS]]</div><br />
<div style="float: right; width: 40%">__TOC__</div><br />
<br />
There is currently a pull request to integrate a redundant communication system into the existing ground segment agents: [https://github.com/paparazzi/paparazzi/pull/429 github.com/paparazzi/paparazzi/pull/429]. The goal of this project is to allow multiple radio modems or other links be used between the aircraft and the ground station in a redundant fashion so that even if one link is lost, communication can be maintained. So far, the aircraft to ground component has been created and tested in the lab. More comprehensive testing should be performed before the system is considered to be stable. The ground to aircraft component has not been created yet.<br />
<br />
===Reasons to redundant links===<br />
Communication from the aircraft to the ground is called telemetry. This communication allows the status of the aircraft such as location, altitude, airspeed, battery level, current flight block, and much more to be monitored in real time. Communication from the ground to the aircraft is called datalink. This communication allows commands to be sent to the aircraft from the ground. This includes telling the aircraft what navigation to perform: fly to a waypoint, start the search area, come in for a landing. If a single link is used, as was always the case before this project, then if the aircraft goes out of range, or that link is otherwise lost, no telemetry information can be displayed in the GCS and commands sent from the GCS won't be received by the aircraft. Using the following redundant link system allows multiple links to be used in an effort to avoid this. Typically, you would introduce diversity when adding links. For example:<br />
* If you have an on-board computer, you could tunnel messages through Wi-Fi over UDP in addition to a traditional 900 MHz XBee radio modem.<br />
* You could use a satellite modem for long-range monitoring in addition to a radio modem.<br />
* You could use a cellular modem in addition to a radio modem.<br />
* With additional ground infrastructure, you could have radio modems located at different locations.<br />
* You could use radio modems at different frequencies or with different antenna gains or orientations.<br />
* You could use this system to evaluate different types of radio modems or antenna placements - you'll get real time info on each such as the ping time, received messages rate, and more information could easily be added.<br />
<br />
There are undoubtedly many more possibilities.<br />
<br />
== Aircraft to Ground ==<br />
<br />
===Compatibility===<br />
This project was made to be fully backwards compatible and support the awesome functionality that Paparazzi already has. This includes:<br />
* Completely backwards compatible - includes aircraft configuration files, previous flight logs, existing sessions, etc...<br />
* Logging and replay - if multiple links are used, data received through either link is recorded. Also, replays will include the status of each link as it was during the flight.<br />
* Link features such as USB-serial, audio, UDP, different transport layers, etc...<br />
* Multi-aircraft sessions - also, you can use redundant links for one aircraft, but not for another if desired.<br />
* Multiple aircraft connected to the same link - such as might come up in a mesh configuration where one aircraft relays data from another aircraft.<br />
<br />
===Features===<br />
Enabling redundant communication from the aircraft to the ground enables the following features:<br />
* Redundancy - as long as one link is receiving data, it will be logged and displayed on the GCS.<br />
* Monitoring - the status, ping time, and rate of receiving messages for each link is shown (this makes it useful even if you're only using one link).<br />
* Alerts - new alerts are added to the console in the GCS to alert you when a link has been connected for the first time, lost, or re-gained.<br />
<br />
===Future Improvements===<br />
Several different improvements can be made to this system to improve it's performance and help satisfy future needs that may arise:<br />
* Additional information can easily be added to the Link page of the GCS for each link. For example: errors, % uptime, or a scrolling graph of Rx messages/s.<br />
* The ability to mark different links as either critical or backup. The idea here is that not all links should necessarily be treated equal. Maybe only one link is able to send datalink data to the aircraft (actually, this is the case right now) and so that link should be considered critical. If any other link is lost, then the overall telemetry can be counted as OK. But if the critical link is lost, then the GCS should change the link indicator light to red and start counting up even if the other link(s) are OK.<br />
* The Link Combiner algorithm currently employs a simple circular buffer. This could be improved on by adding a time-stamp to each element of the buffer and only counting two buffer elements to be the same if their timestamps are close enough (say within 2 seconds - this could be configured)<br />
* The Link Combiner algorithm could be improved by making the buffer size adjust automatically with the ping time and Rx messages/s rate. Or if the timestamp improvement is implemented, then the maximum time difference could be adjusted.<br />
* A performance and resource use analysis could be done to optimize the Link Combiner. The circular buffer is currently implemented using Python lists which could probably be improved upon. Also, significantly more ivy messages are sent and received. This might make optimizations to the regex or other parts of the ivybus worthwhile.<br />
<br />
===How to use===<br />
<br />
For an example using two USB-serial adaptors, see the '''Flight USB-serial Redundant''' session saved in the example control_panel.xml configuration (on master branch, once the pull request has been accepted).<br />
<br />
For the details, keep reading:<br />
In order to implement redundant links using this code, there are three simple steps to follow:<br />
<br />
* Connect the hardware - on the airborne side, connect the Rx pin of the autopilot's UART port to multiple radio modems or whatever other device which will get the information to the ground. On the ground side, connect multiple modems as normal (using USB to serial adapters, a UDP connection, or whatever). (note: Once the ground to aircraft redundancy has been implemented, you won't have to split the Rx signal and can just plug each modem into a UART port)<br />
* Launch a Link agent for each modem (in Paparazzi Center, select it from the tools menu). Configure the agents as you would have before (serial port, baud rate, UDP, etc...). None of these features have been modified or removed. Then, use two new command line arguments: -redlink and -id. The -redlink flag tells Link that it's one of multiple links. The -id flag lets you specify an integer number as the id of that particular link.<br />
* Launch the Link Combiner agent (again, from the tools menu). This agent listens to all of the Link agents that have their -redlink set and combines the data.<br />
<br />
The following screenshot shows a session with two links, connected to serial ports ttyUSB0 and ttyUSB1, and with id's 1 and 2:<br />
<br />
[[File:redundant_session.png|alt=Agents in Redundant Link Session]]<br />
The Agents Running in a Redundant Link Setup<br />
<br />
* Test the system and make sure that it works correctly under all circumstances. Do this before flying. In particular, make sure that the buffer size if appropriate. Take a look at the [[#Algorithm Considerations|Algorithm Considerations]] section for details.<br />
<br />
===Interface===<br />
Once the redundant link system is started (even if only one Link is used), several changes appear in the GCS. This is achieved by the new message LINK_STATUS which is sent by the Link Combiner. These new features are designed to allow closer monitoring and better management of the link(s) between the aircraft and the ground station.<br />
<br />
The following screenshot clearly shows these changes:<br />
[[File:redundant_link_gcs.png|alt=Changes to the GCS when redundant links are used]]<br />
<br />
Firstly, we can see that there is a new page in the notebook named Link. This page contains critical information for each link. More information can easily be added, but for now, it shows the status of the link (just like the main Link status indicator in the strip), the current ping time, and the rate of received messages. So if one link is lost, it's status indicator will turn red and start counting up just like link 2 in the above screenshot.<br />
<br />
Next, we can see that the main Link status indicator that's located in the strip has been modified slightly. It now shows the ratio of connected links to the total number of links. I.e. 3/4 means that there are four links and one of them has been lost. Furthermore, the indicator will be green if all links are connected, yellow if one or more are lost, and red if all links are lost. Once all links are lost, the indicator will count up just like before.<br />
<br />
Lastly, alerts have been added to the console. Whenever a link is lost or reconnected, a message will appear in the console stating so. Messages also appear when a new link is added.<br />
<br />
===Design===<br />
====Implementation====<br />
Here's a block diagram showing how the aircraft talks to the various ground segment programs (also known as agents) when not using the redundant link system:<br />
<br />
[[File:ground_segment_block_diagram.png|alt=Block diagram of agents in the ground segment]]<br />
Paparazzi Ground Segment<br />
<br />
The ivy bus lets the programs talk to each other through the use of short messages. Pay close attention to the coloured arrows, which show the main flow of these messages. Next we have a block diagram of the redundant link system:<br />
<br />
[[File:redundant_links_block_diagram.png|alt=Block diagram of agents in the ground segment when redundant links are used]]<br />
Paparazzi Ground Segment with Redundant Links<br />
<br />
Here we can see the new agent, the Link Combiner. We also see multiple occurrences of the Link agent. When operating in redundant mode, each occurrence of Link transmits the data it receives from the aircraft to the Link Combiner instead of the Server. It does this by transmitting the received telemetry messages within the TELEMETRY_MESSAGE message which the Server doesn't listen to. The Link Combiner on the other hand does. TELEMETRY_MESSAGE messages are sent by each link and include the id of that link. The Link Combiner listens to all of them and then transmits a single set of messages to the Server with the combined data. This results in the Server and all other ground segment agents (such as Messages and the Real Time Plotter) getting their telemetry data from Link Combiner as if it was coming from a single occurrence of Link.<br />
<br />
====Link Combiner====<br />
The Link Combiner agent is written in Python. It receives messages from all of the Links (when they're in redundant mode: -redlink), and outputs messages to the Server and other ground segment agents. There is a bit involved however since the Server and GCS shouldn't be sent identical messages. I.e. if the aircraft sends a message and it's received successfully by more than one link, then that particular message should only sent by Link Combiner once. This is a somewhat tricky requirement since there is no guarantee that the message will be received by all of the links, and it's possible that the aircraft actually sends a second message that's exactly the same as the first. No extra info (such as a time-stamp or counter) is added to the messages sent from the aircraft to the ground, so the Link Combiner employs an algorithm to detect duplicate messages. Testing has shown that for typical links, this algorithm performs extremely well.<br />
<br />
The algorithm gives each link a circular buffer to store the last N messages. When a new message comes in on a particular link, the algorithm first checks if it's already in that link's buffer. If it is, then it's obviously a new message, so its removed from all of the other buffers if it's in any of them. Then, the message is sent to the other agents. If the message isn't already in the link's buffer, then it's added to the buffer. After that, all of the other link's buffers are checked for the message. If it's in any of them, then the message was already received by another link, so isn't sent. If it's not in any of them, then the message is sent. The following flowchart depicts this algorithm:<br />
<br />
[[File:link_combiner_flowchart.png|alt=Flowchart of the Link Combiner]]<br />
Algorithm to prevent duplicate messages<br />
<br />
====Algorithm Considerations====<br />
As the aircraft sends various messages, possibly with the exact same data, and the links gain and lose connection, there is no guarantee that this algorithm will do a perfect job of filtering out identical and only identical messages. However, in typical operation, it seems to work very well. And for the application of displaying aircraft data, the occasional missing or duplicate message is acceptable. There are only a few scenarios where the Link Combiner won't produce perfect results, and they should come up infrequently:<br />
<br />
* A message will be sent twice if the buffer size is too small to hold all of the messages received from one link between that link receiving the message and another link receiving the identical message. When the second link receives the message that has already been received, if the original isn't in the buffer anymore, than the algorithm won't know it's a duplicate message. This scenario should be considered whenever implementing a redundant link system. Partly because it is the most likely to come up, but also because if it does occur, then all messages will be duplicated. In order to avoid this scenario, you can set the buffer size as a command line argument of Link Combiner. To know what a good value would be, you can observer the Ping time and Rx messages/s of the links in the new Link page of the notebook. Calculate the minimum buffer size by taking the difference between the largest ping time and the smallest ping time and multiplying it by the largest Rx messages/s. Then apply a safety factor when setting the buffer size - 10 times the calculated value should be good.<br />
* A message won't be sent when it should be if the autopilot sends a message that's the same as one it already sent (same name and exact same values) AND one or more links were lost between the first message and the second AND the link that's receiving the second message doesn't have the first message in it's buffer still. That's three conditions. If this happens, then the Link Combiner will see the second message as a duplicate of the first and will skip it. Only this one message will be missed though - it won't start happening to all messages. Also, the data will have been data that was already received. So if it's for example the battery voltage message, then it's not a big deal to miss it. As long as there aren't links rapidly being lost and gained, then this shouldn't happen often. Note that as the buffer size is increased, it is believed that this becomes more likely to happen.<br />
<br />
== Ground to Aircraft ==<br />
<br />
This part of the redundant communication system hasn't been implemented yet. All information here is what it is envisioned to look like.<br />
<br />
===Features===<br />
* Enable multiple datalink links to be used for communicating with the autopilot.<br />
* Let different telemetry be sent out each link.<br />
* Let the choice of what telemetry is sent be moved from the settings page of the GCS to the Link page, since it can be different for each link.<br />
* Add a link status indicator (this is the light that turns red when the link is lost) for the datalink to the Link page. This will allow better monitoring of the links by not assuming that if one direction is good, the other direction is good as well.<br />
* Let each link be configured as telemetry only, datalink only, or by-directional.<br />
<br />
===Compatibility===<br />
Communication in the autopilot is enabled with the ground by including the telemetry subsystem in the airframe file. For example:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing or rotorcraft"><br />
...<br />
<subsystem name="telemetry" type="transparent"/><br />
</firmware><br />
</source><br />
}}<br />
<br />
In order to use multiple links, changes should be made to allow a telemetry subsystem for each link. Related to this, would it be advantageous to have multiple instances be supported for each different subsystem? Once the design for this is determined, would actual support for each subsystem have to be added one at a time? Because of the logic for how multiple subsystems should behave together is dependent on the subsystem, this might be the case. The telemetry subsystem for example should default to sending telemetry out each one and combining the telemetry received.<br />
<br />
===Hardware===<br />
Unlike aircraft to ground redundancy, ground to aircraft redundancy requires multiple UART ports in the hardware of the autopilot. The author is not particularly familiar with this, but believes that there are ways to get multiple UART ports for this purpose:<br />
* Telemetry can be sent out over USB by specifying the telemetry type to be "transparent_usb".<br />
* For the Lisa/M, the USB port can actually be used as a UART port with some hardware modifications.<br />
* Using an I2C GPS instead of a UART one can free up a UART port on most autopilots.<br />
* For the Lisa/M, can UART 1 and 5 be used if Spektrum Satellite receivers aren't used? If so, where are the Tx pins?<br />
<br />
In addition, future hardware designs could includes more UART ports for redundant communications or any other purpose.<br />
<br />
===Design===<br />
Unlike the aircraft to ground communication, for ground to aircraft communication it is not acceptable to have the same message be acted on twice. This could cause the aircraft to behave unexpectedly. In order to implement a 100% guaranteed link combiner for the aircraft, the author proposes a system that adds a counter to each message sent to the aircraft. This would allow the autopilot to easily ignore identical messages - they'll have the same value for the counter. Also, since minimal data is sent from the ground to the aircraft, adding the extra bytes to the payload will have a minimal impact on performance - this is not the case for the telemetry.<br />
<br />
The challenging part of this design will be integrating it properly into the existing systems.</div>Camleehttp://wiki.paparazziuav.org/w/index.php?title=File:Link_page.png&diff=14967File:Link page.png2013-04-28T04:53:18Z<p>Camlee: Multiple links appear in the link page of the GCS when using redundant links.</p>
<hr />
<div>Multiple links appear in the link page of the GCS when using redundant links.</div>Camleehttp://wiki.paparazziuav.org/w/index.php?title=Redundant_Communication&diff=14966Redundant Communication2013-04-28T04:52:10Z<p>Camlee: </p>
<hr />
<div><div style="float: right; width: 15%"><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Tools</categorytree></div><br />
<div style="float: right; width: 45%; overflow: hidden">[[Image:link_page.png|right|397px|Link Page in GCS]]</div><br />
<div style="float: right; width: 40%">__TOC__</div><br />
<br />
There is currently a pull request to integrate a redundant communication system into the existing ground segment agents: [https://github.com/paparazzi/paparazzi/pull/429 github.com/paparazzi/paparazzi/pull/429]. The goal of this project is to allow multiple radio modems or other links be used between the aircraft and the ground station in a redundant fashion so that even if one link is lost, communication can be maintained. So far, the aircraft to ground component has been created and tested in the lab. More comprehensive testing should be performed before the system is considered to be stable. The ground to aircraft component has not been created yet.<br />
<br />
===Reasons to redundant links===<br />
Communication from the aircraft to the ground is called telemetry. This communication allows the status of the aircraft such as location, altitude, airspeed, battery level, current flight block, and much more to be monitored in real time. Communication from the ground to the aircraft is called datalink. This communication allows commands to be sent to the aircraft from the ground. This includes telling the aircraft what navigation to perform: fly to a waypoint, start the search area, come in for a landing. If a single link is used, as was always the case before this project, then if the aircraft goes out of range, or that link is otherwise lost, no telemetry information can be displayed in the GCS and commands sent from the GCS won't be received by the aircraft. Using the following redundant link system allows multiple links to be used in an effort to avoid this. Typically, you would introduce diversity when adding links. For example:<br />
* If you have an on-board computer, you could tunnel messages through Wi-Fi over UDP in addition to a traditional 900 MHz XBee radio modem.<br />
* You could use a satellite modem for long-range monitoring in addition to a radio modem.<br />
* You could use a cellular modem in addition to a radio modem.<br />
* With additional ground infrastructure, you could have radio modems located at different locations.<br />
* You could use radio modems at different frequencies or with different antenna gains or orientations.<br />
* You could use this system to evaluate different types of radio modems or antenna placements - you'll get real time info on each such as the ping time, received messages rate, and more information could easily be added.<br />
<br />
There are undoubtedly many more possibilities.<br />
<br />
== Aircraft to Ground ==<br />
<br />
===Compatibility===<br />
This project was made to be fully backwards compatible and support the awesome functionality that Paparazzi already has. This includes:<br />
* Completely backwards compatible - includes aircraft configuration files, previous flight logs, existing sessions, etc...<br />
* Logging and replay - if multiple links are used, data received through either link is recorded. Also, replays will include the status of each link as it was during the flight.<br />
* Link features such as USB-serial, audio, UDP, different transport layers, etc...<br />
* Multi-aircraft sessions - also, you can use redundant links for one aircraft, but not for another if desired.<br />
* Multiple aircraft connected to the same link - such as might come up in a mesh configuration where one aircraft relays data from another aircraft.<br />
<br />
===Features===<br />
Enabling redundant communication from the aircraft to the ground enables the following features:<br />
* Redundancy - as long as one link is receiving data, it will be logged and displayed on the GCS.<br />
* Monitoring - the status, ping time, and rate of receiving messages for each link is shown (this makes it useful even if you're only using one link).<br />
* Alerts - new alerts are added to the console in the GCS to alert you when a link has been connected for the first time, lost, or re-gained.<br />
<br />
===Future Improvements===<br />
Several different improvements can be made to this system to improve it's performance and help satisfy future needs that may arise:<br />
* Additional information can easily be added to the Link page of the GCS for each link. For example: errors, % uptime, or a scrolling graph of Rx messages/s.<br />
* The ability to mark different links as either critical or backup. The idea here is that not all links should necessarily be treated equal. Maybe only one link is able to send datalink data to the aircraft (actually, this is the case right now) and so that link should be considered critical. If any other link is lost, then the overall telemetry can be counted as OK. But if the critical link is lost, then the GCS should change the link indicator light to red and start counting up even if the other link(s) are OK.<br />
* The Link Combiner algorithm currently employs a simple circular buffer. This could be improved on by adding a time-stamp to each element of the buffer and only counting two buffer elements to be the same if their timestamps are close enough (say within 2 seconds - this could be configured)<br />
* The Link Combiner algorithm could be improved by making the buffer size adjust automatically with the ping time and Rx messages/s rate. Or if the timestamp improvement is implemented, then the maximum time difference could be adjusted.<br />
* A performance and resource use analysis could be done to optimize the Link Combiner. The circular buffer is currently implemented using Python lists which could probably be improved upon. Also, significantly more ivy messages are sent and received. This might make optimizations to the regex or other parts of the ivybus worthwhile.<br />
<br />
===How to use===<br />
<br />
For an example using two USB-serial adaptors, see the '''Flight USB-serial Redundant''' session saved in the example control_panel.xml configuration (on master branch, once the pull request has been accepted).<br />
<br />
For the details, keep reading:<br />
In order to implement redundant links using this code, there are three simple steps to follow:<br />
<br />
* Connect the hardware - on the airborne side, connect the Rx pin of the autopilot's UART port to multiple radio modems or whatever other device which will get the information to the ground. On the ground side, connect multiple modems as normal (using USB to serial adapters, a UDP connection, or whatever). (note: Once the ground to aircraft redundancy has been implemented, you won't have to split the Rx signal and can just plug each modem into a UART port)<br />
* Launch a Link agent for each modem (in Paparazzi Center, select it from the tools menu). Configure the agents as you would have before (serial port, baud rate, UDP, etc...). None of these features have been modified or removed. Then, use two new command line arguments: -redlink and -id. The -redlink flag tells Link that it's one of multiple links. The -id flag lets you specify an integer number as the id of that particular link.<br />
* Launch the Link Combiner agent (again, from the tools menu). This agent listens to all of the Link agents that have their -redlink set and combines the data.<br />
<br />
The following screenshot shows a session with two links, connected to serial ports ttyUSB0 and ttyUSB1, and with id's 1 and 2:<br />
<br />
http://2.bp.blogspot.com/-4ytdpqXMHa0/UXMlR-qGkbI/AAAAAAAAEZw/JO959QjWip4/s640/Screenshot+from+2013-04-15+23_02_27.png<br />
Caption: The Agents Running in a Redundant Link Setup<br />
<br />
* Test the system and make sure that it works correctly under all circumstances. Do this before flying. In particular, make sure that the buffer size if appropriate. Take a look at the [[#Algorithm Considerations|Algorithm Considerations]] section for details.<br />
<br />
===Interface===<br />
Once the redundant link system is started (even if only one Link is used), several changes appear in the GCS. This is achieved by the new message LINK_STATUS which is sent by the Link Combiner. These new features are designed to allow closer monitoring and better management of the link(s) between the aircraft and the ground station.<br />
<br />
The following screenshot clearly shows these changes:<br />
http://3.bp.blogspot.com/-jI7EMZ_0614/UXMjlc1MoBI/AAAAAAAAEZo/LwOgVQN336o/s640/Screenshot+from+2013-04-15+22_59_01.png<br />
<br />
Firstly, we can see that there is a new page in the notebook named Link. This page contains critical information for each link. More information can easily be added, but for now, it shows the status of the link (just like the main Link status indicator in the strip), the current ping time, and the rate of received messages. So if one link is lost, it's status indicator will turn red and start counting up just like link 2 in the above screenshot.<br />
<br />
Next, we can see that the main Link status indicator that's located in the strip has been modified slightly. It now shows the ratio of connected links to the total number of links. I.e. 3/4 means that there are four links and one of them has been lost. Furthermore, the indicator will be green if all links are connected, yellow if one or more are lost, and red if all links are lost. Once all links are lost, the indicator will count up just like before.<br />
<br />
Lastly, alerts have been added to the console. Whenever a link is lost or reconnected, a message will appear in the console stating so. Messages also appear when a new link is added.<br />
<br />
===Design===<br />
====Implementation====<br />
Here's a block diagram showing how the aircraft talks to the various ground segment programs (also known as agents) when not using the redundant link system:<br />
<br />
http://3.bp.blogspot.com/-8-YENO6LcNs/UXMRpkJlx1I/AAAAAAAAEZQ/Z3XDrJCRzQs/s400/Normal+Communication+Layout.png<br />
Caption: Paparazzi Ground Segment<br />
<br />
The ivy bus lets the programs talk to each other through the use of short messages. Pay close attention to the coloured arrows, which show the main flow of these messages. Next we have a block diagram of the redundant link system:<br />
<br />
http://4.bp.blogspot.com/-nx_p90B7FU4/UXMddbJ_gEI/AAAAAAAAEZg/qnbrS-bS3l0/s640/Redundant+Communication+Layout.png<br />
Caption: Paparazzi Ground Segment with Redundant Links<br />
<br />
Here we can see the new agent, the Link Combiner. We also see multiple occurrences of the Link agent. When operating in redundant mode, each occurrence of Link transmits the data it receives from the aircraft to the Link Combiner instead of the Server. It does this by transmitting the received telemetry messages within the TELEMETRY_MESSAGE message which the Server doesn't listen to. The Link Combiner on the other hand does. TELEMETRY_MESSAGE messages are sent by each link and include the id of that link. The Link Combiner listens to all of them and then transmits a single set of messages to the Server with the combined data. This results in the Server and all other ground segment agents (such as Messages and the Real Time Plotter) getting their telemetry data from Link Combiner as if it was coming from a single occurrence of Link.<br />
<br />
====Link Combiner====<br />
The Link Combiner agent is written in Python. It receives messages from all of the Links (when they're in redundant mode: -redlink), and outputs messages to the Server and other ground segment agents. There is a bit involved however since the Server and GCS shouldn't be sent identical messages. I.e. if the aircraft sends a message and it's received successfully by more than one link, then that particular message should only sent by Link Combiner once. This is a somewhat tricky requirement since there is no guarantee that the message will be received by all of the links, and it's possible that the aircraft actually sends a second message that's exactly the same as the first. No extra info (such as a time-stamp or counter) is added to the messages sent from the aircraft to the ground, so the Link Combiner employs an algorithm to detect duplicate messages. Testing has shown that for typical links, this algorithm performs extremely well.<br />
<br />
The algorithm gives each link a circular buffer to store the last N messages. When a new message comes in on a particular link, the algorithm first checks if it's already in that link's buffer. If it is, then it's obviously a new message, so its removed from all of the other buffers if it's in any of them. Then, the message is sent to the other agents. If the message isn't already in the link's buffer, then it's added to the buffer. After that, all of the other link's buffers are checked for the message. If it's in any of them, then the message was already received by another link, so isn't sent. If it's not in any of them, then the message is sent. The following flowchart depicts this algorithm:<br />
<br />
http://1.bp.blogspot.com/-G1LYSsliAiY/UXNBjHj93PI/AAAAAAAAEaI/hom9cRmd3jI/s640/Algorithm+Diagram.png<br />
Caption: Algorithm to prevent duplicate messages<br />
<br />
====Algorithm Considerations====<br />
As the aircraft sends various messages, possibly with the exact same data, and the links gain and lose connection, there is no guarantee that this algorithm will do a perfect job of filtering out identical and only identical messages. However, in typical operation, it seems to work very well. And for the application of displaying aircraft data, the occasional missing or duplicate message is acceptable. There are only a few scenarios where the Link Combiner won't produce perfect results, and they should come up infrequently:<br />
<br />
* A message will be sent twice if the buffer size is too small to hold all of the messages received from one link between that link receiving the message and another link receiving the identical message. When the second link receives the message that has already been received, if the original isn't in the buffer anymore, than the algorithm won't know it's a duplicate message. This scenario should be considered whenever implementing a redundant link system. Partly because it is the most likely to come up, but also because if it does occur, then all messages will be duplicated. In order to avoid this scenario, you can set the buffer size as a command line argument of Link Combiner. To know what a good value would be, you can observer the Ping time and Rx messages/s of the links in the new Link page of the notebook. Calculate the minimum buffer size by taking the difference between the largest ping time and the smallest ping time and multiplying it by the largest Rx messages/s. Then apply a safety factor when setting the buffer size - 10 times the calculated value should be good.<br />
* A message won't be sent when it should be if the autopilot sends a message that's the same as one it already sent (same name and exact same values) AND one or more links were lost between the first message and the second AND the link that's receiving the second message doesn't have the first message in it's buffer still. That's three conditions. If this happens, then the Link Combiner will see the second message as a duplicate of the first and will skip it. Only this one message will be missed though - it won't start happening to all messages. Also, the data will have been data that was already received. So if it's for example the battery voltage message, then it's not a big deal to miss it. As long as there aren't links rapidly being lost and gained, then this shouldn't happen often. Note that as the buffer size is increased, it is believed that this becomes more likely to happen.<br />
<br />
== Ground to Aircraft ==<br />
<br />
This part of the redundant communication system hasn't been implemented yet. All information here is what it is envisioned to look like.<br />
<br />
===Features===<br />
* Enable multiple datalink links to be used for communicating with the autopilot.<br />
* Let different telemetry be sent out each link.<br />
* Let the choice of what telemetry is sent be moved from the settings page of the GCS to the Link page, since it can be different for each link.<br />
* Add a link status indicator (this is the light that turns red when the link is lost) for the datalink to the Link page. This will allow better monitoring of the links by not assuming that if one direction is good, the other direction is good as well.<br />
* Let each link be configured as telemetry only, datalink only, or by-directional.<br />
<br />
===Compatibility===<br />
Communication in the autopilot is enabled with the ground by including the telemetry subsystem in the airframe file. For example:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing or rotorcraft"><br />
...<br />
<subsystem name="telemetry" type="transparent"/><br />
</firmware><br />
</source><br />
}}<br />
<br />
In order to use multiple links, changes should be made to allow a telemetry subsystem for each link. Related to this, would it be advantageous to have multiple instances be supported for each different subsystem? Once the design for this is determined, would actual support for each subsystem have to be added one at a time? Because of the logic for how multiple subsystems should behave together is dependent on the subsystem, this might be the case. The telemetry subsystem for example should default to sending telemetry out each one and combining the telemetry received.<br />
<br />
===Hardware===<br />
Unlike aircraft to ground redundancy, ground to aircraft redundancy requires multiple UART ports in the hardware of the autopilot. The author is not particularly familiar with this, but believes that there are ways to get multiple UART ports for this purpose:<br />
* Telemetry can be sent out over USB by specifying the telemetry type to be "transparent_usb".<br />
* For the Lisa/M, the USB port can actually be used as a UART port with some hardware modifications.<br />
* Using an I2C GPS instead of a UART one can free up a UART port on most autopilots.<br />
* For the Lisa/M, can UART 1 and 5 be used if Spektrum Satellite receivers aren't used? If so, where are the Tx pins?<br />
<br />
In addition, future hardware designs could includes more UART ports for redundant communications or any other purpose.<br />
<br />
===Design===<br />
Unlike the aircraft to ground communication, for ground to aircraft communication it is not acceptable to have the same message be acted on twice. This could cause the aircraft to behave unexpectedly. In order to implement a 100% guaranteed link combiner for the aircraft, the author proposes a system that adds a counter to each message sent to the aircraft. This would allow the autopilot to easily ignore identical messages - they'll have the same value for the counter. Also, since minimal data is sent from the ground to the aircraft, adding the extra bytes to the payload will have a minimal impact on performance - this is not the case for the telemetry.<br />
<br />
The challenging part of this design will be integrating it properly into the existing systems.</div>Camleehttp://wiki.paparazziuav.org/w/index.php?title=Redundant_Communication&diff=14965Redundant Communication2013-04-28T04:38:27Z<p>Camlee: </p>
<hr />
<div>There is currently a pull request to integrate a redundant communication system into the existing ground segment agents: [https://github.com/paparazzi/paparazzi/pull/429 github.com/paparazzi/paparazzi/pull/429]. The goal of this project is to allow multiple radio modems or other links be used between the aircraft and the ground station in a redundant fashion so that even if one link is lost, communication can be maintained. So far, the aircraft to ground component has been created and tested in the lab. More comprehensive testing should be performed before the system is considered to be stable. The ground to aircraft component has not been created yet.<br />
<br />
===Reasons to use this===<br />
Communication from the aircraft to the ground is called telemetry. This communication allows the status of the aircraft such as location, altitude, airspeed, battery level, current flight block, and much more to be monitored in real time. Communication from the ground to the aircraft is called datalink. This communication allows commands to be sent to the aircraft from the ground. This includes telling the aircraft what navigation to perform: fly to a waypoint, start the search area, come in for a landing. If a single link is used, as was always the case before this project, then if the aircraft goes out of range, or that link is otherwise lost, no telemetry information can be displayed in the GCS and commands sent from the GCS won't be received by the aircraft. Using the following redundant link system allows multiple links to be used in an effort to avoid this. Typically, you would introduce diversity when adding links. For example:<br />
* If you have an on-board computer, you could tunnel messages through Wi-Fi over UDP in addition to a traditional 900 MHz XBee radio modem.<br />
* You could use a satellite modem for long-range monitoring in addition to a radio modem.<br />
* You could use a cellular modem in addition to a radio modem.<br />
* With additional ground infrastructure, you could have radio modems located at different locations.<br />
* You could use radio modems at different frequencies or with different antenna gains or orientations.<br />
* You could use this system to evaluate different types of radio modems or antenna placements - you'll get real time info on each such as the ping time, received messages rate, and more information could easily be added.<br />
<br />
There are undoubtedly many more possibilities.<br />
<br />
===Compatibility===<br />
This project was made to be fully backwards compatible and support the awesome functionality that Paparazzi already has. This includes:<br />
* Completely backwards compatible - includes aircraft configuration files, previous flight logs, existing sessions, etc...<br />
* Logging and replay - if multiple links are used, data received through either link is recorded. Also, replays will include the status of each link as it was during the flight.<br />
* Link features such as USB-serial, audio, UDP, different transport layers, etc...<br />
* Multi-aircraft sessions - also, you can use redundant links for one aircraft, but not for another if desired.<br />
* Multiple aircraft connected to the same link - such as might come up in a mesh configuration where one aircraft relays data from another aircraft.<br />
<br />
== Aircraft to Ground ==<br />
<br />
===Features===<br />
Enabling redundant communication from the aircraft to the ground enables the following features:<br />
* Redundancy - as long as one link is receiving data, it will be logged and displayed on the GCS.<br />
* Monitoring - the status, ping time, and rate of receiving messages for each link is shown (this makes it useful even if you're only using one link).<br />
* Alerts - new alerts are added to the console in the GCS to alert you when a link has been connected for the first time, lost, or re-gained.<br />
<br />
===Future Improvements===<br />
Several different improvements can be made to this system to improve it's performance and help satisfy future needs that may arise:<br />
* Additional information can easily be added to the Link page of the GCS for each link. For example: errors, % uptime, or a scrolling graph of Rx messages/s.<br />
* The ability to mark different links as either critical or backup. The idea here is that not all links should necessarily be treated equal. Maybe only one link is able to send datalink data to the aircraft (actually, this is the case right now) and so that link should be considered critical. If any other link is lost, then the overall telemetry can be counted as OK. But if the critical link is lost, then the GCS should change the link indicator light to red and start counting up even if the other link(s) are OK.<br />
* The Link Combiner algorithm currently employs a simple circular buffer. This could be improved on by adding a time-stamp to each element of the buffer and only counting two buffer elements to be the same if their timestamps are close enough (say within 2 seconds - this could be configured)<br />
* The Link Combiner algorithm could be improved by making the buffer size adjust automatically with the ping time and Rx messages/s rate. Or if the timestamp improvement is implemented, then the maximum time difference could be adjusted.<br />
* A performance and resource use analysis could be done to optimize the Link Combiner. The circular buffer is currently implemented using Python lists which could probably be improved upon. Also, significantly more ivy messages are sent and received. This might make optimizations to the regex or other parts of the ivybus worthwhile.<br />
<br />
===How to use===<br />
<br />
For an example using two USB-serial adaptors, see the '''Flight USB-serial Redundant''' session saved in the example control_panel.xml configuration (on master branch, once the pull request has been accepted).<br />
<br />
For the details, keep reading:<br />
In order to implement redundant links using this code, there are three simple steps to follow:<br />
<br />
* Connect the hardware - on the airborne side, connect the Rx pin of the autopilot's UART port to multiple radio modems or whatever other device which will get the information to the ground. On the ground side, connect multiple modems as normal (using USB to serial adapters, a UDP connection, or whatever). (note: Once the ground to aircraft redundancy has been implemented, you won't have to split the Rx signal and can just plug each modem into a UART port)<br />
* Launch a Link agent for each modem (in Paparazzi Center, select it from the tools menu). Configure the agents as you would have before (serial port, baud rate, UDP, etc...). None of these features have been modified or removed. Then, use two new command line arguments: -redlink and -id. The -redlink flag tells Link that it's one of multiple links. The -id flag lets you specify an integer number as the id of that particular link.<br />
* Launch the Link Combiner agent (again, from the tools menu). This agent listens to all of the Link agents that have their -redlink set and combines the data.<br />
<br />
The following screenshot shows a session with two links, connected to serial ports ttyUSB0 and ttyUSB1, and with id's 1 and 2:<br />
<br />
http://2.bp.blogspot.com/-4ytdpqXMHa0/UXMlR-qGkbI/AAAAAAAAEZw/JO959QjWip4/s640/Screenshot+from+2013-04-15+23_02_27.png<br />
Caption: The Agents Running in a Redundant Link Setup<br />
<br />
* Test the system and make sure that it works correctly under all circumstances. Do this before flying. In particular, make sure that the buffer size if appropriate. Take a look at the [[#Algorithm Considerations|Algorithm Considerations]] section for details.<br />
<br />
===Interface===<br />
Once the redundant link system is started (even if only one Link is used), several changes appear in the GCS. This is achieved by the new message LINK_STATUS which is sent by the Link Combiner. These new features are designed to allow closer monitoring and better management of the link(s) between the aircraft and the ground station.<br />
<br />
The following screenshot clearly shows these changes:<br />
http://3.bp.blogspot.com/-jI7EMZ_0614/UXMjlc1MoBI/AAAAAAAAEZo/LwOgVQN336o/s640/Screenshot+from+2013-04-15+22_59_01.png<br />
<br />
Firstly, we can see that there is a new page in the notebook named Link. This page contains critical information for each link. More information can easily be added, but for now, it shows the status of the link (just like the main Link status indicator in the strip), the current ping time, and the rate of received messages. So if one link is lost, it's status indicator will turn red and start counting up just like link 2 in the above screenshot.<br />
<br />
Next, we can see that the main Link status indicator that's located in the strip has been modified slightly. It now shows the ratio of connected links to the total number of links. I.e. 3/4 means that there are four links and one of them has been lost. Furthermore, the indicator will be green if all links are connected, yellow if one or more are lost, and red if all links are lost. Once all links are lost, the indicator will count up just like before.<br />
<br />
Lastly, alerts have been added to the console. Whenever a link is lost or reconnected, a message will appear in the console stating so. Messages also appear when a new link is added.<br />
<br />
===Design===<br />
====Implementation====<br />
Here's a block diagram showing how the aircraft talks to the various ground segment programs (also known as agents) when not using the redundant link system:<br />
<br />
http://3.bp.blogspot.com/-8-YENO6LcNs/UXMRpkJlx1I/AAAAAAAAEZQ/Z3XDrJCRzQs/s400/Normal+Communication+Layout.png<br />
Caption: Paparazzi Ground Segment<br />
<br />
The ivy bus lets the programs talk to each other through the use of short messages. Pay close attention to the coloured arrows, which show the main flow of these messages. Next we have a block diagram of the redundant link system:<br />
<br />
http://4.bp.blogspot.com/-nx_p90B7FU4/UXMddbJ_gEI/AAAAAAAAEZg/qnbrS-bS3l0/s640/Redundant+Communication+Layout.png<br />
Caption: Paparazzi Ground Segment with Redundant Links<br />
<br />
Here we can see the new agent, the Link Combiner. We also see multiple occurrences of the Link agent. When operating in redundant mode, each occurrence of Link transmits the data it receives from the aircraft to the Link Combiner instead of the Server. It does this by transmitting the received telemetry messages within the TELEMETRY_MESSAGE message which the Server doesn't listen to. The Link Combiner on the other hand does. TELEMETRY_MESSAGE messages are sent by each link and include the id of that link. The Link Combiner listens to all of them and then transmits a single set of messages to the Server with the combined data. This results in the Server and all other ground segment agents (such as Messages and the Real Time Plotter) getting their telemetry data from Link Combiner as if it was coming from a single occurrence of Link.<br />
<br />
====Link Combiner====<br />
The Link Combiner agent is written in Python. It receives messages from all of the Links (when they're in redundant mode: -redlink), and outputs messages to the Server and other ground segment agents. There is a bit involved however since the Server and GCS shouldn't be sent identical messages. I.e. if the aircraft sends a message and it's received successfully by more than one link, then that particular message should only sent by Link Combiner once. This is a somewhat tricky requirement since there is no guarantee that the message will be received by all of the links, and it's possible that the aircraft actually sends a second message that's exactly the same as the first. No extra info (such as a time-stamp or counter) is added to the messages sent from the aircraft to the ground, so the Link Combiner employs an algorithm to detect duplicate messages. Testing has shown that for typical links, this algorithm performs extremely well.<br />
<br />
The algorithm gives each link a circular buffer to store the last N messages. When a new message comes in on a particular link, the algorithm first checks if it's already in that link's buffer. If it is, then it's obviously a new message, so its removed from all of the other buffers if it's in any of them. Then, the message is sent to the other agents. If the message isn't already in the link's buffer, then it's added to the buffer. After that, all of the other link's buffers are checked for the message. If it's in any of them, then the message was already received by another link, so isn't sent. If it's not in any of them, then the message is sent. The following flowchart depicts this algorithm:<br />
<br />
http://1.bp.blogspot.com/-G1LYSsliAiY/UXNBjHj93PI/AAAAAAAAEaI/hom9cRmd3jI/s640/Algorithm+Diagram.png<br />
Caption: Algorithm to prevent duplicate messages<br />
<br />
====Algorithm Considerations====<br />
As the aircraft sends various messages, possibly with the exact same data, and the links gain and lose connection, there is no guarantee that this algorithm will do a perfect job of filtering out identical and only identical messages. However, in typical operation, it seems to work very well. And for the application of displaying aircraft data, the occasional missing or duplicate message is acceptable. There are only a few scenarios where the Link Combiner won't produce perfect results, and they should come up infrequently:<br />
<br />
* A message will be sent twice if the buffer size is too small to hold all of the messages received from one link between that link receiving the message and another link receiving the identical message. When the second link receives the message that has already been received, if the original isn't in the buffer anymore, than the algorithm won't know it's a duplicate message. This scenario should be considered whenever implementing a redundant link system. Partly because it is the most likely to come up, but also because if it does occur, then all messages will be duplicated. In order to avoid this scenario, you can set the buffer size as a command line argument of Link Combiner. To know what a good value would be, you can observer the Ping time and Rx messages/s of the links in the new Link page of the notebook. Calculate the minimum buffer size by taking the difference between the largest ping time and the smallest ping time and multiplying it by the largest Rx messages/s. Then apply a safety factor when setting the buffer size - 10 times the calculated value should be good.<br />
* A message won't be sent when it should be if the autopilot sends a message that's the same as one it already sent (same name and exact same values) AND one or more links were lost between the first message and the second AND the link that's receiving the second message doesn't have the first message in it's buffer still. That's three conditions. If this happens, then the Link Combiner will see the second message as a duplicate of the first and will skip it. Only this one message will be missed though - it won't start happening to all messages. Also, the data will have been data that was already received. So if it's for example the battery voltage message, then it's not a big deal to miss it. As long as there aren't links rapidly being lost and gained, then this shouldn't happen often. Note that as the buffer size is increased, it is believed that this becomes more likely to happen.<br />
<br />
== Ground to Aircraft ==<br />
<br />
This part of the redundant communication system hasn't been implemented yet. All information here is what it is envisioned to look like.<br />
<br />
===Features===<br />
* Enable multiple datalink links to be used for communicating with the autopilot.<br />
* Let different telemetry be sent out each link.<br />
* Let the choice of what telemetry is sent be moved from the settings page of the GCS to the Link page, since it can be different for each link.<br />
* Add a link status indicator (this is the light that turns red when the link is lost) for the datalink to the Link page. This will allow better monitoring of the links by not assuming that if one direction is good, the other direction is good as well.<br />
* Let each link be configured as telemetry only, datalink only, or by-directional.<br />
<br />
===Compatibility===<br />
Communication in the autopilot is enabled with the ground by including the telemetry subsystem in the airframe file. For example:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing or rotorcraft"><br />
...<br />
<subsystem name="telemetry" type="transparent"/><br />
</firmware><br />
</source><br />
}}<br />
<br />
In order to use multiple links, changes should be made to allow a telemetry subsystem for each link. Related to this, would it be advantageous to have multiple instances be supported for each different subsystem? Once the design for this is determined, would actual support for each subsystem have to be added one at a time? Because of the logic for how multiple subsystems should behave together is dependent on the subsystem, this might be the case. The telemetry subsystem for example should default to sending telemetry out each one and combining the telemetry received.<br />
<br />
===Hardware===<br />
Unlike aircraft to ground redundancy, ground to aircraft redundancy requires multiple UART ports in the hardware of the autopilot. The author is not particularly familiar with this, but believes that there are ways to get multiple UART ports for this purpose:<br />
* Telemetry can be sent out over USB by specifying the telemetry type to be "transparent_usb".<br />
* For the Lisa/M, the USB port can actually be used as a UART port with some hardware modifications.<br />
* Using an I2C GPS instead of a UART one can free up a UART port on most autopilots.<br />
* For the Lisa/M, can UART 1 and 5 be used if Spektrum Satellite receivers aren't used? If so, where are the Tx pins?<br />
<br />
In addition, future hardware designs could includes more UART ports for redundant communications or any other purpose.<br />
<br />
===Design===<br />
Unlike the aircraft to ground communication, for ground to aircraft communication it is not acceptable to have the same message be acted on twice. This could cause the aircraft to behave unexpectedly. In order to implement a 100% guaranteed link combiner for the aircraft, the author proposes a system that adds a counter to each message sent to the aircraft. This would allow the autopilot to easily ignore identical messages - they'll have the same value for the counter. Also, since minimal data is sent from the ground to the aircraft, adding the extra bytes to the payload will have a minimal impact on performance - this is not the case for the telemetry.<br />
<br />
The challenging part of this design will be integrating it properly into the existing systems.</div>Camleehttp://wiki.paparazziuav.org/w/index.php?title=Redundant_Communication&diff=14964Redundant Communication2013-04-28T03:15:10Z<p>Camlee: </p>
<hr />
<div>There is currently a pull request to integrate a redundant communication system into the existing ground segment agents: [https://github.com/paparazzi/paparazzi/pull/429 github.com/paparazzi/paparazzi/pull/429]. The goal of this project is to allow multiple radio modems or other links be used between the aircraft and the ground station in a redundant fashion so that even if one link is lost, communication can be maintained. So far, the aircraft to ground component has been created and tested in the lab. More comprehensive testing should be performed before the system is considered to be stable. The ground to aircraft component has not been created yet.<br />
<br />
===Reasons to use this===<br />
Communication from the aircraft to the ground is called telemetry. This communication allows the status of the aircraft such as location, altitude, airspeed, battery level, current flight block, and much more to be monitored in real time. Communication from the ground to the aircraft is called datalink. This communication allows the commands to be sent to the aircraft from the ground. This includes telling the aircraft what navigation to perform: waypoint navigation, search area, landing. If a single link is used, as is typical, then if the aircraft goes out of range, or that link is otherwise lost, no telemetry information can be displayed in the GCS and commands sent from the GCS won't be sent to the aircraft. Using the following redundant link system allows multiple links to be used in an effort to avoid this. Typically, you would introduce diversity when adding links. For example:<br />
* If you have an on-board computer, you could tunnel messages through Wi-Fi over UDP in addition to a traditional 900 MHz XBee radio modem.<br />
* You could use a satellite modem for long-range monitoring in addition to a radio modem.<br />
* You could use a cellular modem in addition to a radio modem.<br />
* With additional ground infrastructure, you could have radio modems located at different locations.<br />
* You could use radio modems at different frequencies or with different antenna gains or orientations.<br />
* You could use this system to evaluate different types of radio modems or antenna placements - you'll get real time info on each such as the ping time, received messages rate, and more information can easily be added.<br />
<br />
There are undoubtedly many more possibilities.<br />
<br />
===Compatibility===<br />
This project was made to be fully backwards compatible and support the awesome functionality that Paparazzi already has. This includes:<br />
* Completely backwards compatible - includes aircraft configuration files, previous flight logs, existing sessions, etc...<br />
* Logging and replay - if multiple links are used, data received through either link is recorded. Also, replays will include the status of each link as it was during the flight.<br />
* Link features such as USB-serial, audio, UDP, different transport layers, etc...<br />
* Multi-aircraft sessions - you can use redundant links for one aircraft, but not for another if desired<br />
* Multiple aircraft connected to the same link - such as might come up in a mesh configuration where one aircraft relays data from another aircraft<br />
<br />
<br />
== Aircraft to Ground ==<br />
<br />
===Features===<br />
Enabling redundant communication from the aircraft to the ground enables the following features:<br />
* Redundancy - as long as one link is receiving data, it will be logged and displayed on the GCS<br />
* Monitoring - the status, ping time, and rate of receiving messages for each link is shown (this makes it useful even if you're only using one link)<br />
* Alerts - new alerts are added to the console in the GCS to alert you when a link has been connected for the first time, lost, or re-gained.<br />
<br />
===Future Improvements===<br />
Several different improvements can be made to this system to improve it's performance and help satisfy everybody's needs:<br />
* Additional information can easily be added to the Link page of the GCS for each link. For example: errors, % uptime, or a scrolling graph of Rx messages/s<br />
* The ability to mark different links as either critical or backup. The idea here is that not all links should necessarily be treated equal. Maybe only one link is able to send datalink data to the aircraft (actually, this is the case right now) and so that link should be considered critical. If any other link is lost, then the overall telemetry can be counted as OK. But if the critical link is lost, then the GCS should change the link indicator light to red and start counting up even if the other link(s) are OK.<br />
* The Link Combiner algorithm currently employs a simple circular buffer. This could be improved on by adding a time-stamp to each element of the buffer and only counting two buffer elements to be the same if their timestamps are close enough.<br />
* The Link Combiner algorithm could be improved by making the buffer size adjust automatically with the ping time and Rx messages/s rate.<br />
* A performance and resource use analysis could be done to optimize the Link Combiner. The circular buffer is currently implemented using Python lists which could probably be improved upon. Also, significantly more ivy messages are sent and received. This might make optimizations to the regex or other parts of the ivybus worthwhile.<br />
<br />
===How to use===<br />
<br />
For an example using two USB-serial adaptors, see the Flight USB-serial Redundant session saved in the example control_panel.xml configuration (on master branch, once the pull request has been accepted).<br />
<br />
For the details, keep reading:<br />
In order to implement redundant links using this code, there are three simple steps to follow:<br />
<br />
* Connect the hardware - on the airborne side, connect the Rx pin of the autopilot to multiple radio modems or whatever other device which will get the information to the ground. On the ground side, connect multiple modems as normal (using USB to serial adapters, a UDP connection, or whatever).<br />
* Launch a Link agent for each modem. Configure the agents as you would have before (serial port, baud rate, UDP, etc...). None of these features have been modified or removed. Then, use two new command line arguments: -redlink and -id. The -redlink flag tells Link that it's one of multiple links. The -id flag lets you specify an integer number as the id of that particular link.<br />
* Launch the Link Combiner agent. This agent listens to all of the Link agents that have their -redlink set and combines the data.<br />
<br />
The following screenshot shows a session with two links, connected to serial ports ttyUSB0 and ttyUSB1, and with id's 1 and 2:<br />
<br />
http://3.bp.blogspot.com/-jI7EMZ_0614/UXMjlc1MoBI/AAAAAAAAEZo/LwOgVQN336o/s640/Screenshot+from+2013-04-15+22_59_01.png<br />
Caption: The Agents Running in a Redundant Link Setup<br />
<br />
* Test the system and make sure that it works correctly under all circumstances. Do this before flying. In particular, take a look at the [[#Algorithm Considerations|Algorithm Considerations]] section to ensure that the correct buffer size of chosen.<br />
<br />
===Interface===<br />
Once the redundant link system is started (even if only one Link is used), several changes appear in the GCS. This is achieved by the new message LINK_STATUS which is sent by the Link Combiner. These new features are designed to allow closer monitoring and better management of the link(s) between the aircraft and the ground station. <br />
<br />
The following screenshot clearly shows these changes:<br />
http://3.bp.blogspot.com/-jI7EMZ_0614/UXMjlc1MoBI/AAAAAAAAEZo/LwOgVQN336o/s640/Screenshot+from+2013-04-15+22_59_01.png<br />
<br />
Firstly, we can see that there is a new page in the notebook named Link. This page contains critical information for each link. More information can easily be added, but for now, it shows the status of the link (just like the main Link status indicator in the strip), the current ping time, and the rate of received messages. So if one link is lost, it's status indicator will turn red and start counting up just like link 2 in the above screenshot.<br />
<br />
Next, we can see that the main Link status indicator that's located in the strip has been modified slightly. It now shows the ratio of connected links to the total number of links. I.e. 3/4 means that there are four links and one of them has been lost. Furthermore, the indicator will be green if all links are connected, yellow if one or more are lost, and red if all links are lost. Once all links are lost, the indicator will count up just like before.<br />
<br />
Lastly, alerts have been added to the console. Whenever a link is lost or reconnected, a message will appear in the console stating so. Messages also appear when a new link is added.<br />
<br />
===Design===<br />
====Implementation====<br />
Here's a block diagram showing how the aircraft talks to the various ground segment programs (also known as agents) when not using the redundant link system:<br />
<br />
http://3.bp.blogspot.com/-8-YENO6LcNs/UXMRpkJlx1I/AAAAAAAAEZQ/Z3XDrJCRzQs/s400/Normal+Communication+Layout.png<br />
Caption: Paparazzi Ground Segment<br />
<br />
The ivy bus lets the programs talk to each other through the use of short messages. Pay close attention to the coloured arrows, which show the main flow of these messages. Next we have a block diagram of the redundant link system:<br />
<br />
http://4.bp.blogspot.com/-nx_p90B7FU4/UXMddbJ_gEI/AAAAAAAAEZg/qnbrS-bS3l0/s640/Redundant+Communication+Layout.png<br />
Caption: Paparazzi Ground Segment with Redundant Links<br />
<br />
Here we can see a new agent, the Link Combiner. We also see multiple occurrences of the Link agent. When operating in redundant mode, each occurrence of Link transmits the data it receives from the aircraft to the Link Combiner instead of the Server. It does this by transmitting the received telemetry messages within the TELEMETRY_MESSAGE message which the Server doesn't listen to. The Link Combiner on the other hand does. TELEMETRY_MESSAGE messages are sent by each link and include the id of that link. The Link Combiner listens to all of them and then transmits a single set of messages to the Server with the combined data. This results in the Server and all other ground segment agents (such as Messages and the Real Time Plotter) getting their telemetry data from Link Combiner as if it was coming from a single occurrence of Link.<br />
<br />
====Link Combiner====<br />
The Link Combiner agent is written in Python. It receives messages from all of the Links (when they're in redundant mode), and outputs messages to the Server and other ground segment agents. There is a bit involved however since the Server and GCS shouldn't be sent identical messages. I.e. if the aircraft sends a message and it's received successfully by more than one link, then that particular message should only sent by Link Combiner once. This is a somewhat tricky requirement since there is no guarantee that the message will be received by all of the links, and it's possible that the aircraft actually sends a second message that's exactly the same as the first. No extra info (such as a time-stamp or counter) is added to the messages sent from the aircraft to the ground, so the Link Combiner employs an algorithm to detect duplicate messages. Testing has shown that for typical links, this algorithm performs extremely well.<br />
<br />
The algorithm gives each link a circular buffer to store the last N messages. When a new message comes in on a particular link, the algorithm first checks if it's already in that link's buffer. If it is, then it's obviously a new message, so its removed from all of the other buffers if it's in any of them. Then, the message is sent. If the message isn't already in the link's buffer, then it's added to the buffer. After that, all of the other link's buffers are checked for the message. If it's in any of them, then the message was already received by another link, so isn't sent. If it's not in any of them, then the message is sent. The following flowchart depicts this algorithm:<br />
<br />
http://1.bp.blogspot.com/-G1LYSsliAiY/UXNBjHj93PI/AAAAAAAAEaI/hom9cRmd3jI/s640/Algorithm+Diagram.png<br />
Caption: Algorithm to prevent duplicate messages<br />
<br />
====Algorithm Considerations====<br />
As the aircraft sends various, possibly identical, messages and the links gain and lose connection, there is no guarantee that this algorithm will do a perfect job of filtering out identical and only identical messages. However, in typical operation, it seems to work very well. And for the application of displaying aircraft data, the occasional missing or duplicate message is acceptable. There are only a few scenarios where the Link Combiner won't produce perfect results, and they should come up infrequently:<br />
<br />
* A message will be sent twice if the buffer size is too small to hold all of the messages received from one link between that link receiving the message and another link receiving the identical message. When the second link receives the message that has already been received, if the original isn't in the buffer anymore, than the algorithm won't know it's a duplicate message. This scenario should be considered whenever implementing a redundant link system. Partly because it is the most likely to come up, but also because if it does occur, then all messages will be duplicated. In order to avoid this scenario, you can set the buffer size as a command line argument of Link Combiner. To know what a good value would be, you can observer the Ping time and Rx messages/s of the links in the new Link page of the notebook. Calculate the minimum buffer size by taking the difference between the largest ping time and the smallest ping time and multiplying it by the largest Rx messages/s. Then apply a safety factor when setting the buffer size - 10 times the calculated value should be good.<br />
* A message won't be sent when it should be if the autopilot sends a message that's the same as one it already sent (same name and exact same values) AND at least one link was lost between the first message and the second AND the link that's receiving the second message doesn't have the first message in it's buffer still. That's three conditions. If this happens, then the Link Combiner will see the second message as a duplicate of the first and will skip it. Only this one message will be missed though - it won't start happening to all messages. Also, the data will have been data that was already received. So if it's for example the battery voltage message, then it's not a big deal to miss it. As long as there aren't links rapidly being lost and gained, then this shouldn't happen often. Note that as the buffer size is increased, it is believed that this becomes more likely to happen.<br />
<br />
== Ground to Aircraft ==<br />
<br />
This part of the redundant communication system hasn't been implemented yet. All information here is what it is envisioned to look like.<br />
<br />
===Features===<br />
* Enable multiple datalink links to be used for communicating with the autopilot.<br />
* Let different telemetry be sent out each link.<br />
* Let the choice of what telemetry is sent be moved from the settings page of the GCS to the Link page, since it can be different for each link.<br />
* Add a link status indicator (this is the light that turns red when the link is lost) for the datalink to the Link page. This will allow better monitoring of the links by not assuming that if one direction is good, the other direction is good as well.<br />
* Let each link be configured as telemetry only, datalink only, or by-directional.<br />
<br />
===Compatibility===<br />
Communication in the autopilot is enabled with the ground by including the telemetry subsystem in the airframe file. For example:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing or rotorcraft"><br />
...<br />
<subsystem name="telemetry" type="transparent"/><br />
</firmware><br />
</source><br />
}}<br />
<br />
In order to use multiple links, changes should be made to allow a telemetry subsystem for each link. Related to this, would it be advantageous to have multiple instances be supported for each different subsystem? Once the design for this is determined, would actual support for each subsystem have to be added one at a time? Because of the logic for how multiple subsystems should behave together is dependent on the subsystem, this might be the case. The telemetry subsystem for example should default to sending telemetry out each one and combining the telemetry received.<br />
<br />
===Hardware===<br />
Unlike aircraft to ground redundancy, ground to aircraft redundancy requires multiple UART ports in the hardware of the autopilot. The author is not that familiar with this, but believes that there are ways to get multiple UART ports for this purpose:<br />
* Telemetry can be sent out over USB by specifying the telemetry type to be "transparent_usb".<br />
* For the Lisa/M, the USB port can actually be used as a UART port with some hardware modifications.<br />
* Using an I2C GPS instead of a UART one can free up a UART port on most autopilots<br />
* For the Lisa/M, can UART 1 and 5 be used if Spektrum Satellite receivers aren't used? If so, where are the Tx pins?<br />
<br />
In addition, future hardware designs could includes more UART ports for redundant communications or any other purpose.<br />
<br />
===Design===<br />
Unlike the aircraft to ground communication, for ground to aircraft communication it is not acceptable to have the same message be acted on twice. This could cause the aircraft to behave unexpectedly. In order to implement a 100% guaranteed link combiner for the aircraft, the author proposes a system that adds a counter to each message sent to the aircraft. This would allow the autopilot to easily ignore identical messages - they'll have the same value for counter. Also, since minimal data is sent from the ground to the aircraft, adding the extra bytes to the payload will have a minimal impact on performance - this is not the case for the telemetry.<br />
<br />
The challenging part of this design will be integrating it properly into the existing systems.</div>Camleehttp://wiki.paparazziuav.org/w/index.php?title=Redundant_Communication&diff=14963Redundant Communication2013-04-28T03:12:32Z<p>Camlee: </p>
<hr />
<div>There is currently a pull request to integrate a redundant communication system into the existing ground segment agents: [https://github.com/paparazzi/paparazzi/pull/429 github.com/paparazzi/paparazzi/pull/429]. The goal of this project is to allow multiple radio modems or other links be used between the aircraft and the ground station in a redundant fashion so that even if one link is lost, communication can be maintained. So far, the plane to ground component has been created and tested in the lab. More comprehensive testing should be performed before the system is considered to be stable. The ground to plane component has not been created yet.<br />
<br />
===Reasons to use this===<br />
Communication from the aircraft to the ground is called telemetry. This communication allows the status of the aircraft such as location, altitude, airspeed, battery level, current flight block, and much more to be monitored in real time. Communication from the ground to the aircraft is called datalink. This communication allows the commands to be sent to the aircraft from the ground. This includes telling the aircraft what navigation to perform: waypoint navigation, search area, landing. If a single link is used, as is typical, then if the plane goes out of range, or that link is otherwise lost, no telemetry information can be displayed in the GCS and commands sent from the GCS won't be sent to the aircraft. Using the following redundant link system allows multiple links to be used in an effort to avoid this. Typically, you would introduce diversity when adding links. For example:<br />
* If you have an on-board computer, you could tunnel messages through Wi-Fi over UDP in addition to a traditional 900 MHz XBee radio modem.<br />
* You could use a satellite modem for long-range monitoring in addition to a radio modem.<br />
* You could use a cellular modem in addition to a radio modem.<br />
* With additional ground infrastructure, you could have radio modems located at different locations.<br />
* You could use radio modems at different frequencies or with different antenna gains or orientations.<br />
* You could use this system to evaluate different types of radio modems or antenna placements - you'll get real time info on each such as the ping time, received messages rate, and more information can easily be added.<br />
<br />
There are undoubtedly many more possibilities.<br />
<br />
===Compatibility===<br />
This project was made to be fully backwards compatible and support the awesome functionality that Paparazzi already has. This includes:<br />
* Completely backwards compatible - includes aircraft configuration files, previous flight logs, existing sessions, etc...<br />
* Logging and replay - if multiple links are used, data received through either link is recorded. Also, replays will include the status of each link as it was during the flight.<br />
* Link features such as USB-serial, audio, UDP, different transport layers, etc...<br />
* Multi-aircraft sessions - you can use redundant links for one aircraft, but not for another if desired<br />
* Multiple aircraft connected to the same link - such as might come up in a mesh configuration where one aircraft relays data from another aircraft<br />
<br />
<br />
== Aircraft to Ground ==<br />
<br />
===Features===<br />
Enabling redundant communication from the aircraft to the ground enables the following features:<br />
* Redundancy - as long as one link is receiving data, it will be logged and displayed on the GCS<br />
* Monitoring - the status, ping time, and rate of receiving messages for each link is shown (this makes it useful even if you're only using one link)<br />
* Alerts - new alerts are added to the console in the GCS to alert you when a link has been connected for the first time, lost, or re-gained.<br />
<br />
===Future Improvements===<br />
Several different improvements can be made to this system to improve it's performance and help satisfy everybody's needs:<br />
* Additional information can easily be added to the Link page of the GCS for each link. For example: errors, % uptime, or a scrolling graph of Rx messages/s<br />
* The ability to mark different links as either critical or backup. The idea here is that not all links should necessarily be treated equal. Maybe only one link is able to send datalink data to the plane (actually, this is the case right now) and so that link should be considered critical. If any other link is lost, then the overall telemetry can be counted as OK. But if the critical link is lost, then the GCS should change the link indicator light to red and start counting up even if the other link(s) are OK.<br />
* The Link Combiner algorithm currently employs a simple circular buffer. This could be improved on by adding a time-stamp to each element of the buffer and only counting two buffer elements to be the same if their timestamps are close enough.<br />
* The Link Combiner algorithm could be improved by making the buffer size adjust automatically with the ping time and Rx messages/s rate.<br />
* A performance and resource use analysis could be done to optimize the Link Combiner. The circular buffer is currently implemented using Python lists which could probably be improved upon. Also, significantly more ivy messages are sent and received. This might make optimizations to the regex or other parts of the ivybus worthwhile.<br />
<br />
===How to use===<br />
<br />
For an example using two USB-serial adaptors, see the Flight USB-serial Redundant session saved in the example control_panel.xml configuration (on master branch, once the pull request has been accepted).<br />
<br />
For the details, keep reading:<br />
In order to implement redundant links using this code, there are three simple steps to follow:<br />
<br />
* Connect the hardware - on the airborne side, connect the Rx pin of the autopilot to multiple radio modems or whatever other device which will get the information to the ground. On the ground side, connect multiple modems as normal (using USB to serial adapters, a UDP connection, or whatever).<br />
* Launch a Link agent for each modem. Configure the agents as you would have before (serial port, baud rate, UDP, etc...). None of these features have been modified or removed. Then, use two new command line arguments: -redlink and -id. The -redlink flag tells Link that it's one of multiple links. The -id flag lets you specify an integer number as the id of that particular link.<br />
* Launch the Link Combiner agent. This agent listens to all of the Link agents that have their -redlink set and combines the data.<br />
<br />
The following screenshot shows a session with two links, connected to serial ports ttyUSB0 and ttyUSB1, and with id's 1 and 2:<br />
<br />
http://3.bp.blogspot.com/-jI7EMZ_0614/UXMjlc1MoBI/AAAAAAAAEZo/LwOgVQN336o/s640/Screenshot+from+2013-04-15+22_59_01.png<br />
Caption: The Agents Running in a Redundant Link Setup<br />
<br />
* Test the system and make sure that it works correctly under all circumstances. Do this before flying. In particular, take a look at the [[#Algorithm Considerations|Algorithm Considerations]] section to ensure that the correct buffer size of chosen.<br />
<br />
===Interface===<br />
Once the redundant link system is started (even if only one Link is used), several changes appear in the GCS. This is achieved by the new message LINK_STATUS which is sent by the Link Combiner. These new features are designed to allow closer monitoring and better management of the link(s) between the aircraft and the ground station. <br />
<br />
The following screenshot clearly shows these changes:<br />
http://3.bp.blogspot.com/-jI7EMZ_0614/UXMjlc1MoBI/AAAAAAAAEZo/LwOgVQN336o/s640/Screenshot+from+2013-04-15+22_59_01.png<br />
<br />
Firstly, we can see that there is a new page in the notebook named Link. This page contains critical information for each link. More information can easily be added, but for now, it shows the status of the link (just like the main Link status indicator in the strip), the current ping time, and the rate of received messages. So if one link is lost, it's status indicator will turn red and start counting up just like link 2 in the above screenshot.<br />
<br />
Next, we can see that the main Link status indicator that's located in the strip has been modified slightly. It now shows the ratio of connected links to the total number of links. I.e. 3/4 means that there are four links and one of them has been lost. Furthermore, the indicator will be green if all links are connected, yellow if one or more are lost, and red if all links are lost. Once all links are lost, the indicator will count up just like before.<br />
<br />
Lastly, alerts have been added to the console. Whenever a link is lost or reconnected, a message will appear in the console stating so. Messages also appear when a new link is added.<br />
<br />
===Design===<br />
====Implementation====<br />
Here's a block diagram showing how the plane talks to the various ground segment programs (also known as agents) when not using the redundant link system:<br />
<br />
http://3.bp.blogspot.com/-8-YENO6LcNs/UXMRpkJlx1I/AAAAAAAAEZQ/Z3XDrJCRzQs/s400/Normal+Communication+Layout.png<br />
Caption: Paparazzi Ground Segment<br />
<br />
The ivy bus lets the programs talk to each other through the use of short messages. Pay close attention to the coloured arrows, which show the main flow of these messages. Next we have a block diagram of the redundant link system:<br />
<br />
http://4.bp.blogspot.com/-nx_p90B7FU4/UXMddbJ_gEI/AAAAAAAAEZg/qnbrS-bS3l0/s640/Redundant+Communication+Layout.png<br />
Caption: Paparazzi Ground Segment with Redundant Links<br />
<br />
Here we can see a new agent, the Link Combiner. We also see multiple occurrences of the Link agent. When operating in redundant mode, each occurrence of Link transmits the data it receives from the plane to the Link Combiner instead of the Server. It does this by transmitting the received telemetry messages within the TELEMETRY_MESSAGE message which the Server doesn't listen to. The Link Combiner on the other hand does. TELEMETRY_MESSAGE messages are sent by each link and include the id of that link. The Link Combiner listens to all of them and then transmits a single set of messages to the Server with the combined data. This results in the Server and all other ground segment agents (such as Messages and the Real Time Plotter) getting their telemetry data from Link Combiner as if it was coming from a single occurrence of Link.<br />
<br />
====Link Combiner====<br />
The Link Combiner agent is written in Python. It receives messages from all of the Links (when they're in redundant mode), and outputs messages to the Server and other ground segment agents. There is a bit involved however since the Server and GCS shouldn't be sent identical messages. I.e. if the plane sends a message and it's received successfully by more than one link, then that particular message should only sent by Link Combiner once. This is a somewhat tricky requirement since there is no guarantee that the message will be received by all of the links, and it's possible that the plane actually sends a second message that's exactly the same as the first. No extra info (such as a time-stamp or counter) is added to the messages sent from the plane to the ground, so the Link Combiner employs an algorithm to detect duplicate messages. Testing has shown that for typical links, this algorithm performs extremely well.<br />
<br />
The algorithm gives each link a circular buffer to store the last N messages. When a new message comes in on a particular link, the algorithm first checks if it's already in that link's buffer. If it is, then it's obviously a new message, so its removed from all of the other buffers if it's in any of them. Then, the message is sent. If the message isn't already in the link's buffer, then it's added to the buffer. After that, all of the other link's buffers are checked for the message. If it's in any of them, then the message was already received by another link, so isn't sent. If it's not in any of them, then the message is sent. The following flowchart depicts this algorithm:<br />
<br />
http://1.bp.blogspot.com/-G1LYSsliAiY/UXNBjHj93PI/AAAAAAAAEaI/hom9cRmd3jI/s640/Algorithm+Diagram.png<br />
Caption: Algorithm to prevent duplicate messages<br />
<br />
====Algorithm Considerations====<br />
As the plane sends various, possibly identical, messages and the links gain and lose connection, there is no guarantee that this algorithm will do a perfect job of filtering out identical and only identical messages. However, in typical operation, it seems to work very well. And for the application of displaying aircraft data, the occasional missing or duplicate message is acceptable. There are only a few scenarios where the Link Combiner won't produce perfect results, and they should come up infrequently:<br />
<br />
* A message will be sent twice if the buffer size is too small to hold all of the messages received from one link between that link receiving the message and another link receiving the identical message. When the second link receives the message that has already been received, if the original isn't in the buffer anymore, than the algorithm won't know it's a duplicate message. This scenario should be considered whenever implementing a redundant link system. Partly because it is the most likely to come up, but also because if it does occur, then all messages will be duplicated. In order to avoid this scenario, you can set the buffer size as a command line argument of Link Combiner. To know what a good value would be, you can observer the Ping time and Rx messages/s of the links in the new Link page of the notebook. Calculate the minimum buffer size by taking the difference between the largest ping time and the smallest ping time and multiplying it by the largest Rx messages/s. Then apply a safety factor when setting the buffer size - 10 times the calculated value should be good.<br />
* A message won't be sent when it should be if the autopilot sends a message that's the same as one it already sent (same name and exact same values) AND at least one link was lost between the first message and the second AND the link that's receiving the second message doesn't have the first message in it's buffer still. That's three conditions. If this happens, then the Link Combiner will see the second message as a duplicate of the first and will skip it. Only this one message will be missed though - it won't start happening to all messages. Also, the data will have been data that was already received. So if it's for example the battery voltage message, then it's not a big deal to miss it. As long as there aren't links rapidly being lost and gained, then this shouldn't happen often. Note that as the buffer size is increased, it is believed that this becomes more likely to happen.<br />
<br />
== Ground to Aircraft ==<br />
<br />
This part of the redundant communication system hasn't been implemented yet. All information here is what it is envisioned to look like.<br />
<br />
===Features===<br />
* Enable multiple datalink links to be used for communicating with the autopilot.<br />
* Let different telemetry be sent out each link.<br />
* Let the choice of what telemetry is sent be moved from the settings page of the GCS to the Link page, since it can be different for each link.<br />
* Add a link status indicator (this is the light that turns red when the link is lost) for the datalink to the Link page. This will allow better monitoring of the links by not assuming that if one direction is good, the other direction is good as well.<br />
* Let each link be configured as telemetry only, datalink only, or by-directional.<br />
<br />
===Compatibility===<br />
Communication in the autopilot is enabled with the ground by including the telemetry subsystem in the airframe file. For example:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing or rotorcraft"><br />
...<br />
<subsystem name="telemetry" type="transparent"/><br />
</firmware><br />
</source><br />
}}<br />
<br />
In order to use multiple links, changes should be made to allow a telemetry subsystem for each link. Related to this, would it be advantageous to have multiple instances be supported for each different subsystem? Once the design for this is determined, would actual support for each subsystem have to be added one at a time? Because of the logic for how multiple subsystems should behave together is dependent on the subsystem, this might be the case. The telemetry subsystem for example should default to sending telemetry out each one and combining the telemetry received.<br />
<br />
===Hardware===<br />
Unlike aircraft to ground redundancy, ground to aircraft redundancy requires multiple UART ports in the hardware of the autopilot. The author is not that familiar with this, but believes that there are ways to get multiple UART ports for this purpose:<br />
* Telemetry can be sent out over USB by specifying the telemetry type to be "transparent_usb".<br />
* For the Lisa/M, the USB port can actually be used as a UART port with some hardware modifications.<br />
* Using an I2C GPS instead of a UART one can free up a UART port on most autopilots<br />
* For the Lisa/M, can UART 1 and 5 be used if Spektrum Satellite receivers aren't used? If so, where are the Tx pins?<br />
<br />
In addition, future hardware designs could includes more UART ports for redundant communications or any other purpose.<br />
<br />
===Design===<br />
Unlike the aircraft to ground communication, for ground to aircraft communication it is not acceptable to have the same message be acted on twice. This could cause the aircraft to behave unexpectedly. In order to implement a 100% guaranteed link combiner for the aircraft, the author proposes a system that adds a counter to each message sent to the plane. This would allow the autopilot to easily ignore identical messages - they'll have the same value for counter. Also, since minimal data is sent from the ground to the aircraft, adding the extra bytes to the payload will have a minimal impact on performance - this is not the case for the telemetry.<br />
<br />
The challenging part of this design will be integrating it properly into the existing systems.</div>Camleehttp://wiki.paparazziuav.org/w/index.php?title=Redundant_Communication&diff=14962Redundant Communication2013-04-28T02:43:20Z<p>Camlee: </p>
<hr />
<div>There is currently a pull request to integrate a redundant communication system into the existing ground segment agents: [https://github.com/paparazzi/paparazzi/pull/429]. The goal of this project is to allow multiple radio modems or other links be used between the aircraft and the ground station in a redundant fashion so that even if one link is lost, communication can be maintained. So far, the plane to ground component has been created and tested in the lab. More comprehensive testing should be performed before the system is considered to be stable. The ground to plane component has not been created yet.<br />
<br />
===Reasons to use this===<br />
Communication from the aircraft to the ground is called telemetry. This communication allows the status of the aircraft such as location, altitude, airspeed, battery level, current flight block, and much more to be monitored in real time. Communication from the ground to the aircraft is called datalink. This communication allows the commands to be sent to the aircraft from the ground. This includes telling the aircraft what navigation to perform: waypoint navigation, search area, landing. If a single link is used, as is typical, then if the plane goes out of range, or that link is otherwise lost, no telemetry information can be displayed in the GCS and commands sent from the GCS won't be sent to the aircraft. Using the following redundant link system allows multiple links to be used in an effort to avoid this. Typically, you would introduce diversity when adding links. For example:<br />
* If you have an on-board computer, you could tunnel messages through Wi-Fi over UDP in addition to a traditional 900 MHz XBee radio modem.<br />
* You could use a satellite modem for long-range monitoring in addition to a radio modem.<br />
* You could use a cellular modem in addition to a radio modem.<br />
* With additional ground infrastructure, you could have radio modems located at different locations.<br />
* You could use radio modems at different frequencies or with different antenna gains or orientations.<br />
* You could use this system to evaluate different types of radio modems or antenna placements - you'll get real time info on each such as the ping time, received messages rate, and more information can easily be added.<br />
<br />
There are undoubtedly many more possibilities.<br />
<br />
===Compatibility===<br />
This project was made to be fully backwards compatible and support the awesome functionality that Paparazzi already has. This includes:<br />
* Completely backwards compatible - includes aircraft configuration files, previous flight logs, existing sessions, etc...<br />
* Logging and replay - if multiple links are used, data received through either link is recorded. Also, replays will include the status of each link as it was during the flight.<br />
* Link features such as USB-serial, audio, UDP, different transport layers, etc...<br />
* Multi-aircraft sessions - you can use redundant links for one aircraft, but not for another if desired<br />
* Multiple aircraft connected to the same link - such as might come up in a mesh configuration where one aircraft relays data from another aircraft<br />
<br />
<br />
== Aircraft to Ground ==<br />
<br />
===Features===<br />
Enabling redundant communication from the aircraft to the ground enables the following features:<br />
* Redundancy - as long as one link is receiving data, it will be logged and displayed on the GCS<br />
* Monitoring - the status, ping time, and rate of receiving messages for each link is shown (this makes it useful even if you're only using one link)<br />
* Alerts - new alerts are added to the console in the GCS to alert you when a link has been connected for the first time, lost, or re-gained.<br />
<br />
===Future Improvements===<br />
Several different improvements can be made to this system to improve it's performance and help satisfy everybody's needs:<br />
* <br />
<br />
===How to use===<br />
<br />
For an example using two USB-serial adaptors, see the Flight USB-serial Redundant session saved in the example control_panel.xml configuration (on master branch, once the pull request has been accepted).<br />
<br />
For the details, keep reading:<br />
In order to implement redundant links using this code, there are three simple steps to follow:<br />
<br />
* Connect the hardware - on the airborne side, connect the Rx pin of the autopilot to multiple radio modems or whatever other device which will get the information to the ground. On the ground side, connect multiple modems as normal (using USB to serial adapters, a UDP connection, or whatever).<br />
* Launch a Link agent for each modem. Configure the agents as you would have before (serial port, baud rate, UDP, etc...). None of these features have been modified or removed. Then, use two new command line arguments: -redlink and -id. The -redlink flag tells Link that it's one of multiple links. The -id flag lets you specify an integer number as the id of that particular link.<br />
* Launch the Link Combiner agent. This agent listens to all of the Link agents that have their -redlink set and combines the data.<br />
<br />
The following screenshot shows a session with two links, connected to serial ports ttyUSB0 and ttyUSB1, and with id's 1 and 2:<br />
<br />
http://3.bp.blogspot.com/-jI7EMZ_0614/UXMjlc1MoBI/AAAAAAAAEZo/LwOgVQN336o/s640/Screenshot+from+2013-04-15+22_59_01.png<br />
Caption: The Agents Running in a Redundant Link Setup<br />
<br />
* Test the system and make sure that it works correctly under all circumstances. Do this before flying. In particular, take a look at the [[#Algorithm Considerations|Algorithm Considerations]] section to ensure that the correct buffer size of chosen.<br />
<br />
===Interface===<br />
Once the redundant link system is started (even if only one Link is used), several changes appear in the GCS. This is achieved by the new message LINK_STATUS which is sent by the Link Combiner. These new features are designed to allow closer monitoring and better management of the link(s) between the aircraft and the ground station. <br />
<br />
The following screenshot clearly shows these changes:<br />
http://3.bp.blogspot.com/-jI7EMZ_0614/UXMjlc1MoBI/AAAAAAAAEZo/LwOgVQN336o/s640/Screenshot+from+2013-04-15+22_59_01.png<br />
<br />
Firstly, we can see that there is a new page in the notebook named Link. This page contains critical information for each link. More information can easily be added, but for now, it shows the status of the link (just like the main Link status indicator in the strip), the current ping time, and the rate of received messages. So if one link is lost, it's status indicator will turn red and start counting up just like link 2 in the above screenshot.<br />
<br />
Next, we can see that the main Link status indicator that's located in the strip has been modified slightly. It now shows the ratio of connected links to the total number of links. I.e. 3/4 means that there are four links and one of them has been lost. Furthermore, the indicator will be green if all links are connected, yellow if one or more are lost, and red if all links are lost. Once all links are lost, the indicator will count up just like before.<br />
<br />
Lastly, alerts have been added to the console. Whenever a link is lost or reconnected, a message will appear in the console stating so. Messages also appear when a new link is added.<br />
<br />
===Design===<br />
====Implementation====<br />
Here's a block diagram showing how the plane talks to the various ground segment programs (also known as agents) when not using the redundant link system:<br />
<br />
http://3.bp.blogspot.com/-8-YENO6LcNs/UXMRpkJlx1I/AAAAAAAAEZQ/Z3XDrJCRzQs/s400/Normal+Communication+Layout.png<br />
Caption: Paparazzi Ground Segment<br />
<br />
The ivy bus lets the programs talk to each other through the use of short messages. Pay close attention to the coloured arrows, which show the main flow of these messages. Next we have a block diagram of the redundant link system:<br />
<br />
http://4.bp.blogspot.com/-nx_p90B7FU4/UXMddbJ_gEI/AAAAAAAAEZg/qnbrS-bS3l0/s640/Redundant+Communication+Layout.png<br />
Caption: Paparazzi Ground Segment with Redundant Links<br />
<br />
Here we can see a new agent, the Link Combiner. We also see multiple occurrences of the Link agent. When operating in redundant mode, each occurrence of Link transmits the data it receives from the plane to the Link Combiner instead of the Server. It does this by transmitting the received telemetry messages within the TELEMETRY_MESSAGE message which the Server doesn't listen to. The Link Combiner on the other hand does. TELEMETRY_MESSAGE messages are sent by each link and include the id of that link. The Link Combiner listens to all of them and then transmits a single set of messages to the Server with the combined data. This results in the Server and all other ground segment agents (such as Messages and the Real Time Plotter) getting their telemetry data from Link Combiner as if it was coming from a single occurrence of Link.<br />
<br />
====Link Combiner====<br />
The Link Combiner agent is written in Python. It receives messages from all of the Links (when they're in redundant mode), and outputs messages to the Server and other ground segment agents. There is a bit involved however since the Server and GCS shouldn't be sent identical messages. I.e. if the plane sends a message and it's received successfully by more than one link, then that particular message should only sent by Link Combiner once. This is a somewhat tricky requirement since there is no guarantee that the message will be received by all of the links, and it's possible that the plane actually sends a second message that's exactly the same as the first. No extra info (such as a time-stamp or counter) is added to the messages sent from the plane to the ground, so the Link Combiner employs an algorithm to detect duplicate messages. Testing has shown that for typical links, this algorithm performs extremely well.<br />
<br />
The algorithm gives each link a circular buffer to store the last N messages. When a new message comes in on a particular link, the algorithm first checks if it's already in that link's buffer. If it is, then it's obviously a new message, so its removed from all of the other buffers if it's in any of them. Then, the message is sent. If the message isn't already in the link's buffer, then it's added to the buffer. After that, all of the other link's buffers are checked for the message. If it's in any of them, then the message was already received by another link, so isn't sent. If it's not in any of them, then the message is sent. The following flowchart depicts this algorithm:<br />
<br />
http://1.bp.blogspot.com/-G1LYSsliAiY/UXNBjHj93PI/AAAAAAAAEaI/hom9cRmd3jI/s640/Algorithm+Diagram.png<br />
Caption: Algorithm to prevent duplicate messages<br />
<br />
====Algorithm Considerations====<br />
As the plane sends various, possibly identical, messages and the links gain and lose connection, there is no guarantee that this algorithm will do a perfect job of filtering out identical and only identical messages. However, in typical operation, it seems to work very well. And for the application of displaying aircraft data, the occasional missing or duplicate message is acceptable. There are only a few scenarios where the Link Combiner won't produce perfect results, and they should come up infrequently:<br />
<br />
* A message will be sent twice if the buffer size is too small to hold all of the messages received from one link between that link receiving the message and another link receiving the identical message. When the second link receives the message that has already been received, if the original isn't in the buffer anymore, than the algorithm won't know it's a duplicate message. This scenario should be considered whenever implementing a redundant link system. Partly because it is the most likely to come up, but also because if it does occur, then all messages will be duplicated. In order to avoid this scenario, you can set the buffer size as a command line argument of Link Combiner. To know what a good value would be, you can observer the Ping time and Rx messages/s of the links in the new Link page of the notebook. Calculate the minimum buffer size by taking the difference between the largest ping time and the smallest ping time and multiplying it by the largest Rx messages/s. Then apply a safety factor when setting the buffer size - 10 times the calculated value should be good.<br />
* A message won't be sent when it should be if the autopilot sends a message that's the same as one it already sent (same name and exact same values) AND at least one link was lost between the first message and the second AND the link that's receiving the second message doesn't have the first message in it's buffer still. That's three conditions. If this happens, then the Link Combiner will see the second message as a duplicate of the first and will skip it. Only this one message will be missed though - it won't start happening to all messages. Also, the data will have been data that was already received. So if it's for example the battery voltage message, then it's not a big deal to miss it. As long as there aren't links rapidly being lost and gained, then this shouldn't happen often. Note that as the buffer size is increased, it is believed that this becomes more likely to happen.<br />
<br />
== Ground to Aircraft ==<br />
<br />
This part of the redundant communication system hasn't been implemented yet. All information here is what it is envisioned to look like.<br />
<br />
===Features===<br />
* Enable multiple datalink links to be used for communicating with the autopilot.<br />
* Let different telemetry be sent out each link.<br />
* Let the choice of what telemetry is sent be moved from the settings page of the GCS to the Link page, since it can be different for each link.<br />
* Add a link status indicator (this is the light that turns red when the link is lost) for the datalink to the Link page. This will allow better monitoring of the links by not assuming that if one direction is good, the other direction is good as well.<br />
* Let each link be configured as telemetry only, datalink only, or by-directional.<br />
<br />
===Compatibility===<br />
Communication in the autopilot is enabled with the ground by including the telemetry subsystem in the airframe file. For example:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing or rotorcraft"><br />
...<br />
<subsystem name="telemetry" type="transparent"/><br />
</firmware><br />
</source><br />
}}<br />
<br />
In order to use multiple links, changes should be made to allow a telemetry subsystem for each link. Related to this, would it be advantageous to have multiple instances be supported for each different subsystem? Once the design for this is determined, would actual support for each subsystem have to be added one at a time? Because of the logic for how multiple subsystems should behave together is dependent on the subsystem, this might be the case. The telemetry subsystem for example should default to sending telemetry out each one and combining the telemetry received.<br />
<br />
===Hardware===<br />
Unlike aircraft to ground redundancy, ground to aircraft redundancy requires multiple UART ports in the hardware of the autopilot. The author is not that familiar with this, but believes that there are ways to get multiple UART ports for this purpose:<br />
* Telemetry can be sent out over USB by specifying the telemetry type to be "transparent_usb".<br />
* For the Lisa/M, the USB port can actually be used as a UART port with some hardware modifications.<br />
* Using an I2C GPS instead of a UART one can free up a UART port on most autopilots<br />
* For the Lisa/M, can UART 1 and 5 be used if Spektrum Satellite receivers aren't used? If so, where are the Tx pins?<br />
<br />
In addition, future hardware designs could includes more UART ports for redundant communications or any other purpose.<br />
<br />
===Design===<br />
Unlike the aircraft to ground communication, for ground to aircraft communication it is not acceptable to have the same message be acted on twice. This could cause the aircraft to behave unexpectedly. In order to implement a 100% guaranteed link combiner for the aircraft, the author proposes a system that adds a counter to each message sent to the plane. This would allow the autopilot to easily ignore identical messages - they'll have the same value for counter. Also, since minimal data is sent from the ground to the aircraft, adding the extra bytes to the payload will have a minimal impact on performance - this is not the case for the telemetry.<br />
<br />
The challenging part of this design will be integrating it properly into the existing systems.</div>Camleehttp://wiki.paparazziuav.org/w/index.php?title=Redundant_Communication&diff=14961Redundant Communication2013-04-28T02:35:28Z<p>Camlee: </p>
<hr />
<div>There is currently a pull request to integrate a redundant communication system into the existing ground segment agents: [https://github.com/paparazzi/paparazzi/pull/429]. The goal of this project is to allow multiple radio modems or other links be used between the aircraft and the ground station in a redundant fashion so that even if one link is lost, communication can be maintained. So far, the plane to ground component has been created and tested in the lab. More comprehensive testing should be performed before the system is considered to be stable. The ground to plane component has not been created yet.<br />
<br />
===Reasons to use this===<br />
Communication from the aircraft to the ground is called telemetry. This communication allows the status of the aircraft such as location, altitude, airspeed, battery level, current flight block, and much more to be monitored in real time. Communication from the ground to the aircraft is called datalink. This communication allows the commands to be sent to the aircraft from the ground. This includes telling the aircraft what navigation to perform: waypoint navigation, search area, landing. If a single link is used, as is typical, then if the plane goes out of range, or that link is otherwise lost, no telemetry information can be displayed in the GCS and commands sent from the GCS won't be sent to the aircraft. Using the following redundant link system allows multiple links to be used in an effort to avoid this. Typically, you would introduce diversity when adding links. For example:<br />
* If you have an on-board computer, you could tunnel messages through Wi-Fi over UDP in addition to a traditional 900 MHz XBee radio modem.<br />
* You could use a satellite modem for long-range monitoring in addition to a radio modem.<br />
* You could use a cellular modem in addition to a radio modem.<br />
* With additional ground infrastructure, you could have radio modems located at different locations.<br />
* You could use radio modems at different frequencies or with different antenna gains or orientations.<br />
* You could use this system to evaluate different types of radio modems or antenna placements - you'll get real time info on each such as the ping time, received messages rate, and more information can easily be added.<br />
<br />
There are undoubtedly many more possibilities.<br />
<br />
===Compatibility===<br />
This project was made to be fully backwards compatible and support the awesome functionality that Paparazzi already has. This includes:<br />
* Completely backwards compatible - includes aircraft configuration files, previous flight logs, existing sessions, etc...<br />
* Logging and replay - if multiple links are used, data received through either link is recorded. Also, replays will include the status of each link as it was during the flight.<br />
* Link features such as USB-serial, audio, UDP, different transport layers, etc...<br />
* Multi-aircraft sessions - you can use redundant links for one aircraft, but not for another if desired<br />
* Multiple aircraft connected to the same link - such as might come up in a mesh configuration where one aircraft relays data from another aircraft<br />
<br />
<br />
== Aircraft to Ground ==<br />
<br />
===Features===<br />
Enabling redundant communication from the aircraft to the ground enables the following features:<br />
* Redundancy - as long as one link is receiving data, it will be logged and displayed on the GCS<br />
* Monitoring - the status, ping time, and rate of receiving messages for each link is shown (this makes it useful even if you're only using one link)<br />
* Alerts - new alerts are added to the console in the GCS to alert you when a link has been connected for the first time, lost, or re-gained.<br />
<br />
===Future Improvements===<br />
Several different improvements can be made to this system to improve it's performance and help satisfy everybody's needs:<br />
* <br />
<br />
===How to use===<br />
<br />
For an example using two USB-serial adaptors, see the Flight USB-serial Redundant session saved in the example control_panel.xml configuration (on master branch, once the pull request has been accepted).<br />
<br />
For the details, keep reading:<br />
In order to implement redundant links using this code, there are three simple steps to follow:<br />
<br />
* Connect the hardware - on the airborne side, connect the Rx pin of the autopilot to multiple radio modems or whatever other device which will get the information to the ground. On the ground side, connect multiple modems as normal (using USB to serial adapters, a UDP connection, or whatever).<br />
* Launch a Link agent for each modem. Configure the agents as you would have before (serial port, baud rate, UDP, etc...). None of these features have been modified or removed. Then, use two new command line arguments: -redlink and -id. The -redlink flag tells Link that it's one of multiple links. The -id flag lets you specify an integer number as the id of that particular link.<br />
* Launch the Link Combiner agent. This agent listens to all of the Link agents that have their -redlink set and combines the data.<br />
<br />
The following screenshot shows a session with two links, connected to serial ports ttyUSB0 and ttyUSB1, and with id's 1 and 2:<br />
<br />
http://3.bp.blogspot.com/-jI7EMZ_0614/UXMjlc1MoBI/AAAAAAAAEZo/LwOgVQN336o/s640/Screenshot+from+2013-04-15+22_59_01.png<br />
Caption: The Agents Running in a Redundant Link Setup<br />
<br />
* Test the system and make sure that it works correctly under all circumstances. Do this before flying. In particular, take a look at the [[#Algorithm Considerations|Algorithm Considerations]] section to ensure that the correct buffer size of chosen.<br />
<br />
===Interface===<br />
Once the redundant link system is started (even if only one Link is used), several changes appear in the GCS. This is achieved by the new message LINK_STATUS which is sent by the Link Combiner. These new features are designed to allow closer monitoring and better management of the link(s) between the aircraft and the ground station. <br />
<br />
The following screenshot clearly shows these changes:<br />
http://3.bp.blogspot.com/-jI7EMZ_0614/UXMjlc1MoBI/AAAAAAAAEZo/LwOgVQN336o/s640/Screenshot+from+2013-04-15+22_59_01.png<br />
<br />
Firstly, we can see that there is a new page in the notebook named Link. This page contains critical information for each link. More information can easily be added, but for now, it shows the status of the link (just like the main Link status indicator in the strip), the current ping time, and the rate of received messages. So if one link is lost, it's status indicator will turn red and start counting up just like link 2 in the above screenshot.<br />
<br />
Next, we can see that the main Link status indicator that's located in the strip has been modified slightly. It now shows the ratio of connected links to the total number of links. I.e. 3/4 means that there are four links and one of them has been lost. Furthermore, the indicator will be green if all links are connected, yellow if one or more are lost, and red if all links are lost. Once all links are lost, the indicator will count up just like before.<br />
<br />
Lastly, alerts have been added to the console. Whenever a link is lost or reconnected, a message will appear in the console stating so. Messages also appear when a new link is added.<br />
<br />
===Design===<br />
Here's a block diagram showing how the plane talks to the various ground segment programs (also known as agents) when not using the redundant link system:<br />
<br />
http://3.bp.blogspot.com/-8-YENO6LcNs/UXMRpkJlx1I/AAAAAAAAEZQ/Z3XDrJCRzQs/s400/Normal+Communication+Layout.png<br />
Caption: Paparazzi Ground Segment<br />
<br />
The ivy bus lets the programs talk to each other through the use of short messages. Pay close attention to the coloured arrows, which show the main flow of these messages. Next we have a block diagram of the redundant link system:<br />
<br />
http://4.bp.blogspot.com/-nx_p90B7FU4/UXMddbJ_gEI/AAAAAAAAEZg/qnbrS-bS3l0/s640/Redundant+Communication+Layout.png<br />
Caption: Paparazzi Ground Segment with Redundant Links<br />
<br />
Here we can see a new agent, the Link Combiner. We also see multiple occurrences of the Link agent. When operating in redundant mode, each occurrence of Link transmits the data it receives from the plane to the Link Combiner instead of the Server. It does this by transmitting the received telemetry messages within the TELEMETRY_MESSAGE message which the Server doesn't listen to. The Link Combiner on the other hand does. TELEMETRY_MESSAGE messages are sent by each link and include the id of that link. The Link Combiner listens to all of them and then transmits a single set of messages to the Server with the combined data. This results in the Server and all other ground segment agents (such as Messages and the Real Time Plotter) getting their telemetry data from Link Combiner as if it was coming from a single occurrence of Link.<br />
<br />
====Link Combiner====<br />
The Link Combiner agent is written in Python. It receives messages from all of the Links (when they're in redundant mode), and outputs messages to the Server and other ground segment agents. There is a bit involved however since the Server and GCS shouldn't be sent identical messages. I.e. if the plane sends a message and it's received successfully by more than one link, then that particular message should only sent by Link Combiner once. This is a somewhat tricky requirement since there is no guarantee that the message will be received by all of the links, and it's possible that the plane actually sends a second message that's exactly the same as the first. No extra info (such as a time-stamp or counter) is added to the messages sent from the plane to the ground, so the Link Combiner employs an algorithm to detect duplicate messages. Testing has shown that for typical links, this algorithm performs extremely well.<br />
<br />
The algorithm gives each link a circular buffer to store the last N messages. When a new message comes in on a particular link, the algorithm first checks if it's already in that link's buffer. If it is, then it's obviously a new message, so its removed from all of the other buffers if it's in any of them. Then, the message is sent. If the message isn't already in the link's buffer, then it's added to the buffer. After that, all of the other link's buffers are checked for the message. If it's in any of them, then the message was already received by another link, so isn't sent. If it's not in any of them, then the message is sent. The following flowchart depicts this algorithm:<br />
<br />
http://1.bp.blogspot.com/-G1LYSsliAiY/UXNBjHj93PI/AAAAAAAAEaI/hom9cRmd3jI/s640/Algorithm+Diagram.png<br />
Caption: Algorithm to prevent duplicate messages<br />
<br />
====Algorithm Considerations====<br />
As the plane sends various, possibly identical, messages and the links gain and lose connection, there is no guarantee that this algorithm will do a perfect job of filtering out identical and only identical messages. However, in typical operation, it seems to work very well. And for the application of displaying aircraft data, the occasional missing or duplicate message is acceptable. There are only a few scenarios where the Link Combiner won't produce perfect results, and they should come up infrequently:<br />
<br />
* A message will be sent twice if the buffer size is too small to hold all of the messages received from one link between that link receiving the message and another link receiving the identical message. When the second link receives the message that has already been received, if the original isn't in the buffer anymore, than the algorithm won't know it's a duplicate message. This scenario should be considered whenever implementing a redundant link system. Partly because it is the most likely to come up, but also because if it does occur, then all messages will be duplicated. In order to avoid this scenario, you can set the buffer size as a command line argument of Link Combiner. To know what a good value would be, you can observer the Ping time and Rx messages/s of the links in the new Link page of the notebook. Calculate the minimum buffer size by taking the difference between the largest ping time and the smallest ping time and multiplying it by the largest Rx messages/s. Then apply a safety factor when setting the buffer size - 10 times the calculated value should be good.<br />
* A message won't be sent when it should be if the autopilot sends a message that's the same as one it already sent (same name and exact same values) AND at least one link was lost between the first message and the second AND the link that's receiving the second message doesn't have the first message in it's buffer still. That's three conditions. If this happens, then the Link Combiner will see the second message as a duplicate of the first and will skip it. Only this one message will be missed though - it won't start happening to all messages. Also, the data will have been data that was already received. So if it's for example the battery voltage message, then it's not a big deal to miss it. As long as there aren't links rapidly being lost and gained, then this shouldn't happen often. Note that as the buffer size is increased, I believe that this becomes more likely to happen.<br />
<br />
<br />
<br />
<br />
== Ground to Aircraft ==<br />
<br />
This part of the redundant communication system hasn't been implemented yet. All information here is what it is envisioned to look like.<br />
<br />
===Features===<br />
* Enable multiple datalink links to be used for communicating with the autopilot.<br />
* Let different telemetry be sent out each link.<br />
* Let the choice of what telemetry is sent be moved from the settings page of the GCS to the Link page, since it can be different for each link.<br />
* Add a link status indicator (this is the light that turns red when the link is lost) for the datalink to the Link page. This will allow better monitoring of the links by not assuming that if one direction is good, the other direction is good as well.<br />
* Let each link be configured as telemetry only, datalink only, or by-directional.<br />
<br />
===Compatibility===<br />
Communication in the autopilot is enabled with the ground by including the telemetry subsystem in the airframe file. For example:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing or rotorcraft"><br />
...<br />
<subsystem name="telemetry" type="transparent"/><br />
</firmware><br />
</source><br />
}}<br />
<br />
In order to use multiple links, changes should be made to allow a telemetry subsystem for each link. Related to this, I've heard that it would be advantageous multiple instances of each subsystem to be included. I would imaging that once the design for this is determined, actual support for each subsystem would have to be added one at a time. This is because the logic for how multiple subsystems should behave together is dependent on the subsystem. The telemetry subsystem for example should default to sending telemetry out each one and combining the telemetry received.<br />
<br />
<br />
===Hardware===<br />
Unlike aircraft to ground redundancy, ground to aircraft redundancy requires multiple UART ports in the hardware of the autopilot. The author is not that familiar with this, but believes that there are ways to get multiple UART ports for this purpose:<br />
* Telemetry can be sent out over USB by specifying the telemetry type to be "transparent_usb".<br />
* For the Lisa/M, the USB port can actually be used as a UART port with some hardware modifications.<br />
* Using an I2C GPS instead of a UART one can free up a UART port on most autopilots<br />
* For the Lisa/M, can UART 1 and 5 be used if Spektrum Satellite receivers aren't used? If so, where are the Tx pins?<br />
<br />
<br />
In addition, future hardware designs could includes more UART ports for redundant communications or any other purpose.<br />
<br />
===Design===<br />
Unlike the aircraft to ground communication, for ground to aircraft communication it is not acceptable to have the same message be acted on twice. This could cause the aircraft to behave unexpectedly. In order to implement a 100% guaranteed link combiner for the aircraft, I propose a system that adds a counter to each message sent to the plane. This would allow the autopilot to easily ignore identical messages - they'll have the same value for counter. Also, since minimal data is sent from the ground to the aircraft, adding the extra bytes to the payload will have a minimal impact on performance - this is not the case for the telemetry.<br />
<br />
The challenging part of this design will be integrating it properly into the existing systems.</div>Camleehttp://wiki.paparazziuav.org/w/index.php?title=Redundant_Communication&diff=14960Redundant Communication2013-04-28T00:45:39Z<p>Camlee: </p>
<hr />
<div>There is currently a pull request to integrate a redundant communication system into the existing ground segment agents: [https://github.com/paparazzi/paparazzi/pull/429]. The goal of this project is to allow multiple radio modems or other links be used between the aircraft and the ground station in a redundant fashion so that even if one link is lost, communication can be maintained. So far, the plane to ground component has been created and tested. The ground to plane component has not been created yet.<br />
<br />
===Reasons to use this===<br />
Communication from the aircraft to the ground is called telemetry. This communication allows the status of the aircraft such as location, altitude, airspeed, battery level, current flight block, and much more to be monitored in real time. Communication from the ground to the aircraft is called datalink. This communication allows the commands to be sent to the aircraft from the ground. This includes telling the aircraft what navigation to perform: waypoint navigation, search area, landing. If a single link is used, as is typical, then if the plane goes out of range, or that link is otherwise lost, no telemetry information can be displayed in the GCS and commands sent from the GCS won't be sent to the aircraft. Using the following redundant link system allows multiple links to be used in an effort to avoid this. Typically, you would introduce diversity when adding links. For example:<br />
* If you have an on-board computer, you could tunnel messages through Wi-Fi over UDP in addition to a traditional 900 MHz XBee radio modem.<br />
* You could use a satellite modem for long-range monitoring in addition to a radio modem.<br />
* You could use a cellular modem in addition to a radio modem.<br />
* With additional ground infrastructure, you could have radio modems located at different locations.<br />
* You could use radio modems at different frequencies or with different antenna gains or orientations.<br />
* You could use this system to evaluate different types of radio modems or antenna placements - you'll get real time info on each such as the ping time, received messages rate, and more information can easily be added.<br />
<br />
There are undoubtedly many more possibilities.<br />
<br />
===Compatibility===<br />
This project was made to be fully backwards compatible and support the awesome functionality that Paparazzi already has. This includes:<br />
* Completely backwards compatible - includes aircraft configuration files, previous flight logs, existing sessions, etc...<br />
* Logging and replay - if multiple links are used, data received through either link is recorded. Also, replays will include the status of each link as it was during the flight.<br />
* Link features such as USB-serial, audio, UDP, different transport layers, etc...<br />
* Multi-aircraft sessions - you can use redundant links for one aircraft, but not for another if desired<br />
* Multiple aircraft connected to the same link - such as might come up in a mesh configuration where one aircraft relays data from another aircraft<br />
<br />
<br />
== Aircraft to Ground ==<br />
<br />
===Features===<br />
Enabling redundant communication from the aircraft to the ground enables the following features:<br />
* Redundancy - as long as one link is receiving data, it will be logged and displayed on the GCS<br />
* Monitoring - the status, ping time, and rate of receiving messages for each link is shown (this makes it useful even if you're only using one link)<br />
* Alerts - new alerts are added to the console in the GCS to alert you when a link has been connected for the first time, lost, or re-gained.<br />
<br />
===How to use===<br />
<br />
For an example using two USB-serial adaptors, see the Flight USB-serial Redundant session saved in the example control_panel.xml configuration (on master branch, once the pull request has been accepted).<br />
<br />
For the details, keep reading:<br />
In order to implement redundant links using this code, there are three simple steps to follow:<br />
<br />
* Connect the hardware - on the airborne side, connect the Rx pin of the autopilot to multiple radio modems or whatever other device which will get the information to the ground. On the ground side, connect multiple modems as normal (using USB to serial adapters, a UDP connection, or whatever).<br />
* Launch a Link agent for each modem. Configure the agents as you would have before (serial port, baud rate, UDP, etc...). None of these features have been modified or removed. Then, use two new command line arguments: -redlink and -id. The -redlink flag tells Link that it's one of multiple links. The -id flag lets you specify an integer number as the id of that particular link.<br />
* Launch the Link Combiner agent. This agent listens to all of the Link agents that have their -redlink set and combines the data.<br />
<br />
The following screenshot shows a session with two links, connected to serial ports ttyUSB0 and ttyUSB1, and with id's 1 and 2:<br />
<br />
http://3.bp.blogspot.com/-jI7EMZ_0614/UXMjlc1MoBI/AAAAAAAAEZo/LwOgVQN336o/s640/Screenshot+from+2013-04-15+22_59_01.png<br />
Caption: The Agents Running in a Redundant Link Setup<br />
<br />
* Test the system and make sure that it works correctly under all circumstances. Do this before flying. In particular, take a look at the [[#Algorithm Considerations|Algorithm Considerations]] section to ensure that the correct buffer size of chosen.<br />
<br />
===Interface===<br />
Once the redundant link system is started (even if only one Link is used), several changes appear in the GCS. This is achieved by the new message LINK_STATUS which is sent by the Link Combiner. These new features are designed to allow closer monitoring and better management of the link(s) between the aircraft and the ground station. <br />
<br />
The following screenshot clearly shows these changes:<br />
http://3.bp.blogspot.com/-jI7EMZ_0614/UXMjlc1MoBI/AAAAAAAAEZo/LwOgVQN336o/s640/Screenshot+from+2013-04-15+22_59_01.png<br />
<br />
Firstly, we can see that there is a new page in the notebook named Link. This page contains critical information for each link. More information can easily be added, but for now, it shows the status of the link (just like the main Link status indicator in the strip), the current ping time, and the rate of received messages. So if one link is lost, it's status indicator will turn red and start counting up just like link 2 in the above screenshot.<br />
<br />
Next, we can see that the main Link status indicator that's located in the strip has been modified slightly. It now shows the ratio of connected links to the total number of links. I.e. 3/4 means that there are four links and one of them has been lost. Furthermore, the indicator will be green if all links are connected, yellow if one or more are lost, and red if all links are lost. Once all links are lost, the indicator will count up just like before.<br />
<br />
Lastly, alerts have been added to the console. Whenever a link is lost or reconnected, a message will appear in the console stating so. Messages also appear when a new link is added.<br />
<br />
===Design===<br />
Here's a block diagram showing how the plane talks to the various ground segment programs (also known as agents) when not using the redundant link system:<br />
<br />
http://3.bp.blogspot.com/-8-YENO6LcNs/UXMRpkJlx1I/AAAAAAAAEZQ/Z3XDrJCRzQs/s400/Normal+Communication+Layout.png<br />
Caption: Paparazzi Ground Segment<br />
<br />
The ivy bus lets the programs talk to each other through the use of short messages. Pay close attention to the coloured arrows, which show the main flow of these messages. Next we have a block diagram of the redundant link system:<br />
<br />
http://4.bp.blogspot.com/-nx_p90B7FU4/UXMddbJ_gEI/AAAAAAAAEZg/qnbrS-bS3l0/s640/Redundant+Communication+Layout.png<br />
Caption: Paparazzi Ground Segment with Redundant Links<br />
<br />
Here we can see a new agent, the Link Combiner. We also see multiple occurrences of the Link agent. When operating in redundant mode, each occurrence of Link transmits the data it receives from the plane to the Link Combiner instead of the Server. It does this by transmitting the received telemetry messages within the TELEMETRY_MESSAGE message which the Server doesn't listen to. The Link Combiner on the other hand does. TELEMETRY_MESSAGE messages are sent by each link and include the id of that link. The Link Combiner listens to all of them and then transmits a single set of messages to the Server with the combined data. This results in the Server and all other ground segment agents (such as Messages and the Real Time Plotter) getting their telemetry data from Link Combiner as if it was coming from a single occurrence of Link.<br />
<br />
====Link Combiner====<br />
The Link Combiner agent is written in Python. It receives messages from all of the Links (when they're in redundant mode), and outputs messages to the Server and other ground segment agents. There is a bit involved however since the Server and GCS shouldn't be sent identical messages. I.e. if the plane sends a message and it's received successfully by more than one link, then that particular message should only sent by Link Combiner once. This is a somewhat tricky requirement since there is no guarantee that the message will be received by all of the links, and it's possible that the plane actually sends a second message that's exactly the same as the first. No extra info (such as a time-stamp or counter) is added to the messages sent from the plane to the ground, so the Link Combiner employs an algorithm to detect duplicate messages. Testing has shown that for typical links, this algorithm performs extremely well.<br />
<br />
The algorithm gives each link a circular buffer to store the last N messages. When a new message comes in on a particular link, the algorithm first checks if it's already in that link's buffer. If it is, then it's obviously a new message, so its removed from all of the other buffers if it's in any of them. Then, the message is sent. If the message isn't already in the link's buffer, then it's added to the buffer. After that, all of the other link's buffers are checked for the message. If it's in any of them, then the message was already received by another link, so isn't sent. If it's not in any of them, then the message is sent. The following flowchart depicts this algorithm:<br />
<br />
http://1.bp.blogspot.com/-G1LYSsliAiY/UXNBjHj93PI/AAAAAAAAEaI/hom9cRmd3jI/s640/Algorithm+Diagram.png<br />
Caption: Algorithm to prevent duplicate messages<br />
<br />
====Algorithm Considerations====<br />
As the plane sends various, possibly identical, messages and the links gain and lose connection, there is no guarantee that this algorithm will do a perfect job of filtering out identical and only identical messages. However, in typical operation, it seems to work very well. And for the application of displaying aircraft data, the occasional missing or duplicate message is acceptable. There are only a few scenarios where the Link Combiner won't produce perfect results, and they should come up infrequently:<br />
<br />
* A message will be sent twice if the buffer size is too small to hold all of the messages received from one link between that link receiving the message and another link receiving the identical message. When the second link receives the message that has already been received, if the original isn't in the buffer anymore, than the algorithm won't know it's a duplicate message. This scenario should be considered whenever implementing a redundant link system. Partly because it is the most likely to come up, but also because if it does occur, then all messages will be duplicated. In order to avoid this scenario, you can set the buffer size as a command line argument of Link Combiner. To know what a good value would be, you can observer the Ping time and Rx messages/s of the links in the new Link page of the notebook. Calculate the minimum buffer size by taking the difference between the largest ping time and the smallest ping time and multiplying it by the largest Rx messages/s. Then apply a safety factor when setting the buffer size - 10 times the calculated value should be good.<br />
* A message won't be sent when it should be if the autopilot sends a message that's the same as one it already sent (same name and exact same values) AND at least one link was lost between the first message and the second AND the link that's receiving the second message doesn't have the first message in it's buffer still. That's three conditions. If this happens, then the Link Combiner will see the second message as a duplicate of the first and will skip it. Only this one message will be missed though - it won't start happening to all messages. Also, the data will have been data that was already received. So if it's for example the battery voltage message, then it's not a big deal to miss it. As long as there aren't links rapidly being lost and gained, then this shouldn't happen often. Note that as the buffer size is increased, I believe that this becomes more likely to happen.<br />
<br />
<br />
<br />
<br />
== Ground to Aircraft ==</div>Camleehttp://wiki.paparazziuav.org/w/index.php?title=Redundant_Communication&diff=14959Redundant Communication2013-04-28T00:40:23Z<p>Camlee: </p>
<hr />
<div>There is currently a pull request to integrate a redundant communication system into the existing ground segment agents: [https://github.com/paparazzi/paparazzi/pull/429]. The goal of this project is to allow multiple radio modems or other links be used between the aircraft and the ground station in a redundant fashion so that even if one link is lost, communication can be maintained. So far, the plane to ground component has been created and tested. The ground to plane component has not been created yet.<br />
<br />
===Reasons to use this===<br />
Communication from the aircraft to the ground is called telemetry. This communication allows the status of the aircraft such as location, altitude, airspeed, battery level, current flight block, and much more to be monitored in real time. Communication from the ground to the aircraft is called datalink. This communication allows the commands to be sent to the aircraft from the ground. This includes telling the aircraft what navigation to perform: waypoint navigation, search area, landing. If a single link is used, as is typical, then if the plane goes out of range, or that link is otherwise lost, no telemetry information can be displayed in the GCS and commands sent from the GCS won't be sent to the aircraft. Using the following redundant link system allows multiple links to be used in an effort to avoid this. Typically, you would introduce diversity when adding links. For example:<br />
* If you have an on-board computer, you could tunnel messages through Wi-Fi over UDP in addition to a traditional 900 MHz XBee radio modem.<br />
* You could use a satellite modem for long-range monitoring in addition to a radio modem.<br />
* You could use a cellular modem in addition to a radio modem.<br />
* With additional ground infrastructure, you could have radio modems located at different locations.<br />
* You could use radio modems at different frequencies or with different antenna gains or orientations.<br />
* You could use this system to evaluate different types of radio modems or antenna placements - you'll get real time info on each such as the ping time, received messages rate, and more information can easily be added.<br />
<br />
There are undoubtedly many more possibilities.<br />
<br />
===Compatibility===<br />
This project was made to be fully backwards compatible and support the awesome functionality that Paparazzi already has. This includes:<br />
* Completely backwards compatible - includes aircraft configuration files, previous flight logs, existing sessions, etc...<br />
* Logging and replay - if multiple links are used, data received through either link is recorded. Also, replays will include the status of each link as it was during the flight.<br />
* Link features such as USB-serial, audio, UDP, different transport layers, etc...<br />
* Multi-aircraft sessions - you can use redundant links for one aircraft, but not for another if desired<br />
* Multiple aircraft connected to the same link - such as might come up in a mesh configuration where one aircraft relays data from another aircraft<br />
<br />
<br />
== Aircraft to Ground ==<br />
<br />
===Features===<br />
Enabling redundant communication from the aircraft to the ground enables the following features:<br />
* Redundancy - as long as one link is receiving data, it will be logged and displayed on the GCS<br />
* Monitoring - the status, ping time, and rate of receiving messages for each link is shown (this makes it useful even if you're only using one link)<br />
* Alerts - new alerts are added to the console in the GCS to alert you when a link has been connected for the first time, lost, or re-gained.<br />
<br />
===How to use===<br />
<br />
For an example using two USB-serial adaptors, see the Flight USB-serial Redundant session saved in the example control_panel.xml configuration (on master branch, once the pull request has been accepted).<br />
<br />
For the details, keep reading:<br />
In order to implement redundant links using this code, there are three simple steps to follow:<br />
<br />
* Connect the hardware - on the airborne side, connect the Rx pin of the autopilot to multiple radio modems or whatever other device which will get the information to the ground. On the ground side, connect multiple modems as normal (using USB to serial adapters, a UDP connection, or whatever).<br />
* Launch a Link agent for each modem. Configure the agents as you would have before (serial port, baud rate, UDP, etc...). None of these features have been modified or removed. Then, use two new command line arguments: -redlink and -id. The -redlink flag tells Link that it's one of multiple links. The -id flag lets you specify an integer number as the id of that particular link.<br />
* Launch the Link Combiner agent. This agent listens to all of the Link agents that have their -redlink set and combines the data.<br />
<br />
The following screenshot shows a session with two links, connected to serial ports ttyUSB0 and ttyUSB1, and with id's 1 and 2:<br />
<br />
http://3.bp.blogspot.com/-jI7EMZ_0614/UXMjlc1MoBI/AAAAAAAAEZo/LwOgVQN336o/s640/Screenshot+from+2013-04-15+22_59_01.png<br />
<br />
Caption: The Agents Running in a Redundant Link Setup<br />
<br />
===Interface===<br />
Once the redundant link system is started (even if only one Link is used), several changes appear in the GCS. This is achieved by the new message LINK_STATUS which is sent by the Link Combiner. These new features are designed to allow closer monitoring and better management of the link(s) between the aircraft and the ground station. <br />
<br />
The following screenshot clearly shows these changes:<br />
http://3.bp.blogspot.com/-jI7EMZ_0614/UXMjlc1MoBI/AAAAAAAAEZo/LwOgVQN336o/s640/Screenshot+from+2013-04-15+22_59_01.png<br />
<br />
Firstly, we can see that there is a new page in the notebook named Link. This page contains critical information for each link. More information can easily be added, but for now, it shows the status of the link (just like the main Link status indicator in the strip), the current ping time, and the rate of received messages. So if one link is lost, it's status indicator will turn red and start counting up just like link 2 in the above screenshot.<br />
<br />
Next, we can see that the main Link status indicator that's located in the strip has been modified slightly. It now shows the ratio of connected links to the total number of links. I.e. 3/4 means that there are four links and one of them has been lost. Furthermore, the indicator will be green if all links are connected, yellow if one or more are lost, and red if all links are lost. Once all links are lost, the indicator will count up just like before.<br />
<br />
Lastly, alerts have been added to the console. Whenever a link is lost or reconnected, a message will appear in the console stating so. Messages also appear when a new link is added.<br />
<br />
===Design===<br />
Here's a block diagram showing how the plane talks to the various ground segment programs (also known as agents) when not using the redundant link system:<br />
<br />
http://3.bp.blogspot.com/-8-YENO6LcNs/UXMRpkJlx1I/AAAAAAAAEZQ/Z3XDrJCRzQs/s400/Normal+Communication+Layout.png<br />
Caption: Paparazzi Ground Segment<br />
<br />
The ivy bus lets the programs talk to each other through the use of short messages. Pay close attention to the coloured arrows, which show the main flow of these messages. Next we have a block diagram of the redundant link system:<br />
<br />
http://4.bp.blogspot.com/-nx_p90B7FU4/UXMddbJ_gEI/AAAAAAAAEZg/qnbrS-bS3l0/s640/Redundant+Communication+Layout.png<br />
Caption: Paparazzi Ground Segment with Redundant Links<br />
<br />
Here we can see a new agent, the Link Combiner. We also see multiple occurrences of the Link agent. When operating in redundant mode, each occurrence of Link transmits the data it receives from the plane to the Link Combiner instead of the Server. It does this by transmitting the received telemetry messages within the TELEMETRY_MESSAGE message which the Server doesn't listen to. The Link Combiner on the other hand does. TELEMETRY_MESSAGE messages are sent by each link and include the id of that link. The Link Combiner listens to all of them and then transmits a single set of messages to the Server with the combined data. This results in the Server and all other ground segment agents (such as Messages and the Real Time Plotter) getting their telemetry data from Link Combiner as if it was coming from a single occurrence of Link.<br />
<br />
====Link Combiner====<br />
The Link Combiner agent is written in Python. It receives messages from all of the Links (when they're in redundant mode), and outputs messages to the Server and other ground segment agents. There is a bit involved however since the Server and GCS shouldn't be sent identical messages. I.e. if the plane sends a message and it's received successfully by more than one link, then that particular message should only sent by Link Combiner once. This is a somewhat tricky requirement since there is no guarantee that the message will be received by all of the links, and it's possible that the plane actually sends a second message that's exactly the same as the first. No extra info (such as a time-stamp or counter) is added to the messages sent from the plane to the ground, so the Link Combiner employs an algorithm to detect duplicate messages. Testing has shown that for typical links, this algorithm performs extremely well.<br />
<br />
The algorithm gives each link a circular buffer to store the last N messages. When a new message comes in on a particular link, the algorithm first checks if it's already in that link's buffer. If it is, then it's obviously a new message, so its removed from all of the other buffers if it's in any of them. Then, the message is sent. If the message isn't already in the link's buffer, then it's added to the buffer. After that, all of the other link's buffers are checked for the message. If it's in any of them, then the message was already received by another link, so isn't sent. If it's not in any of them, then the message is sent. The following flowchart depicts this algorithm:<br />
<br />
http://1.bp.blogspot.com/-G1LYSsliAiY/UXNBjHj93PI/AAAAAAAAEaI/hom9cRmd3jI/s640/Algorithm+Diagram.png<br />
Caption: Algorithm to prevent duplicate messages<br />
<br />
As the plane sends various, possibly identical, messages and the links gain and lose connection, there is no guarantee that this algorithm will do a perfect job of filtering out identical and only identical messages. However, in typical operation, it seems to work very well. And for the application of displaying aircraft data, the occasional missing or duplicate message is acceptable. There are only a few scenarios where the Link Combiner won't produce perfect results, and they should come up infrequently:<br />
<br />
* A message will be sent twice if the buffer size is too small to hold all of the messages received from one link between that link receiving the message and another link receiving the identical message. When the second link receives the message that has already been received, if the original isn't in the buffer anymore, than the algorithm won't know it's a duplicate message. This scenario should be considered whenever implementing a redundant link system. Partly because it is the most likely to come up, but also because if it does occur, then all messages will be duplicated. In order to avoid this scenario, you can set the buffer size as a command line argument of Link Combiner. To know what a good value would be, you can observer the Ping time and Rx messages/s of the links in the new Link page of the notebook. Calculate the minimum buffer size by taking the difference between the largest ping time and the smallest ping time and multiplying it by the largest Rx messages/s. Then apply a safety factor when setting the buffer size - 10 times the calculated value should be good.<br />
* A message won't be sent when it should be if the autopilot sends a message that's the same as one it already sent (same name and exact same values) AND at least one link was lost between the first message and the second AND the link that's receiving the second message doesn't have the first message in it's buffer still. That's three conditions. If this happens, then the Link Combiner will see the second message as a duplicate of the first and will skip it. Only this one message will be missed though - it won't start happening to all messages. Also, the data will have been data that was already received. So if it's for example the battery voltage message, then it's not a big deal to miss it. As long as there aren't links rapidly being lost and gained, then this shouldn't happen often. Note that as the buffer size is increased, I believe that this becomes more likely to happen.<br />
<br />
<br />
<br />
<br />
== Ground to Aircraft ==</div>Camleehttp://wiki.paparazziuav.org/w/index.php?title=Redundant_Communication&diff=14958Redundant Communication2013-04-28T00:24:16Z<p>Camlee: </p>
<hr />
<div>There is currently a pull request to integrate a redundant communication system into the existing ground segment agents: [https://github.com/paparazzi/paparazzi/pull/429]. The goal of this project is to allow multiple radio modems or other links be used between the aircraft and the ground station in a redundant fashion so that even if one link is lost, communication can be maintained. So far, the plane to ground component has been created and tested. The ground to plane component has not been created yet.<br />
<br />
===Reasons to use this===<br />
Communication from the aircraft to the ground is called telemetry. This communication allows the status of the aircraft such as location, altitude, airspeed, battery level, current flight block, and much more to be monitored in real time. Communication from the ground to the aircraft is called datalink. This communication allows the commands to be sent to the aircraft from the ground. This includes telling the aircraft what navigation to perform: waypoint navigation, search area, landing. If a single link is used, as is typical, then if the plane goes out of range, or that link is otherwise lost, no telemetry information can be displayed in the GCS and commands sent from the GCS won't be sent to the aircraft. Using the following redundant link system allows multiple links to be used in an effort to avoid this. Typically, you would introduce diversity when adding links. For example:<br />
* If you have an on-board computer, you could tunnel messages through Wi-Fi over UDP in addition to a traditional 900 MHz XBee radio modem.<br />
* You could use a satellite modem for long-range monitoring in addition to a radio modem.<br />
* You could use a cellular modem in addition to a radio modem.<br />
* With additional ground infrastructure, you could have radio modems located at different locations.<br />
* You could use radio modems at different frequencies or with different antenna gains or orientations.<br />
* You could use this system to evaluate different types of radio modems or antenna placements - you'll get real time info on each such as the ping time, received messages rate, and more information can easily be added.<br />
<br />
There are undoubtedly many more possibilities.<br />
<br />
===Compatibility===<br />
This project was made to be fully backwards compatible and support the awesome functionality that Paparazzi already has. This includes:<br />
* Completely backwards compatible - includes aircraft configuration files, previous flight logs, existing sessions, etc...<br />
* Logging and replay - if multiple links are used, data received through either link is recorded. Also, replays will include the status of each link as it was during the flight.<br />
* Link features such as USB-serial, audio, UDP, different transport layers, etc...<br />
* Multi-aircraft sessions - you can use redundant links for one aircraft, but not for another if desired<br />
* Multiple aircraft connected to the same link - such as might come up in a mesh configuration where one aircraft relays data from another aircraft<br />
<br />
<br />
== Aircraft to Ground ==<br />
<br />
===Features===<br />
Enabling redundant communication from the aircraft to the ground enables the following features:<br />
* Redundancy - as long as one link is receiving data, it will be logged and displayed on the GCS<br />
* Monitoring - the status, ping time, and rate of receiving messages for each link is shown (this makes it useful even if you're only using one link)<br />
* Alerts - new alerts are added to the console in the GCS to alert you when a link has been connected for the first time, lost, or re-gained.<br />
<br />
===How to use===<br />
<br />
For an example using two USB-serial adaptors, see the Flight USB-serial Redundant session saved in the example control_panel.xml configuration (on master branch, once the pull request has been accepted).<br />
<br />
For the details, keep reading:<br />
In order to implement redundant links using this code, there are three simple steps to follow:<br />
<br />
* Connect the hardware - on the airborne side, connect the Rx pin of the autopilot to multiple radio modems or whatever other device which will get the information to the ground. On the ground side, connect multiple modems as normal (using USB to serial adapters, a UDP connection, or whatever).<br />
* Launch a Link agent for each modem. Configure the agents as you would have before (serial port, baud rate, UDP, etc...). None of these features have been modified or removed. Then, use two new command line arguments: -redlink and -id. The -redlink flag tells Link that it's one of multiple links. The -id flag lets you specify an integer number as the id of that particular link.<br />
* Launch the Link Combiner agent. This agent listens to all of the Link agents that have their -redlink set and combines the data.<br />
<br />
The following screenshot shows a session with two links, connected to serial ports ttyUSB0 and ttyUSB1, and with id's 1 and 2:<br />
<br />
http://3.bp.blogspot.com/-jI7EMZ_0614/UXMjlc1MoBI/AAAAAAAAEZo/LwOgVQN336o/s640/Screenshot+from+2013-04-15+22_59_01.png<br />
<br />
Caption: The Agents Running in a Redundant Link Setup<br />
<br />
== Ground to Aircraft ==</div>Camleehttp://wiki.paparazziuav.org/w/index.php?title=Redundant_Communication&diff=14957Redundant Communication2013-04-28T00:23:05Z<p>Camlee: </p>
<hr />
<div>There is currently a pull request to integrate a redundant communication system into the existing ground segment agents: [https://github.com/paparazzi/paparazzi/pull/429]. The goal of this project is to allow multiple radio modems or other links be used between the aircraft and the ground station in a redundant fashion so that even if one link is lost, communication can be maintained. So far, the plane to ground component has been created and tested. The ground to plane component has not been created yet.<br />
<br />
===Reasons to use this===<br />
Communication from the aircraft to the ground is called telemetry. This communication allows the status of the aircraft such as location, altitude, airspeed, battery level, current flight block, and much more to be monitored in real time. Communication from the ground to the aircraft is called datalink. This communication allows the commands to be sent to the aircraft from the ground. This includes telling the aircraft what navigation to perform: waypoint navigation, search area, landing. If a single link is used, as is typical, then if the plane goes out of range, or that link is otherwise lost, no telemetry information can be displayed in the GCS and commands sent from the GCS won't be sent to the aircraft. Using the following redundant link system allows multiple links to be used in an effort to avoid this. Typically, you would introduce diversity when adding links. For example:<br />
* If you have an on-board computer, you could tunnel messages through Wi-Fi over UDP in addition to a traditional 900 MHz XBee radio modem.<br />
* You could use a satellite modem for long-range monitoring in addition to a radio modem.<br />
* You could use a cellular modem in addition to a radio modem.<br />
* With additional ground infrastructure, you could have radio modems located at different locations.<br />
* You could use radio modems at different frequencies or with different antenna gains or orientations.<br />
* You could use this system to evaluate different types of radio modems or antenna placements - you'll get real time info on each such as the ping time, received messages rate, and more information can easily be added.<br />
<br />
There are undoubtedly many more possibilities.<br />
<br />
===Compatibility===<br />
This project was made to be fully backwards compatible and support the awesome functionality that Paparazzi already has. This includes:<br />
* Completely backwards compatible - includes aircraft configuration files, previous flight logs, existing sessions, etc...<br />
* Logging and replay - if multiple links are used, data received through either link is recorded. Also, replays will include the status of each link as it was during the flight.<br />
* Link features such as USB-serial, audio, UDP, different transport layers, etc...<br />
* Multi-aircraft sessions - you can use redundant links for one aircraft, but not for another if desired<br />
* Multiple aircraft connected to the same link - such as might come up in a mesh configuration where one aircraft relays data from another aircraft<br />
<br />
<br />
== Aircraft to Ground ==<br />
<br />
===Features===<br />
Enabling redundant communication from the aircraft to the ground enables the following features:<br />
* Redundancy - as long as one link is receiving data, it will be logged and displayed on the GCS<br />
* Monitoring - the status, ping time, and rate of receiving messages for each link is shown (this makes it useful even if you're only using one link)<br />
* Alerts - new alerts are added to the console in the GCS to alert you when a link has been connected for the first time, lost, or re-gained.<br />
<br />
===How to use===<br />
<br />
For an example using two USB-serial adaptors, see the Flight USB-serial Redundant session saved in the example control_panel.xml configuration (on master branch, once the pull request has been accepted).<br />
<br />
For the details, keep reading:<br />
In order to implement redundant links using this code, there are three simple steps to follow:<br />
<br />
* Connect the hardware - on the airborne side, connect the Rx pin of the autopilot to multiple radio modems or whatever other device which will get the information to the ground. On the ground side, connect multiple modems as normal (using USB to serial adapters, a UDP connection, or whatever).<br />
* Launch a Link agent for each modem. Configure the agents as you would have before (serial port, baud rate, UDP, etc...). None of these features have been modified or removed. Then, use two new command line arguments: -redlink and -id. The -redlink flag tells Link that it's one of multiple links. The -id flag lets you specify an integer number as the id of that particular link.<br />
* Launch the Link Combiner agent. This agent listens to all of the Link agents that have their -redlink set and combines the data.<br />
<br />
The following screenshot shows a session with two links, connected to serial ports ttyUSB0 and ttyUSB1, and with id's 1 and 2:<br />
<br />
<br />
Caption: The Agents Running in a Redundant Link Setup<br />
<br />
== Ground to Aircraft ==</div>Camleehttp://wiki.paparazziuav.org/w/index.php?title=Redundant_comms&diff=14956Redundant comms2013-04-27T23:51:37Z<p>Camlee: moved Redundant comms to Redundant Communication:&#32;Want to change main title.</p>
<hr />
<div>#REDIRECT [[Redundant Communication]]</div>Camleehttp://wiki.paparazziuav.org/w/index.php?title=Redundant_Communication&diff=14955Redundant Communication2013-04-27T23:51:37Z<p>Camlee: moved Redundant comms to Redundant Communication:&#32;Want to change main title.</p>
<hr />
<div>== Redundant Communication ==<br />
There is currently a pull request to integrate a redundant communication system into the existing ground segment agents: [https://github.com/paparazzi/paparazzi/pull/429]. The goal of this project is to allow multiple radio modems or other links be used between the aircraft and the ground station in a redundant fashion so that even if one link is lost, communication can be maintained. So far, the plane to ground component has been created and tested. The ground to plane component has not been created yet.<br />
<br />
Communication from the aircraft to the ground is called telemetry. This communication allows the status of the aircraft such as location, altitude, airspeed, battery level, current flight block, and much more to be monitored in real time. Communication from the ground to the aircraft is called datalink. This communication allows the commands to be sent to the aircraft from the ground. This includes telling the aircraft what navigation to perform: waypoint navigation, search area, landing. If a single link is used, as is typical, then if the plane goes out of range, or that link is otherwise lost, no telemetry information can be displayed in the GCS and commands sent from the GCS won't be sent to the aircraft. Using the following redundant link system allows multiple links to be used in an effort to avoid this. Typically, you would introduce diversity when adding links. For example:<br />
* If you have an on-board computer, you could tunnel messages through Wi-Fi over UDP in addition to a traditional 900 MHz XBee radio modem.<br />
* You could use a satellite modem for long-range monitoring in addition to a radio modem.<br />
* You could use a cellular modem in addition to a radio modem.<br />
* With additional ground infrastructure, you could have radio modems located at different locations.<br />
* You could use radio modems at different frequencies or with different antenna gains or orientations.<br />
* You could use this system to evaluate different types of radio modems or antenna placements - you'll get real time info on each such as the ping time, received messages rate, and more information can easily be added.<br />
<br />
There are undoubtedly many more possibilities.<br />
<br />
This project was made to be fully backwards compatible and support the awesome functionality that Paparazzi already has. This includes:<br />
* Completely backwards compatible - includes aircraft configuration files, previous flight logs, existing sessions, etc...<br />
* Logging and replay - if multiple links are used, data received through either link is recorded. Also, replays will include the status of each link as it was during the flight.<br />
* Link features such as USB-serial, audio, UDP, different transport layers, etc...<br />
* Multi-aircraft sessions - you can use redundant links for one aircraft, but not for another if desired<br />
* Multiple aircraft connected to the same link - such as might come up in a mesh configuration where one aircraft relays data from another aircraft<br />
<br />
<br />
== Aircraft to Ground ==<br />
<br />
===Main Features===<br />
Enabling redundant communication from the aircraft to the ground enables the following features:<br />
* Redundancy - as long as one link is receiving data, it will be logged and displayed on the GCS<br />
* Monitoring - the status, ping time, and rate of receiving messages for each link is shown (this makes it useful even if you're only using one link)<br />
* Alerts - new alerts are added to the console in the GCS to alert you when a link has been connected for the first time, lost, or re-gained.<br />
<br />
===How to use===<br />
<br />
For an example using two USB-serial adaptors, see the Flight USB-serial Redundant session saved in the example control_panel.xml configuration (on master branch, once the pull request has been accepted).<br />
<br />
For the details, keep reading:<br />
In order to implement redundant links using this code, there are three simple steps to follow:<br />
<br />
* Connect the hardware - on the airborne side, connect the Rx pin of the autopilot to multiple radio modems or whatever other device which will get the information to the ground. On the ground side, connect multiple modems as normal (using USB to serial adapters, a UDP connection, or whatever).<br />
* Launch a Link agent for each modem. Configure the agents as you would have before (serial port, baud rate, UDP, etc...). None of these features have been modified or removed. Then, use two new command line arguments: -redlink and -id. The -redlink flag tells Link that it's one of multiple links. The -id flag lets you specify an integer number as the id of that particular link.<br />
* Launch the Link Combiner agent. This agent listens to all of the Link agents that have their -redlink set and combines the data.<br />
<br />
The following screenshot shows a session with two links, connected to serial ports ttyUSB0 and ttyUSB1, and with id's 1 and 2:<br />
<br />
http://2.bp.blogspot.com/-4ytdpqXMHa0/UXMlR-qGkbI/AAAAAAAAEZw/JO959QjWip4/s1600/Screenshot+from+2013-04-15+23_02_27.png<br />
The Agents Running in a Redundant Link Setup<br />
<br />
== Ground to Aircraft ==</div>Camleehttp://wiki.paparazziuav.org/w/index.php?title=Redundant_Communication&diff=14954Redundant Communication2013-04-27T23:50:29Z<p>Camlee: </p>
<hr />
<div>== Redundant Communication ==<br />
There is currently a pull request to integrate a redundant communication system into the existing ground segment agents: [https://github.com/paparazzi/paparazzi/pull/429]. The goal of this project is to allow multiple radio modems or other links be used between the aircraft and the ground station in a redundant fashion so that even if one link is lost, communication can be maintained. So far, the plane to ground component has been created and tested. The ground to plane component has not been created yet.<br />
<br />
Communication from the aircraft to the ground is called telemetry. This communication allows the status of the aircraft such as location, altitude, airspeed, battery level, current flight block, and much more to be monitored in real time. Communication from the ground to the aircraft is called datalink. This communication allows the commands to be sent to the aircraft from the ground. This includes telling the aircraft what navigation to perform: waypoint navigation, search area, landing. If a single link is used, as is typical, then if the plane goes out of range, or that link is otherwise lost, no telemetry information can be displayed in the GCS and commands sent from the GCS won't be sent to the aircraft. Using the following redundant link system allows multiple links to be used in an effort to avoid this. Typically, you would introduce diversity when adding links. For example:<br />
* If you have an on-board computer, you could tunnel messages through Wi-Fi over UDP in addition to a traditional 900 MHz XBee radio modem.<br />
* You could use a satellite modem for long-range monitoring in addition to a radio modem.<br />
* You could use a cellular modem in addition to a radio modem.<br />
* With additional ground infrastructure, you could have radio modems located at different locations.<br />
* You could use radio modems at different frequencies or with different antenna gains or orientations.<br />
* You could use this system to evaluate different types of radio modems or antenna placements - you'll get real time info on each such as the ping time, received messages rate, and more information can easily be added.<br />
<br />
There are undoubtedly many more possibilities.<br />
<br />
This project was made to be fully backwards compatible and support the awesome functionality that Paparazzi already has. This includes:<br />
* Completely backwards compatible - includes aircraft configuration files, previous flight logs, existing sessions, etc...<br />
* Logging and replay - if multiple links are used, data received through either link is recorded. Also, replays will include the status of each link as it was during the flight.<br />
* Link features such as USB-serial, audio, UDP, different transport layers, etc...<br />
* Multi-aircraft sessions - you can use redundant links for one aircraft, but not for another if desired<br />
* Multiple aircraft connected to the same link - such as might come up in a mesh configuration where one aircraft relays data from another aircraft<br />
<br />
<br />
== Aircraft to Ground ==<br />
<br />
===Main Features===<br />
Enabling redundant communication from the aircraft to the ground enables the following features:<br />
* Redundancy - as long as one link is receiving data, it will be logged and displayed on the GCS<br />
* Monitoring - the status, ping time, and rate of receiving messages for each link is shown (this makes it useful even if you're only using one link)<br />
* Alerts - new alerts are added to the console in the GCS to alert you when a link has been connected for the first time, lost, or re-gained.<br />
<br />
===How to use===<br />
<br />
For an example using two USB-serial adaptors, see the Flight USB-serial Redundant session saved in the example control_panel.xml configuration (on master branch, once the pull request has been accepted).<br />
<br />
For the details, keep reading:<br />
In order to implement redundant links using this code, there are three simple steps to follow:<br />
<br />
* Connect the hardware - on the airborne side, connect the Rx pin of the autopilot to multiple radio modems or whatever other device which will get the information to the ground. On the ground side, connect multiple modems as normal (using USB to serial adapters, a UDP connection, or whatever).<br />
* Launch a Link agent for each modem. Configure the agents as you would have before (serial port, baud rate, UDP, etc...). None of these features have been modified or removed. Then, use two new command line arguments: -redlink and -id. The -redlink flag tells Link that it's one of multiple links. The -id flag lets you specify an integer number as the id of that particular link.<br />
* Launch the Link Combiner agent. This agent listens to all of the Link agents that have their -redlink set and combines the data.<br />
<br />
The following screenshot shows a session with two links, connected to serial ports ttyUSB0 and ttyUSB1, and with id's 1 and 2:<br />
<br />
http://2.bp.blogspot.com/-4ytdpqXMHa0/UXMlR-qGkbI/AAAAAAAAEZw/JO959QjWip4/s1600/Screenshot+from+2013-04-15+23_02_27.png<br />
The Agents Running in a Redundant Link Setup<br />
<br />
== Ground to Aircraft ==</div>Camleehttp://wiki.paparazziuav.org/w/index.php?title=Redundant_Communication&diff=14953Redundant Communication2013-04-27T23:23:35Z<p>Camlee: </p>
<hr />
<div>== Redundant Communication ==<br />
There is currently a pull request to integrate a redundant communication system into the existing ground segment agents: [https://github.com/paparazzi/paparazzi/pull/429]. The goal of this project is to allow multiple radio modems or other links be used between the aircraft and the ground station in a redundant fashion so that even if one link is lost, communication can be maintained. So far, the plane to ground component has been created and tested. The ground to plane component has not been created yet.<br />
<br />
Communication from the aircraft to the ground is called telemetry. This communication allows the status of the aircraft such as location, altitude, airspeed, battery level, current flight block, and much more to be monitored in real time. If a single link is used, as is typical, then if the plane goes out of range, or that link is otherwise lost, none of this information can be displayed on the GCS. Using the following redundant link system allows multiple links to be used in an effort to avoid this. Typically, you would introduce diversity when adding links. For example:<br />
* If you have an on-board computer, you could tunnel messages through Wi-Fi over UDP in addition to a traditional 900 MHz XBee radio modem.<br />
* You could use a satellite phone for long-range monitoring in addition to a radio modem.<br />
* You could use a cellular modem in addition to a radio modem.<br />
* With additional ground infrastructure, you could have radio modems located at different locations.<br />
* You could use radio modems at different frequencies or with different antenna gains or orientations.<br />
<br />
There are undoubtedly many more possibilities.<br />
<br />
This project was made to be fully backwards compatible and support some of the awesome functionality that Paparazzi already has. This includes:<br />
* Completely backwards compatible - includes aircraft configuration files, previous flight logs, existing sessions, etc...<br />
* Logging and replay - if multiple links are used, data received through either link is recorded. Also, replays will include <br />
<br />
<br />
== Aircraft to Ground ==<br />
<br />
===Features===<br />
Enabling redundant communication from the aircraft to the ground enables the following features:<br />
* Redundancy - as long as one link is receiving data, it will be logged and displayed on the GCS<br />
* Monitoring - the status, ping time, and rate of receiving messages for each link is shown (this makes it useful even if you're only using one link)<br />
* Alerts - new alerts are added to the console in the GCS to alert you when a link has been connected for the first time, lost, or re-gained.<br />
<br />
<br />
===How to use===<br />
<br />
For an example session using two USB-serial adaptors, see the Flight USB-serial Redundant session saved in the example control_panel.xml configuration (on master branch, once the pull request has been accepted).<br />
<br />
For the details, keep reading:<br />
In order to implement redundant links using this code, there are three simple steps to follow:<br />
<br />
* Connect the hardware - on the airborne side, connect the Rx pin of the autopilot to multiple radio modems or whatever other device which will get the information to the ground. On the ground side, connect multiple modems as normal (using USB to serial adapters, a UDP connection, or whatever).<br />
* Launch a Link agent for each modem. Configure the agents as you would have before (serial port, baud rate, UDP, etc...). None of these features have been modified or removed. Use two new command line arguments: -redlink and -id. The -redlink flag tells Link that it's one of multiple links. The -id flag lets you specify an integer number as the id of that particular link.<br />
* Launch the Link Combiner agent. This agent listens to all of the Link agents that have their -redlink set and combines the data.<br />
<br />
The following screenshot shows a session with two links, connected to serial ports ttyUSB0 and ttyUSB1, and with id's 1 and 2:<br />
<br />
http://2.bp.blogspot.com/-4ytdpqXMHa0/UXMlR-qGkbI/AAAAAAAAEZw/JO959QjWip4/s1600/Screenshot+from+2013-04-15+23_02_27.png<br />
<br />
<br />
<br />
The Agents Running in a Redundant Link Setup<br />
<br />
== Ground to Aircraft ==</div>Camleehttp://wiki.paparazziuav.org/w/index.php?title=Redundant_Communication&diff=14952Redundant Communication2013-04-27T22:31:35Z<p>Camlee: Created page with "== Redundant Communication == There is currently a pull request to integrate a redundant communication system into the existing ground segment agents: [https://github.com/paparaz…"</p>
<hr />
<div>== Redundant Communication ==<br />
There is currently a pull request to integrate a redundant communication system into the existing ground segment agents: [https://github.com/paparazzi/paparazzi/pull/429]. The goal of this project is to allow multiple radio modems or other links be used between the aircraft and the ground station in a redundant fashion so that even if one link is lost, communication can be maintained. So far, the plane to ground component has been created and tested. The ground to plane component has not been created yet.<br />
<br />
== Plane to Ground ==<br />
<br />
<br />
<br />
===How to use===<br />
<br />
In order to implement redundant links using this code, there are three simple steps to follow:<br />
<br />
* Connect the hardware - on the airborne side, connect the Rx of the autopilot to multiple radio modems. On the ground side, connect multiple modems as normal (using USB to serial adapters, or whatever).<br />
* Launch a Link agent for each modem. Use two new command line arguments: -redlink and -id. The -redlink flag tells Link that it's one of multiple links. The -id flag lets you specify an integer number as the id of that particular link.<br />
* Launch the Link Combiner agent.<br />
<br />
The following screenshot shows a setup with two links, connected to serial ports ttyUSB0 and ttyUSB1, and with id's 1 and 2:<br />
[[File:Example.jpg]]<br />
<br />
The Agents Running in a Redundant Link Setup<br />
<br />
== Ground to Plane ==</div>Camlee