micro-ros/micro-ros_crazyflie_demo

Provides a demo of micro-ROS based on a Crazyflie.

micro-ros_crazyflie_demo's Issues

firmware update question

Issue template

• Hardware description: Crazyflie 2.1
• RTOS: freeRTOS
• Installation type: micro_ros_setup
• Version or commit hash: foxy

Steps to reproduce the issue

I'm trying to run the micro-ros demo with crazyflie2.1

1. Run the docker compose and build with

docker-compose run --rm cf_builder
ros2 run micro_ros_setup configure_firmware.sh crazyflie_demo 
ros2 run micro_ros_setup build_firmware.sh

2. Put Crazyflie in DFU mode and check with

lsusb

The terminal outside the container is in DFU mode but the terminal inside container is in BOOTLOADER mode like these

3. I can only flash the firmware inside the container so flash the micro-ROS firmware with

 ros2 run micro_ros_setup flash_firmware.sh

Expected behavior

micro-ROS firmware is flashed successfully and Connect to Crazyflie successfully.

Actual behavior

Messages showed in terminal loos okay but when I connected to Crazyflie with cfclient (after docker-compose up -d), Crazyflie turned into 「Self test fail」(The right front LED (1) is repeatedly blinking five short red pulses with a longer pause between groups.)

Additional information

Is there something wrong and how can I check everything is ok?

Problems to run the example without docker

Hello!

I'm trying to run this demo with Foxy natively, but I'm having some problems to understand which are the steps to do it. I build and flashed the Crazyflie with the crazyflie_position_publisher app. I have all the Bitcraze libraries installed and working well (cflib and cfclient). I want only to see the odometry and attitude data of the Crazyflie in my terminal (Using the micro-ROS agent). What should i configure inside the uros_cf_bridge_no_joystick? I saw the lines 66 and 67

serial_dev = '/dev/ttyS11' serial_dev_agent = '/dev/ttyS10'

but I get some errors about permission to access this port.

Can you guys give me some light about it?

In my case it is not working well

Thesedays I'm trying to run the microros demo with crazyflie2.1 and ros2 dashing
I built adn flashed the firmware in cf2.1
and up the docker compose with

$ cd /path/micro-ROS_crazyflie_demo
$ xhost +
$ docker-compose up -d

then in my case RVIZ was not running and just cfclinet poped up
I could check the translater node and /drone/attitue and /drond/odometry topics
but these topics couldn't get any data

So I ran the parts saperately

(1) run cfclient
  $ cfclient # or python3 -m cfclient.gui 
(2) check the pseudoterminal number
(3) run the uros agent
  $ ros2 run micro_ros_agent micro_ros_agent serial --dev /dev/pts/checked_number -v6
(4) connect the cf2.1 and cfclient

then sometimes I could see something in the agent terminal like these

if my understand is right then cf2.1 get the roll, pitch, yaw or x, y, z like these data to micro ros agent and
micro ros agent terminal would show these data
but the only data I could see was very statictic I mean while moving my drone, the data was not changing

The conclusion is I think 'it is not working correctly'

The only one doubtful point is
When I build uROS firmware of cf2.1, it works but in the middle of the process

the summary is like this, is this can be the reasone that the cf2.1 can't send the right data?
when I run in foxy then the summary is like this

Is there anybody who ran the crazyflie2.1 micro ros demo recently or get the similar porblems or who can help me

Connection with multiple crazyflies (swarm)

Connection with two (or more) crazyflies

• Hardware description: Crazyflie 2.1
• RTOS: freeRTOS
• Installation type: micro_ros_setup
• Version or commit hash: foxy

Steps to reproduce the issue

