search

micro-ROS / micro-ROS_crazyflie_demo

Provides a demo of micro-ROS based on a Crazyflie.
Apache License 2.0
18 stars 6 forks source link

Unexpected behaviour using different QoS settings #15

Closed ruimscarvalho98 closed 2 years ago

ruimscarvalho98 commented 3 years ago

Unexpected behaviour using different QoS settings

Steps to reproduce the issue

I have pushed the necessary files to this temporary repo.

  1. Build the workspace and agent using the micro_ros_setup scripts (I have tried with docker as well and the results were the same).
  2. Configure firmware to use the custom uros app that can be found here . This app basically subscribes to a /microROS/ping topic and publishes a response to a /microROS/pong topic. The message type is a custom type which is an array of uint8_t that i have defined in cf_messages and added to mcu_ws. A ROS2 node to measure the latency (RTT) is present in the eval_ws
  3. In order to avoid issues due to radio communication i am using USB, therefore i have modified the microros_transports.c file and the bridge to use the USB llink but the results still apply to radio.
  4. Build the firmware and flash it to the crazyflie.
  5. Run the python bridge, i have used the no joystick version with modifications to print the console as well.
  6. Build the agent according to the micro_ros_setup repo and run it ros2 run micro_ros_agent micro_ros_agent serial --dev /tmp/ttyS10 --baudrate 115200 -v6 im using tmp to avoid needing sudo
  7. Build, source and run the latency_test (making sure the QoS matches the on in the app)in the eval_ws ros2 run csv_creator latency_test --ros-args -p num_samples:=100 -p num_bytes:=256 -p frequency:=1 -p id:=2 -p filename:="random_name" or use the automated script with variable number of bytes.
  8. Change the qos in both app and ROS2 node and compare the results using RELIABLE vs BEST_EFFORT QoS

Expected behavior

The latency using both profiles should be similar or slightly lower in one of them (probably lower in best effort) and increases with the number of packets sent (CRTP uses 31 bytes of payload per packet and has an overhead due to the XRCE serial framing)

Actual behavior

The latency with RELIABLE QoS increases with the payload as expected but the BEST_EFFORT results are random, with significantly higher latency ~110ms vs ~25ms for 8B payload using USB with no clear change with respect to payload size and with significant message loss (i suspect the crazyflie receives but doesnt send back the pong)

Additional information

I also think the timeout to read from serial should be lower as the 200ms that are used are significantly higher than the RTT of the radio link which takes around 7ms meaning it is better to send more packets than wait for sufficient data from the serial stream.

pablogs9 commented 3 years ago

Is this issue still valid? Maybe https://github.com/eProsima/Micro-XRCE-DDS-Agent/pull/262 is related.

@ruimscarvalho98 can you give us an update?

ruimscarvalho98 commented 3 years ago

Maybe eProsima/Micro-XRCE-DDS-Agent#262 is related.

Hey @pablogs9, I am a bit busy this week but I'll try to test this when I find some time and give you an update on it

Acuadros95 commented 2 years ago

Closing due to inactivity, reopen if needed.