ArduPilot

This post is an explainer on the telemetry datarates in ArduPilot, plus information and data on how to configure the datarate to fit in lower-bandwidth radio systems. All datarates in this article are averages and are rounded to 1 ... [More] decimal place. Does not include actions such as downloading parameters or waypoints. All datarates are in the Vehicle → GCS direction. ArduPilot telemetry is a series of MAVLink messages output from a UART (or serial) port on the flight controller. The MAVLink messages may be a streamed message (message is emitted at some regular rate), such as the vehicle’s GPS position or hardware status. Other messages are emitted in response to a command or query from the ground station, such as downloading parameters or a confirmation of a flight mode change. The following table shows the average datarate of the default streamed messages from the different ArduPilot firmwares at the default rate of 4Hz. Note the datarate whilst the vehicle is armed is slightly higher, as additional streamed messages (such as NAV_CONTROLLER_OUTPUT) are active. The datarate will vary depending on the vehicle hardware and configuration, as additional sensors (such as a 2nd GPS) will increase the datarate. Firmware Datarate when disarmed Datarate when armed Plane 3.5 kbytes/sec 4 kbytes/sec Copter 3.5 kbytes/sec 3.7 kbytes/sec Rover 3.4 kbytes/sec 3.9 kbytes/sec On a typical 57600 baud RF telemetry radio, this equates to 59%-69% of the available radio datarate being used. If you are using a lower baud RF link, then ArduPilot’s streaming datarates may need to be trimmed down. There are several methods to do this. The easiest method is to lower the rate of the streams. By default, a GCS will ask ArduPilot to stream at 4 Hz. This can be changed in Mission Planner in Config→Planner→Telemetry Rates or in MAVProxy via the --streamrate=n commandline option. So, lowering the streamrates down to 1Hz gives the following average datarates: Firmware Datarate when disarmed Datarate when armed Plane 0.9 kbytes/sec 1.0 kbytes/sec Copter 0.9 kbytes/sec 0.9 kbytes/sec Rover 0.9 kbytes/sec 1.0 kbytes/sec Taking this further, streams can be disabled. For example, you may not want raw sensor readings or RC channel values. In that case, set the “Sensor” and “RC” streams to “0” in Mission Planner. At this time, MAVProxy does not support setting individual streamrates. If preferred, these streamrates can be set on ArduPilot instead of the GCS. The average datarates are now: Firmware Datarate when disarmed Datarate when armed Plane 0.7 kbytes/sec 0.8 kbytes/sec Copter 0.6 kbytes/sec 0.7 kbytes/sec Rover 0.6 kbytes/sec 0.8 kbytes/sec If finer grained control of which MAVLink messages are streamed is desired, the individual messages and rates can be controlled. There are a few methods for doing this. For this example, a file containing the message ID’s and rate (in milliseconds) is placed in the SD card’s root directory: message-intervals-chan0.txt 33 200 1 1000 74 2000 The above file tells ArduPilot that chan0 should stream message 33 (GLOBAL_POSITION_INT) at 5 Hz, message 1 (SYS_STATUS) at 1 Hz and message 74 (VFR_HUD) at 0.5 Hz. This gives basic information of the vehicle’s state and position. Using this file, the telemetry datarate is lowered to 0.3 kbyte/sec. This sort of datarate would be suitable for radios operating at 2400 baud and above. If you are working with very low datarate radios (<100 bytes/sec), you may wish to lower the datarate even further. For this, the new “MAVLinkHL” serial protocol option will be of interest. MAVLinkHL is an implementation of the High Latency MAVLink protocol and is designed primarily for low datarate satellite systems (such as SBD modems, such as Iridium Short Burst Data (SBD) | Iridium Satellite Communications). This protocol sends out a HIGH_LATENCY2 MAVLink message at 0.2 Hz (by default) in place of a HEARTBEAT packet. The HIGH_LATENCY2 message contains a summary of the vehicle’s state and status in a single message, replacing the need to stream multiple different messages to get similar information. To use High Latency MAVLink, set the relevant SERIALn_PROTOCOL to 43. By default, this connection does not stream any data. It needs to be activated first. In MAVProxy, this can be done via the link hl on|off commands. Otherwise, the message can be requested via the MAV_CMD_CONTROL_HIGH_LATENCY or SET_MESSAGE_INTERVAL commands. The MAV_CMD_CONTROL_HIGH_LATENCY command can be sent over any link to ArduPilot – it does not need to be sent via the High Latency link. Via this method, the telemetry datarate is reduced to 0.01 kbyte/sec! So, for those running low datarate modems or radio systems, ArduPilot has a number of tools to reduce the telemetry datarate. This includes lowering the frequency of message updates and not sending less-useful messages. EDIT: For those interested in exploring the different message data throughputs, there is an excellent tool in the pymavlink repository: pymavlink/mavtelemetry_datarates.py at master · ArduPilot/pymavlink · GitHub 5 posts - 3 participants Read full topic [Less]

