aerostack2 / project_crazyflie

BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

Unstable Aerostack2 Project #13

Closed zZ-kunja-Zz closed 1 month ago

zZ-kunja-Zz commented 3 months ago

I am reaching out regarding some issues we are encountering with the integration of AeroStack2 and Crazyflie drones in our project. We are using a setup involving Ubuntu 22, AeroStack2, Motive 3.02, and 16 Optitrack prime 22 cameras for motion capture. The ROS2 humble project includes the standard AeroStack2 package, the motion capture package, and a simple Crazyflie example project.

We use the mocap.launch.py, which functions correctly after we run the launch command on the simple crazyflie project. To fly the drone, we use the sample mission.py. First the parts of the project we know to work. The controller functions correctly, the drones receive their pose correctly, and the radio connects correctly. When starting up the project, we run into three situations:

  1. Where the drone will fly correctly every day but must be turned off between trials, and the launch file has to be closed and reopened.
  2. The drone flies, but there is a varying delay in receiving pose data.
  3. The drone does not attempt to take off. These three situations will stay until the project is rebuilt and everything is turned off. Additionally, we sometimes get takeoff behavior not available warnings but this does not seem to affect performance.

We would greatly appreciate any guidance on troubleshooting these issues or any known solutions that could help resolve them.

zZ-kunja-Zz commented 3 months ago

I believe our issue stems from not understanding how the launch files mocap.launch.py, tmuxinator start and ./launch_as2.bash work together and how they should be nested or separated into different terminals and in which order to use them in.

pariaspe commented 3 months ago

Hi, sorry for the late response,

1. Where the drone will fly correctly every day but must be turned off between trials, and the launch file has to be closed and reopened.

After, running launch_as2.bash you should be able to run mission scripts multiple times unless you do an emergency kill switch, where full aerostack2 and crazyflie have to be reboot.

2. The drone flies, but there is a varying delay in receiving pose data.

Might it be your system causing the delay? How big is the delay and how are you detecting it? It seems to be an issue related with your system or ROS2, not with aerostack2.

3. The drone does not attempt to take off. These three situations will stay until the project is rebuilt and everything is turned off.
   Additionally, we sometimes get takeoff behavior not available warnings but this does not seem to affect performance.

Can you provide some more details? It is hard to guess why the drone might not taking off with the brief description. Takeoff (or other behaviors) warnings are due to ROS2 discovery protocol which fails sometimes, you can skip those warnings most of the times