• Running a simple micro-ros app with an int32 subscriber and int32 publisher
• Modify the python bridge with an additional CrazyradioBridge() instance to be able to connect to multiple crazyflies with a single radio. (Not the best solution i know just to test ;) ) and write to a different virtual serial port depending on the crazyflie (i used /dev/ttyS11 and /dev/ttyS12.
• Create two separate socat bridges: /dev/ttyS10 <-> /dev/ttyS11 and /dev/ttyS10 <-> /dev/ttyS12

Expected behavior

Multiple crazyflies (micro-ros clients) connect to a single micro-ros agent

Actual behavior

No error happens in the agent and the first crazyflie manages to connect with the agent but the second one fails resulting in an hardfault.
Connection is possible by running two different agents with independent serial ports: /dev/ttyS10 <-> /dev/ttyS11 and /dev/ttyS20 <-> /dev/ttyS12

Additional information

Trying to use the same /dev/ttySXX does not work probably due to socat's bidirectional communication but then again im not sure which alternative approach I can take.

Unexpected behaviour using different QoS settings

Unexpected behaviour using different QoS settings

• Hardware description: Crazyflie 2.1 w/ flow deck and LPS deck
• RTOS: freeRTOS
• Installation type: micro_ros_setup for both the agent and the firmware
• Version or commit hash: foxy

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.

M2 LED on the Crazyflie remains on

After flashing the compiled firmware (through the radio as DFU has not worked for me) the M2 led remains on and the crazyflie does not respond to the cfclient. Is there something I could do to debug this?

Failed to build weather_agent

Hello. I'm trying to use micro-ROS on RaspberryPi(buster v7) according to on the build instruction of this repository. But weather_agent fails to build.
It looks fastcdr not found as the cmake log below. Is it necessary to get in advance?

Issue template

• Hardware description: Raspberry Pi 3 Model A+
• RTOS: Raspbian buster v7
• Installation type:
• Version or commit hash:

Steps to reproduce the issue

• Launch Docker

docker run -ti --rm microros/base:foxy

(got microros/base:foxy f386eff93b36)

• configure and build weather_agent inside Docker

sudo apt-get update && sudo apt-get install -y python3-nose # fix for "module not found" error
ros2 run micro_ros_setup create_firmware_ws.sh raspbian buster_v7
ros2 run micro_ros_setup configure_firmware.sh weather_agent
ros2 run micro_ros_setup build_firmware.sh 

Expected behavior

• Built with no errors

Actual behavior

I got an error below.

root@51d1bd891dcd:/uros_ws# ros2 run micro_ros_setup build_firmware.sh 
Crosscompiled environment: cleaning path
Building firmware for raspbian platform buster_v7
[0.272s] WARNING:colcon.colcon_core.package_discovery:the --packages-ignore-regex '.*_cpp' doesn't match any of the package names
Starting >>> microxrcedds_agent
--- stderr: microxrcedds_agent                                
Cloning into 'microxrcedds_client'...
Cloning into 'spdlog'...
Cloning into 'sanitizers'...
Already on 'master'
Switched to a new branch 'develop'
Cloning into 'microcdr'...
Note: switching to 'v1.2.2'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at 21d3cfe Merge pull request #63 from eProsima/develop
Note: switching to 'v1.4.2'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at 1549ff12 Replace STRING(PREPEND ..) in CMakeLists.txt to support older CMake versions
CMake Error at CMakeLists.txt:143 (find_package):
  By not providing "Findfastcdr.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "fastcdr", but
  CMake did not find one.

  Could not find a package configuration file provided by "fastcdr"
  (requested version 1) with any of the following names:

    fastcdrConfig.cmake
    fastcdr-config.cmake

  Add the installation prefix of "fastcdr" to CMAKE_PREFIX_PATH or set
  "fastcdr_DIR" to a directory containing one of the above files.  If
  "fastcdr" provides a separate development package or SDK, be sure it has
  been installed.


make[2]: *** [CMakeFiles/uagent.dir/build.make:113: uagent-prefix/src/uagent-stamp/uagent-configure] Error 1
make[1]: *** [CMakeFiles/Makefile2:87: CMakeFiles/uagent.dir/all] Error 2
make: *** [Makefile:87: all] Error 2
---
Failed   <<< microxrcedds_agent [17.5s, exited with code 2]

Summary: 0 packages finished [17.7s]
  1 package failed: microxrcedds_agent
  1 package had stderr output: microxrcedds_agent
  1 package not processed

Additional information

Test in Foxy

Please test this demo in micro-ROS Foxy and update this repo accordingly