This short tutorial shows how RPanion, Amazon Web Services and AP_Cloud can be used to upload onboard log files (aka “dataflash logs”) from an ArduPilot flight controller to an AWS server and then process them using AP_Cloud. For this ... [More] test I used the following hardware CubeOrange flight controller running ArduPilot Rover-4.2 (but any ArduPilot compatible autopilot running any recent version of AP should work) RPI4 (but should also work with Raspberry Pi 2, 3, 4, Zero2 and Jetson) Pi-Connect Lite to make connecting the RPI to the autopilot easy ArduPilot configuration The ArduPilot changes enable sending the onboard logs (aka dataflash logs) to the companion computer in real-time (via MAVLink). set SERIALx_BAUD = 921 (or even 1500) to enable highspeed mavlink communication with the companion computer (“x” is the telemetry port number connected to the RPanion) set LOG_BACKEND_TYPE = 3 (File+Mavlink) to enable sending the onboard log file to the companion computer in real time via MAVLink RPanion setup In this step we install RPanion on the RPI4, configure the connection to the autopilot and confirm the autopilot->RPI4 log transfer is working. Install RPanion ver 0.9 (or higher) using the instructions here Power-up the autopilot and RPanion and connect to the RPanion web server the easiest way is to connect to the “rpanion” wifi access point and then open http://10.0.2.100:3000/ another alternative is to plug in an ethernet cable and use your local network router’s interface to determine the RPI’s IP address and then use a modified version of the address linked directly above. On the FlightController page’s Serial Input section set the Baud field to 921600 (or 1500000) to match the autopilot and MAVLink version to 2.0 Reboot the autopilot and RPanion and then confirm the logs are uploading correctly and arming and then disarming the vehicle (or set LOG_DISARMED = 1, wait a few seconds and then reset to 0) and then check a new log appears on the RPanion’s FlightLogs screen’s Bin Logs section. Next we use Putty or another SSH client to generate a keypair which is used later to allow the RPanion to upload to the AWS server Open Putty and connect to 10.0.2.100 using SSH When the login appears, provide username/pwd pi/raspberry cd .ssh cat id_rsa.pub and copy and paste the contents to a text file on your local PC (this will be used later to allow the RPanion to SSH to the AWS server) AWS setup In this step we configure an AWS server to receive the log files from RPanion Create a AWS account by pushing on the Create a Free Account button here. Select the “Root User” option Open the AWS Console Home, select “Launch a virtual machine With EC2 (2 mins)” select “Ubuntu Server 20.04 LTS” push “Create new key pair” and save the .ppk or .pem file to your local PC in case you later which to connect to the server from Putty or similar terminal application (these instructions do not require this key) In Network settings, enable SSH (to allow RPanion to upload logs) and HTTP traffic (used later by AP_Cloud’s web server) push the “Launch Instance” button From the AWS Console, select Instances, look for the “Public IPv4 address” column which holds the server’s IP address From the same screen, start EC2 Connect by checking the checkbox for the server and press Connect and Connect again. type “mkdir logs” to create a directory where the logs will be stored type “cd .ssh” “vi authorized_keys” and then “i” and Ctrl-v to paste in the rpanion’s public key captured in the “RPanion setup” stage. press “wq” to exit vi and then close the window. This allows the RPanion to connect to the AWS server Enable RPanion’s Cloud Upload First we manually check that SSH to the AWS server works On your local PC, open Putty (or similar) and connect to the Rpanion (e.g. 10.0.2.100 using SSH) When the login appears, provide username/pwd pi/raspberry In the console type “ssh [email protected]” where the Xs are replaced with the AWS server’s IP address Reply “yes” is asked about “The authenticity of host can’t be established” If it successfully connects this confirms the RPanion can connect so type “exit” (or just close the window) Configure “Cloud Upload” Open RPanion’s web interface (http://10.0.2.100:3000/) On the Cloud Upload screen, in the “AP:Cloud Rsync” field enter [email protected]:/home/ubuntu (where “x.x.x.x” is the AWS server’s IP address and press “Enable”. After a few minutes “Success” should be displayed If after a few minutes “Status: Success” is displayed then you can be confident that the upload has worked but if you wish you may double check using the AWS’s EC2 Connect feature and type “ls logs” and confirm the files are there. Install AP Cloud on AWS server AP Cloud installation instructions can be found here but more specific and verified instructions are as follows Connect using EC2 Connect by going to the AWS Console, select Instances, check the checkbox for the server, press Connect and Connect again Install MAVProxy (see instructions here) sudo apt-get update sudo apt-get install python3-dev python3-opencv python3-wxgtk4.0 python3-pip python3-matplotlib python3-lxml python3-pygame pip3 install PyYAML mavproxy --user echo "export PATH=$PATH:$HOME/.local/bin" >> ~/.bashrc source ~/.bashrc Install nvm (see instructions here) curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.1/install.sh | bash source ~/.bashrc" nvm install 12 nvm use 12 node -v (should return v12.22.10 or higher) npm install Allow Node.js webserver on port 80 without running as root (see here) whereis node sudo setcap 'cap_net_bind_service=+ep' /usr/local/bin/node (Note: change final path with output from “whereis node” line above) Install and run AP_Cloud cd ~ git clone https://github.com/ArduPilot/AP_Cloud.git cd AP_Cloud with your favourite editor modify AP_Cloud/config/default.json and change “port” to 80 (was 8123) source ~/.bashrc" node index.js Change RPanion’s Cloud upload location Open RPanion’s web interface (http://10.0.2.100:3000/) On the Cloud Upload screen, in the “AP:Cloud Rsync” field enter [email protected]:/home/ubuntu/AP_Cloud/logs/drone1 (where “x.x.x.x” is the AWS server’s IP address Open AP_Cloud by opening a browser on your local PC and type the AWS server’s IP address into the address bar. Click on “drone1” to see meta data extracted from the logs and a link (on the far right) to download each log. Thanks very much to @DavidBuzz and @stephendade for their work on AP Cloud and RPanion respectively! 1 post - 1 participant Read full topic [Less]

