search

rosflight / rosflight_ros_pkgs

ROS packages for the ROSflight autopilot
http://rosflight.org/
BSD 3-Clause "New" or "Revised" License
89 stars 58 forks source link

Not all mavlink messages received/published by rosflight_io if timing is jumbled #68

Closed gellings closed 6 years ago

gellings commented 6 years ago

There seems to be a problem if the timing of mavlink messages is not consistent. I've been trying to stream IMU messages at 100 Hz (and status at 1 Hz) and that's it. I use two 3dr SiK telemetry radios. Below I have scoped the lines to show the mavlink messages before (line 0) the flight radio and after (line 2) the ground station radio. The radios seems to change the timing of the messages by placing the messages next to each other. Using the radios causes several of the messages to get dropped and only some get through. I assume that his is caused by buffering on the radio. Something similar happens if you use an ftdi cable for serial to usb instead of the scilabs chip that is on the naze, though only ftdi chips seem to do it. I've also tried other radios (xbees) and have the same issue.

rosflight_io_timing

  1. 16.04
  2. v1.0
  3. parameter file params.yml.txt
  4. GCC
  5. Naze32 -> SiK telemetry radio -> SiK radio -> rosflight_io

Thanks for your help

dpkoch commented 6 years ago

The issue seems to have been with the FTDI driver. The driver sets its latency timer to "16" by default. With this setting, I was seeing about half of IMU messages being dropped at 500Hz over an FTDI cable. After setting the latency to "1" (its minimum value), I was able to stream IMU at 1000Hz no problem.

The best way to fix this is to put the udev rule at https://gist.github.com/dpkoch/8bb68f7632812599582fd74d28afb3a1 into your /etc/udev/rules.d/ directory. This will set the latency to 1 any time a device using the FTDI driver is plugged in.

You can also change the latency setting manually by running echo 1 > /sys/bus/usb-serial/devices/ttyUSB0/latency_timer after logging in as the root user (sudo -i). Obviously not the best solution, and it has to been done any time the FTDI device is plugged in. But this is what the udev rule is doing for you under the hood.

gellings commented 6 years ago

Thanks for all your work to get to the bottom of this!