This short tutorial shows how RPanion, Amazon Web Services and AP_Cloud can be used to upload onboard log files (aka “dataflash logs”) from an ArduPilot flight controller to an AWS server and then process them using AP_Cloud. For this ... [More] test I used the following hardware CubeOrange flight controller running ArduPilot Rover-4.2 (but any ArduPilot compatible autopilot running any recent version of AP should work) RPI4 (but should also work with Raspberry Pi 2, 3, 4, Zero2 and Jetson) Pi-Connect Lite to make connecting the RPI to the autopilot easy ArduPilot configuration The ArduPilot changes enable sending the onboard logs (aka dataflash logs) to the companion computer in real-time (via MAVLink). set SERIALx_BAUD = 921 (or even 1500) to enable highspeed mavlink communication with the companion computer (“x” is the telemetry port number connected to the RPanion) set LOG_BACKEND_TYPE = 3 (File+Mavlink) to enable sending the onboard log file to the companion computer in real time via MAVLink RPanion setup In this step we install RPanion on the RPI4, configure the connection to the autopilot and confirm the autopilot->RPI4 log transfer is working. Install RPanion ver 0.9 (or higher) using the instructions here Power-up the autopilot and RPanion and connect to the RPanion web server the easiest way is to connect to the “rpanion” wifi access point and then open http://10.0.2.100:3000/ another alternative is to plug in an ethernet cable and use your local network router’s interface to determine the RPI’s IP address and then use a modified version of the address linked directly above. On the FlightController page’s Serial Input section set the Baud field to 921600 (or 1500000) to match the autopilot and MAVLink version to 2.0 Reboot the autopilot and RPanion and then confirm the logs are uploading correctly and arming and then disarming the vehicle (or set LOG_DISARMED = 1, wait a few seconds and then reset to 0) and then check a new log appears on the RPanion’s FlightLogs screen’s Bin Logs section. Next we use Putty or another SSH client to generate a keypair which is used later to allow the RPanion to upload to the AWS server Open Putty and connect to 10.0.2.100 using SSH When the login appears, provide username/pwd pi/raspberry cd .ssh cat id_rsa.pub and copy and paste the contents to a text file on your local PC (this will be used later to allow the RPanion to SSH to the AWS server) AWS setup In this step we configure an AWS server to receive the log files from RPanion Create a AWS account by pushing on the Create a Free Account button here. Select the “Root User” option Open the AWS Console Home, select “Launch a virtual machine With EC2 (2 mins)” select “Ubuntu Server 20.04 LTS” push “Create new key pair” and save the .ppk or .pem file to your local PC in case you later which to connect to the server from Putty or similar terminal application (these instructions do not require this key) In Network settings, enable SSH (to allow RPanion to upload logs) and HTTP traffic (used later by AP_Cloud’s web server) push the “Launch Instance” button From the AWS Console, select Instances, look for the “Public IPv4 address” column which holds the server’s IP address From the same screen, start EC2 Connect by checking the checkbox for the server and press Connect and Connect again. type “mkdir logs” to create a directory where the logs will be stored type “cd .ssh” “vi authorized_keys” and then “i” and Ctrl-v to paste in the rpanion’s public key captured in the “RPanion setup” stage. press “wq” to exit vi and then close the window. This allows the RPanion to connect to the AWS server Enable RPanion’s Cloud Upload First we manually check that SSH to the AWS server works On your local PC, open Putty (or similar) and connect to the Rpanion (e.g. 10.0.2.100 using SSH) When the login appears, provide username/pwd pi/raspberry In the console type “ssh [email protected]” where the Xs are replaced with the AWS server’s IP address Reply “yes” is asked about “The authenticity of host can’t be established” If it successfully connects this confirms the RPanion can connect so type “exit” (or just close the window) Configure “Cloud Upload” Open RPanion’s web interface (http://10.0.2.100:3000/) On the Cloud Upload screen, in the “AP:Cloud Rsync” field enter [email protected]:/home/ubuntu (where “x.x.x.x” is the AWS server’s IP address and press “Enable”. After a few minutes “Success” should be displayed If after a few minutes “Status: Success” is displayed then you can be confident that the upload has worked but if you wish you may double check using the AWS’s EC2 Connect feature and type “ls logs” and confirm the files are there. Install AP Cloud on AWS server AP Cloud installation instructions can be found here but more specific and verified instructions are as follows Connect using EC2 Connect by going to the AWS Console, select Instances, check the checkbox for the server, press Connect and Connect again Install MAVProxy (see instructions here) sudo apt-get update sudo apt-get install python3-dev python3-opencv python3-wxgtk4.0 python3-pip python3-matplotlib python3-lxml python3-pygame pip3 install PyYAML mavproxy --user echo "export PATH=$PATH:$HOME/.local/bin" >> ~/.bashrc source ~/.bashrc Install nvm (see instructions here) curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.1/install.sh | bash export NVM_DIR="$([ -z "${XDG_CONFIG_HOME-}" ] && printf %s "${HOME}/.nvm" || printf %s "${XDG_CONFIG_HOME}/nvm")" [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" nvm install 12 nvm use 12 node -v (should return v12.22.10 or higher) npm install Allow Node.js webserver on port 80 without running as root (see here) whereis node sudo setcap 'cap_net_bind_service=+ep' /usr/local/bin/node (Note: change final path with output from “whereis node” line above) Install and run AP_Cloud cd ~ git clone https://github.com/ArduPilot/AP_Cloud.git cd AP_Cloud with your favourite editor modify AP_Cloud/config/default.json and change “port” to 80 (was 8123) node index.js Change RPanion’s Cloud upload location Open RPanion’s web interface (http://10.0.2.100:3000/) On the Cloud Upload screen, in the “AP:Cloud Rsync” field enter [email protected]:/home/ubuntu/AP_Cloud/logs/drone1 (where “x.x.x.x” is the AWS server’s IP address Open AP_Cloud by opening a browser on your local PC and type the AWS server’s IP address into the address bar. Click on “drone1” to see meta data extracted from the logs and a link (on the far right) to download each log. Thanks very much to @DavidBuzz and @stephendade for their work on AP Cloud and RPanion respectively! 1 post - 1 participant Read full topic [Less]

Here are the slides from the Mar 2022 monthly report presented by Tridge, Randy and a few others at this month’s Partners call. BTW, the image on the left is an OMP ZMO airframe and there is a discussion here on how to convert it to use ... [More] ArduPilot. The image on the right from a test I did with AttracLab last week to test hexacopter motor failures. It was a very successful test with the vehicle only rotating about 180 degrees but otherwise maintaining full control. This was done with Copter-4.1.5. Thanks very much to our Partners for their support and engagement! 1 post - 1 participant Read full topic [Less]

MAVLink routing on Companion Computers. One of the strengths of ArduPilot is that we rely on the standardized MAVLink protocol for our telemetry. As our drones gain more capabilities, companion computers are often used with many ... [More] separate pieces of software that need to have access to the flight controller data. A common approach to do this is to use MAVProxy, the ArduPilot developer’s main Ground Control Station. MAVProxy relies on a module based approach that allows it to have numerous capabilities, can serve as a MAVLink message router between multiple components and implement the routing of MAVLink messages according to Mavlink routing protocol. Routing components with MAVProxy is simple: we need a --master endpoint to connect to the autopilot and then we can setup as many output endpoints (--out) as we want. This approach is simple to set up but has some costs. MAVProxy, is a fully featured ground control station and not a sole message router. Using the default startup options consumes a lot of resources, and defaults to loading numerous modules. You can see those default modules at the MAVProxy prompt, (a prompt that shouldn’t exist for a simple routing feature…), by typing module list : STABILIZE> adsb: ADS-B data support arm: arm/disarm handling auxopt: auxopt command handling battery: battery commands calibration: calibration handling cmdlong: cmdlong handling console: GUI console fence: geo-fence management ftp: ftp handling layout: window layout handling link: link control log: log transfer map: map display misc: misc commands mode: mode handling output: output control param: parameter handling rally: rally point control rc: rc command handling relay: relay handling signing: signing control terrain: terrain handling tuneopt: tuneopt command handling wp: waypoint handling How can we make this better? Solution 1 : Clean up MAVProxy! First, launch MAVProxy as a deamon with --deamon that removes the interactive shell. Next, you want just routing, so the only module you need is link. This module will allow you to set as many outputs you want on launch. Secondly, MAVProxy should be configured to stop adjusting telemetry rates… You may have noticed that MAVProxy and all Mavlink GCS, automatically request data from the Autopilot. This comes from a special routine that will regularly set the telemetry stream rates: the frequency the autopilot should send a defined group of messages. This feature is convenient for a GCS but not for your MAVLink router as it will fight against other software on the same link. For example, if you have MAVProxy connected to the Autopilot and a companion computer connected to MAVProxy, if you ask with the companion computer to have the IMU message at 50Hz, after a few seconds the IMU message will stop coming at 50Hz and revert to 4Hz as MAVProxy will have reset it. Thankfully, MAVProxy has an option to disable this behavior, like most GCS. For MissionPlanner, it is in Planner configuration options. Your new MAVProxy command line will be something like: mavproxy.py --master=tcp:localhost:5762 --daemon --default-modules "link" --streamrate -1 --out 0.0.0.0:14552 --out 0.0.0.0:14553 --master for the autopilot link --daemon for not have interactive shell --default-modules "link" to keep only the ability to set outputs. --streamrate -1 to disable messages control from MAVProxy --out 0.0.0.0:14552 to set new output Now you have a clean router for your Mavlink messages. Solution 2: Use another software that just do MAVLink routing : mavlink-router This is small C-based software that mostly only does MAVLink routing. It can do the routing of Mavlink messages according to MAVLink routing protocol, do messages filtering and sniffing, and lastly it has a logger system. Compared to MAVProxy it is very lightweight both in size and CPU usage. However, it is optimized for routing and has limited other capabilities. If you have multiple pieces of software that need access to the autopilot data stream, mavlink-router is one of the most used options. Solution 3: Use some Linux tools. These aren’t dealing with MAVLink specifically, but can still be used to push MAVLink messages through IP networks. Two are well known: socat : https://linux.die.net/man/1/socat ser2net : https://linux.die.net/man/8/ser2net Both allow you to create a serial connection to the autopilot and link it to an IP network. Solution 4: Use [mavlink-hub.py] (https://github.com/peterbarker/mavlink_hub). This is another packet-distributor based on pymavlink; it has no routing capabilities and simply sends any packets received on any of its links to each of the other links. Lighter-weight than MAVProxy and written in portable Python, and thus heavier on resources than mavlink-router. Solution to avoid : MAVROS MAVROS is a great piece of software but it serves its purpose at linking ONE and only ONE MAVLink system (one autopilot for example) to ROS. It has some routing capabilities to relay messages but considering the heaviness of a ROS deployment, you shouldn’t use it for routing and especially if you don’t need to use other ROS tools. Prefer mavlink-router or even MAVProxy that are much simpler to maintain and efficient for routing. MAVLink routing protocol The Mavlink routing protocol defines how a MAVLink message should be delivered when a target is settled. It can be resumed by the two following pictures. With MAVLink routing prototocl Without MAVlink routing protocol Do you know some other solutions ? Let’s us know ! 11 posts - 5 participants Read full topic [Less]

MAVLink routing on Companion Computers. One of the strengths of ArduPilot is that we rely on the standardized MAVLink protocol for our telemetry. As our drones gain more capabilities, companion computers are often used with many ... [More] separate pieces of software that need to have access to the flight controller data. A common approach to do this is to use MAVProxy, the ArduPilot developer’s main Ground Control Station. MAVProxy relies on a module based approach that allows it to have numerous capabilities, can serve as a MAVLink message router between multiple components and implement the routing of MAVLink messages according to Mavlink routing protocol. Routing components with MAVProxy is simple: we need a --master endpoint to connect to the autopilot and then we can setup as many output endpoints (--out) as we want. This approach is simple to set up but has some costs. MAVProxy, is a fully featured ground control station and not a sole message router. Using the default startup options consumes a lot of resources, and defaults to loading numerous modules. You can see those default modules at the MAVProxy prompt, (a prompt that shouldn’t exist for a simple routing feature…), by typing module list : STABILIZE> adsb: ADS-B data support arm: arm/disarm handling auxopt: auxopt command handling battery: battery commands calibration: calibration handling cmdlong: cmdlong handling console: GUI console fence: geo-fence management ftp: ftp handling layout: window layout handling link: link control log: log transfer map: map display misc: misc commands mode: mode handling output: output control param: parameter handling rally: rally point control rc: rc command handling relay: relay handling signing: signing control terrain: terrain handling tuneopt: tuneopt command handling wp: waypoint handling How can we make this better? Solution 1 : Clean up MAVProxy! First, launch MAVProxy as a deamon with --deamon that removes the interactive shell. Next, you want just routing, so the only module you need is link. This module will allow you to set as many outputs you want on launch. Secondly, MAVProxy should be configured to stop adjusting telemetry rates… You may have noticed that MAVProxy and all Mavlink GCS, automatically request data from the Autopilot. This comes from a special routine that will regularly set the telemetry stream rates: the frequency the autopilot should send a defined group of messages. This feature is convenient for a GCS but not for your MAVLink router as it will fight against other software on the same link. For example, if you have MAVProxy connected to the Autopilot and a companion computer connected to MAVProxy, if you ask with the companion computer to have the IMU message at 50Hz, after a few seconds the IMU message will stop coming at 50Hz and revert to 4Hz as MAVProxy will have reset it. Thankfully, MAVProxy has an option to disable this behavior, like most GCS. For MissionPlanner, it is in Planner configuration options. Your new MAVProxy command line will be something like: mavproxy.py --master=tcp:localhost:5762 --daemon --default-modules "link" --streamrate -1 --out 0.0.0.0:14552 --out 0.0.0.0:14553 --master for the autopilot link --daemon for not have interactive shell --default-modules "link" to keep only the ability to set outputs. --streamrate -1 to disable messages control from MAVProxy --out 0.0.0.0:14552 to set new output Now you have a clean router for your Mavlink messages. Solution 2: Use another software that just do MAVLink routing : mavlink-router This is small C-based software that mostly only does MAVLink routing. It can do the routing of Mavlink messages according to MAVLink routing protocol, do messages filtering and sniffing, and lastly it has a logger system. Compared to MAVProxy it is very lightweight both in size and CPU usage. However, it is optimized for routing and has limited other capabilities. If you have multiple pieces of software that need access to the autopilot data stream, mavlink-router is one of the most used options. Solution 3: Use some Linux tools. These aren’t dealing with MAVLink specifically, but can still be used to push MAVLink messages through IP networks. Two are well known: socat : https://linux.die.net/man/1/socat ser2net : https://linux.die.net/man/8/ser2net Both allow you to create a serial connection to the autopilot and link it to an IP network. Solution 4: Use [mavlink-hub.py] (https://github.com/peterbarker/mavlink_hub). This is another packet-distributor based on pymavlink; it has no routing capabilities and simply sends any packets received on any of its links to each of the other links. Lighter-weight than MAVProxy and written in portable Python, and thus heavier on resources than mavlink-router. Solution to avoid : MAVROS MAVROS is a great piece of software but it serves its purpose at linking ONE and only ONE MAVLink system (one autopilot for example) to ROS. It has some routing capabilities to relay messages but considering the heaviness of a ROS deployment, you shouldn’t use it for routing and especially if you don’t need to use other ROS tools. Prefer mavlink-router or even MAVProxy that are much simpler to maintain and efficient for routing. MAVLink routing protocol The Mavlink routing protocol defines how a MAVLink message should be delivered when a target is settled. It can be resumed by the two following pictures. With MAVLink routing prototocl Without MAVlink routing protocol Do you know some other solutions ? Let’s us know ! 12 posts - 6 participants Read full topic [Less]

MAVLink routing on Companion Computers. One of the strengths of ArduPilot is that we rely on the standardized MAVLink protocol for our telemetry. As our drones gain more capabilities, companion computers are often used with many ... [More] separate pieces of software that need to have access to the flight controller data. A common approach to do this is to use MAVProxy, the ArduPilot developer’s main Ground Control Station. MAVProxy relies on a module based approach that allows it to have numerous capabilities, can serve as a MAVLink message router between multiple components and implement the routing of MAVLink messages according to Mavlink routing protocol. Routing components with MAVProxy is simple: we need a --master endpoint to connect to the autopilot and then we can setup as many output endpoints (--out) as we want. This approach is simple to set up but has some costs. MAVProxy, is a fully featured ground control station and not a sole message router. Using the default startup options consumes a lot of resources, and defaults to loading numerous modules. You can see those default modules at the MAVProxy prompt, (a prompt that shouldn’t exist for a simple routing feature…), by typing module list : STABILIZE> adsb: ADS-B data support arm: arm/disarm handling auxopt: auxopt command handling battery: battery commands calibration: calibration handling cmdlong: cmdlong handling console: GUI console fence: geo-fence management ftp: ftp handling layout: window layout handling link: link control log: log transfer map: map display misc: misc commands mode: mode handling output: output control param: parameter handling rally: rally point control rc: rc command handling relay: relay handling signing: signing control terrain: terrain handling tuneopt: tuneopt command handling wp: waypoint handling How can we make this better? Solution 1 : Clean up MAVProxy! First, launch MAVProxy as a deamon with --deamon that removes the interactive shell. Next, you want just routing, so the only module you need is link. This module will allow you to set as many outputs you want on launch. Secondly, MAVProxy should be configured to stop adjusting telemetry rates… You may have noticed that MAVProxy and all Mavlink GCS, automatically request data from the Autopilot. This comes from a special routine that will regularly set the telemetry stream rates: the frequency the autopilot should send a defined group of messages. This feature is convenient for a GCS but not for your MAVLink router as it will fight against other software on the same link. For example, if you have MAVProxy connected to the Autopilot and a companion computer connected to MAVProxy, if you ask with the companion computer to have the IMU message at 50Hz, after a few seconds the IMU message will stop coming at 50Hz and revert to 4Hz as MAVProxy will have reset it. Thankfully, MAVProxy has an option to disable this behavior, like most GCS. For MissionPlanner, it is in Planner configuration options. Your new MAVProxy command line will be something like: mavproxy.py --master=tcp:localhost:5762 --daemon --default-modules "link" --streamrate -1 --out 0.0.0.0:14552 --out 0.0.0.0:14553 --master for the autopilot link --daemon for not have interactive shell --default-modules "link" to keep only the ability to set outputs. --streamrate -1 to disable messages control from MAVProxy --out 0.0.0.0:14552 to set new output Now you have a clean router for your Mavlink messages. Solution 2: Use another software that just do MAVLink routing : mavlink-router This is small C-based software that mostly only does MAVLink routing. It can do the routing of Mavlink messages according to MAVLink routing protocol, do messages filtering and sniffing, and lastly it has a logger system. Compared to MAVProxy it is very lightweight both in size and CPU usage. However, it is optimized for routing and has limited other capabilities. If you have multiple pieces of software that need access to the autopilot data stream, mavlink-router is one of the most used options. Solution 3: Use some Linux tools. These aren’t dealing with MAVLink specifically, but can still be used to push MAVLink messages through IP networks. Two are well known: socat : https://linux.die.net/man/1/socat ser2net : https://linux.die.net/man/8/ser2net Both allow you to create a serial connection to the autopilot and link it to an IP network. Solution 4: Use [mavlink-hub.py] (https://github.com/peterbarker/mavlink_hub). This is another packet-distributor based on pymavlink; it has no routing capabilities and simply sends any packets received on any of its links to each of the other links. Lighter-weight than MAVProxy and written in portable Python, and thus heavier on resources than mavlink-router. Solution to avoid : MAVROS MAVROS is a great piece of software but it serves its purpose at linking ONE and only ONE MAVLink system (one autopilot for example) to ROS. It has some routing capabilities to relay messages but considering the heaviness of a ROS deployment, you shouldn’t use it for routing and especially if you don’t need to use other ROS tools. Prefer mavlink-router or even MAVProxy that are much simpler to maintain and efficient for routing. MAVLink routing protocol The Mavlink routing protocol defines how a MAVLink message should be delivered when a target is settled. It can be resumed by the two following pictures. With MAVLink routing prototocl Without MAVlink routing protocol Do you know some other solutions ? Let’s us know ! 14 posts - 7 participants Read full topic [Less]

MAVLink routing on Companion Computers. One of the strengths of ArduPilot is that we rely on the standardized MAVLink protocol for our telemetry. As our drones gain more capabilities, companion computers are often used with many ... [More] separate pieces of software that need to have access to the flight controller data. A common approach to do this is to use MAVProxy, the ArduPilot developer’s main Ground Control Station. MAVProxy relies on a module based approach that allows it to have numerous capabilities, can serve as a MAVLink message router between multiple components and implement the routing of MAVLink messages according to Mavlink routing protocol. Routing components with MAVProxy is simple: we need a --master endpoint to connect to the autopilot and then we can setup as many output endpoints (--out) as we want. This approach is simple to set up but has some costs. MAVProxy, is a fully featured ground control station and not a sole message router. Using the default startup options consumes a lot of resources, and defaults to loading numerous modules. You can see those default modules at the MAVProxy prompt, (a prompt that shouldn’t exist for a simple routing feature…), by typing module list : STABILIZE> adsb: ADS-B data support arm: arm/disarm handling auxopt: auxopt command handling battery: battery commands calibration: calibration handling cmdlong: cmdlong handling console: GUI console fence: geo-fence management ftp: ftp handling layout: window layout handling link: link control log: log transfer map: map display misc: misc commands mode: mode handling output: output control param: parameter handling rally: rally point control rc: rc command handling relay: relay handling signing: signing control terrain: terrain handling tuneopt: tuneopt command handling wp: waypoint handling How can we make this better? Solution 1 : Clean up MAVProxy! First, launch MAVProxy as a deamon with --deamon that removes the interactive shell. Next, you want just routing, so the only module you need is link. This module will allow you to set as many outputs you want on launch. Secondly, MAVProxy should be configured to stop adjusting telemetry rates… You may have noticed that MAVProxy and all Mavlink GCS, automatically request data from the Autopilot. This comes from a special routine that will regularly set the telemetry stream rates: the frequency the autopilot should send a defined group of messages. This feature is convenient for a GCS but not for your MAVLink router as it will fight against other software on the same link. For example, if you have MAVProxy connected to the Autopilot and a companion computer connected to MAVProxy, if you ask with the companion computer to have the IMU message at 50Hz, after a few seconds the IMU message will stop coming at 50Hz and revert to 4Hz as MAVProxy will have reset it. Thankfully, MAVProxy has an option to disable this behavior, like most GCS. For MissionPlanner, it is in Planner configuration options. Your new MAVProxy command line will be something like: mavproxy.py --master=tcp:localhost:5762 --daemon --default-modules "link" --streamrate -1 --out 0.0.0.0:14552 --out 0.0.0.0:14553 --master for the autopilot link --daemon for not have interactive shell --default-modules "link" to keep only the ability to set outputs. --streamrate -1 to disable messages control from MAVProxy --out 0.0.0.0:14552 to set new output Now you have a clean router for your Mavlink messages. Solution 2: Use another software that just do MAVLink routing : mavlink-router This is small C-based software that mostly only does MAVLink routing. It can do the routing of Mavlink messages according to MAVLink routing protocol, do messages filtering and sniffing, and lastly it has a logger system. Compared to MAVProxy it is very lightweight both in size and CPU usage. However, it is optimized for routing and has limited other capabilities. If you have multiple pieces of software that need access to the autopilot data stream, mavlink-router is one of the most used options. Solution 3: Use some Linux tools. These aren’t dealing with MAVLink specifically, but can still be used to push MAVLink messages through IP networks. Two are well known: socat : https://linux.die.net/man/1/socat ser2net : https://linux.die.net/man/8/ser2net Both allow you to create a serial connection to the autopilot and link it to an IP network. Solution 4: Use [mavlink-hub.py] (https://github.com/peterbarker/mavlink_hub). This is another packet-distributor based on pymavlink; it has no routing capabilities and simply sends any packets received on any of its links to each of the other links. Lighter-weight than MAVProxy and written in portable Python, and thus heavier on resources than mavlink-router. Solution to avoid : MAVROS MAVROS is a great piece of software but it serves its purpose at linking ONE and only ONE MAVLink system (one autopilot for example) to ROS. It has some routing capabilities to relay messages but considering the heaviness of a ROS deployment, you shouldn’t use it for routing and especially if you don’t need to use other ROS tools. Prefer mavlink-router or even MAVProxy that are much simpler to maintain and efficient for routing. MAVLink routing protocol The Mavlink routing protocol defines how a MAVLink message should be delivered when a target is settled. It can be resumed by the two following pictures. With MAVLink routing prototocl Without MAVlink routing protocol Do you know some other solutions ? Let’s us know ! 13 posts - 6 participants Read full topic [Less]

MAVLink routing on Companion Computers. One of the strengths of ArduPilot is that we rely on the standardized MAVLink protocol for our telemetry. As our drones gain more capabilities, companion computers are often used with many ... [More] separate pieces of software that need to have access to the flight controller data. A common approach to do this is to use MAVProxy, the ArduPilot developer’s main Ground Control Station. MAVProxy relies on a module based approach that allows it to have numerous capabilities, can serve as a MAVLink message router between multiple components and implement the routing of MAVLink messages according to Mavlink routing protocol. Routing components with MAVProxy is simple: we need a --master endpoint to connect to the autopilot and then we can setup as many output endpoints (--out) as we want. This approach is simple to set up but has some costs. MAVProxy, is a fully featured ground control station and not a sole message router. Using the default startup options consumes a lot of resources, and defaults to loading numerous modules. You can see those default modules at the MAVProxy prompt, (a prompt that shouldn’t exist for a simple routing feature…), by typing module list : STABILIZE> adsb: ADS-B data support arm: arm/disarm handling auxopt: auxopt command handling battery: battery commands calibration: calibration handling cmdlong: cmdlong handling console: GUI console fence: geo-fence management ftp: ftp handling layout: window layout handling link: link control log: log transfer map: map display misc: misc commands mode: mode handling output: output control param: parameter handling rally: rally point control rc: rc command handling relay: relay handling signing: signing control terrain: terrain handling tuneopt: tuneopt command handling wp: waypoint handling How can we make this better? Solution 1 : Clean up MAVProxy! First, launch MAVProxy as a deamon with --deamon that removes the interactive shell. Next, you want just routing, so the only module you need is link. This module will allow you to set as many outputs you want on launch. Secondly, MAVProxy should be configured to stop adjusting telemetry rates… You may have noticed that MAVProxy and all Mavlink GCS, automatically request data from the Autopilot. This comes from a special routine that will regularly set the telemetry stream rates: the frequency the autopilot should send a defined group of messages. This feature is convenient for a GCS but not for your MAVLink router as it will fight against other software on the same link. For example, if you have MAVProxy connected to the Autopilot and a companion computer connected to MAVProxy, if you ask with the companion computer to have the IMU message at 50Hz, after a few seconds the IMU message will stop coming at 50Hz and revert to 4Hz as MAVProxy will have reset it. Thankfully, MAVProxy has an option to disable this behavior, like most GCS. For MissionPlanner, it is in Planner configuration options. Your new MAVProxy command line will be something like: mavproxy.py --master=tcp:localhost:5762 --daemon --default-modules "link" --streamrate -1 --out 0.0.0.0:14552 --out 0.0.0.0:14553 --master for the autopilot link --daemon for not have interactive shell --default-modules "link" to keep only the ability to set outputs. --streamrate -1 to disable messages control from MAVProxy --out 0.0.0.0:14552 to set new output Now you have a clean router for your Mavlink messages. Solution 2: Use another software that just do MAVLink routing : mavlink-router This is small C-based software that mostly only does MAVLink routing. It can do the routing of Mavlink messages according to MAVLink routing protocol, do messages filtering and sniffing, and lastly it has a logger system. Compared to MAVProxy it is very lightweight both in size and CPU usage. However, it is optimized for routing and has limited other capabilities. If you have multiple pieces of software that need access to the autopilot data stream, mavlink-router is one of the most used options. Solution 3: Use some Linux tools. These aren’t dealing with MAVLink specifically, but can still be used to push MAVLink messages through IP networks. Two are well known: socat : https://linux.die.net/man/1/socat ser2net : https://linux.die.net/man/8/ser2net Both allow you to create a serial connection to the autopilot and link it to an IP network. Solution 4: Use [mavlink-hub.py] (https://github.com/peterbarker/mavlink_hub). This is another packet-distributor based on pymavlink; it has no routing capabilities and simply sends any packets received on any of its links to each of the other links. Lighter-weight than MAVProxy and written in portable Python, and thus heavier on resources than mavlink-router. Solution to avoid : MAVROS MAVROS is a great piece of software but it serves its purpose at linking ONE and only ONE MAVLink system (one autopilot for example) to ROS. It has some routing capabilities to relay messages but considering the heaviness of a ROS deployment, you shouldn’t use it for routing and especially if you don’t need to use other ROS tools. Prefer mavlink-router or even MAVProxy that are much simpler to maintain and efficient for routing. MAVLink routing protocol The Mavlink routing protocol defines how a MAVLink message should be delivered when a target is settled. It can be resumed by the two following pictures. With MAVLink routing prototocl Without MAVlink routing protocol Do you know some other solutions ? Let’s us know ! 5 posts - 3 participants Read full topic [Less]

MAVLink routing on Companion Computers. One of the strengths of ArduPilot is that we rely on the standardized MAVLink protocol for our telemetry. As our drones gain more capabilities, companion computers are often used with many ... [More] separate pieces of software that need to have access to the flight controller data. A common approach to do this is to use MAVProxy, the ArduPilot developer’s main Ground Control Station. MAVProxy relies on a module based approach that allows it to have numerous capabilities, can serve as a MAVLink message router between multiple components and implement the routing of MAVLink messages according to Mavlink routing protocol. Routing components with MAVProxy is simple: we need a --master endpoint to connect to the autopilot and then we can setup as many output endpoints (--out) as we want. This approach is simple to set up but has some costs. MAVProxy, is a fully featured ground control station and not a sole message router. Using the default startup options consumes a lot of resources, and defaults to loading numerous modules. You can see those default modules at the MAVProxy prompt, (a prompt that shouldn’t exist for a simple routing feature…), by typing module list : STABILIZE> adsb: ADS-B data support arm: arm/disarm handling auxopt: auxopt command handling battery: battery commands calibration: calibration handling cmdlong: cmdlong handling console: GUI console fence: geo-fence management ftp: ftp handling layout: window layout handling link: link control log: log transfer map: map display misc: misc commands mode: mode handling output: output control param: parameter handling rally: rally point control rc: rc command handling relay: relay handling signing: signing control terrain: terrain handling tuneopt: tuneopt command handling wp: waypoint handling How can we make this better? Solution 1 : Clean up MAVProxy! First, launch MAVProxy as a deamon with --deamon that removes the interactive shell. Next, you want just routing, so the only module you need is link. This module will allow you to set as many outputs you want on launch. Secondly, MAVProxy should be configured to stop adjusting telemetry rates… You may have noticed that MAVProxy and all Mavlink GCS, automatically request data from the Autopilot. This comes from a special routine that will regularly set the telemetry stream rates: the frequency the autopilot should send a defined group of messages. This feature is convenient for a GCS but not for your MAVLink router as it will fight against other software on the same link. For example, if you have MAVProxy connected to the Autopilot and a companion computer connected to MAVProxy, if you ask with the companion computer to have the IMU message at 50Hz, after a few seconds the IMU message will stop coming at 50Hz and revert to 4Hz as MAVProxy will have reset it. Thankfully, MAVProxy has an option to disable this behavior, like most GCS. For MissionPlanner, it is in Planner configuration options. Your new MAVProxy command line will be something like: mavproxy.py --master=tcp:localhost:5762 --daemon --default-modules "link" --streamrate -1 --out 0.0.0.0:14552 --out 0.0.0.0:14553 --master for the autopilot link --daemon for not have interactive shell --default-modules "link" to keep only the ability to set outputs. --streamrate -1 to disable messages control from MAVProxy --out 0.0.0.0:14552 to set new output Now you have a clean router for your Mavlink messages. Solution 2: Use another software that just do MAVLink routing : mavlink-router This is small C-based software that mostly only does MAVLink routing. It can do the routing of Mavlink messages according to MAVLink routing protocol, do messages filtering and sniffing, and lastly it has a logger system. Compared to MAVProxy it is very lightweight both in size and CPU usage. However, it is optimized for routing and has limited other capabilities. If you have multiple pieces of software that need access to the autopilot data stream, mavlink-router is one of the most used options. Solution 3: Use some Linux tools. These aren’t dealing with MAVLink specifically, but can still be used to push MAVLink messages through IP networks. Two are well known: socat : https://linux.die.net/man/1/socat ser2net : https://linux.die.net/man/8/ser2net Both allow you to create a serial connection to the autopilot and link it to an IP network. Solution 4: Use [mavlink-hub.py] (https://github.com/peterbarker/mavlink_hub). This is another packet-distributor based on pymavlink; it has no routing capabilities and simply sends any packets received on any of its links to each of the other links. Lighter-weight than MAVProxy and written in portable Python, and thus heavier on resources than mavlink-router. Solution to avoid : MAVROS MAVROS is a great piece of software but it serves its purpose at linking ONE and only ONE MAVLink system (one autopilot for example) to ROS. It has some routing capabilities to relay messages but considering the heaviness of a ROS deployment, you shouldn’t use it for routing and especially if you don’t need to use other ROS tools. Prefer mavlink-router or even MAVProxy that are much simpler to maintain and efficient for routing. MAVLink routing protocol The Mavlink routing protocol defines how a MAVLink message should be delivered when a target is settled. It can be resumed by the two following pictures. With MAVLink routing prototocl Without MAVlink routing protocol Do you know some other solutions ? Let’s us know ! 3 posts - 2 participants Read full topic [Less]