High-level controller causing failed takeoff

[DennisMelamed]

I have been trying to get the code in test_high_level.py to run with my Crazyflie and have been unsuccessful. I was hoping you could help me if you have some extra time. Every time I try to run test_high_level.py, the UAV launches, then immediately flips over and crashes. Sometimes there is a big spike in the position estimates rqt_plot is displaying, but not always. I have tried adjusting the roll and pitch trims in the crazyflie_add call, but to no avail. My CF does have a 5 gram camera, a transmitter, and a non-stock battery attached to it. However, I am able to fly manually with these attachments so I don't think they're causing the issue.

Here is what I have done:

• Flashed the Crazyflie with the official firmware from the master branch, modified to force it to use the Mellinger controller and Kalman estimator
• Launch the VICON system to publish the pose of the CF
• Launch a crazyflie_server, add the CF using crazyflie_add
• run publish_external_position_vicon.py
• launch a baselink_broadcaster to pblish the tf frame /crazyflie/base_link at the same spot as the VICON frame for the CF

• Run test_high_level.py, which contains the following commands:

    cf.setParam("commander/enHighLevel", 1)
  
    cf.takeoff(targetHeight = 0.5, duration = 2.0)
    time.sleep(3.0)
  
    cf.goTo(goal = [0.5, 0.0, 0.0], yaw=0, duration = 2.0, relative = True)
    time.sleep(3.0)
  
    cf.land(targetHeight = 0.0, duration = 2.0)

Here is the plot of the x,y,z state estimates coming from the UAV during the flight in the video linked below:

An image of my crazyflie, in case something in my configuration might be the issue:

And here is a video of it taking off and immediately flipping over: https://drive.google.com/file/d/167p2aUdvXw286ok1-6lwMShYQFU-1haT/view?usp=sharing this occurs regardless of the pitch and roll trims. I am launching from the stand seen in the video to remove any issues caused by the shock absorbing springs on each arm of the UAV.

Is there something I should be changing in the firmware to handle the different weight of the UAV from the stock model? What else might be causing this issue? Thanks in advance for you help!

[whoenig]

• Did you try flying manually with the mellinger controller enabled? For a different mass and battery, you might need to re-tune those two values: https://github.com/bitcraze/crazyflie-firmware/blob/master/src/modules/src/controller_mellinger.c#L48-L49. Note that if you fly manually, only half of the controller is enabled (the attitude part), and not the position part.

• To me the video looks like the state estimate is not working correctly. As a simple sanity check, just run publish_external_position_vicon.py (and not test_high_level.py). Move the CF around manually, and make sure that the plotted state estimate is correct with respect to the world frame.

[DennisMelamed]

Hi Wolfgang, Sorry for the delay in getting back to this, and thank you for your help. I stripped all the extras off my CF and am just using the stock configuration to eliminate possible issues.

• I am able to fly manually with the mellinger controller enabled, and as expected the attitude controller functions while the position needs to be controlled manually.
• I have setup a new workspace with a fresh copy of crazyflie_ros (the master branch)
• in external_position_vicon.launch I have modified the uri and the frame to match my cf.
• I run roslaunch crazyflie_demo external_position_vicon.launch as you suggested
• When I run the steps above, I now no longer get any information being plotted in the state estimate at all (i.e. theres nothing on the /crazyflie/log1/values topics).
• Data is published on /crazyflie/external_position, but this is just the vicon data being re-transmitted

I am not sure where the issue here lies, especially since it seems like a step back from where I was before.

From the firmware side:

• In the crazyflie-firmware repo (2018.10Release tag), in the file estimator.c I switched the line

  currentEstimator = estimator;

  for

  currentEstimator = kalmanEstimator;

  and in controller.c:

  ControllerType forcedController = CONTROLLER_NAME;

  for

  ControllerType forcedController = ControllerTypeMellinger;

  Since I wasn't able to get it to load correctly just by modifying the lines in the Makefile. Perhaps this is the issue? Should I be using a different release of the firmware? (EDIT: I tried with the master branch of the firmware from bitcraze, don't need the above changes anymore- Makefile way works- but the issue persists)

Thanks again for your help

[whoenig]

Sorry for the delay. I just got around testing it. I used the firmware you specified without changes and I flashed it using rosrun crazyflie_tools flash --target stm32 --filename ../cf2-2018.10.bin. Then, I updated the high-level python script to switch to the EKF/Mellinger on demand (which the new firmware release supports): https://github.com/whoenig/crazyflie_ros/blob/master/crazyflie_demo/scripts/test_high_level.py#L14-L15.

It was working for me, but not reliably (some messages seem to get lost). Unlike your report, I also did get the logging data. Nevertheless, I did receive some other reports that the safelink feature I recently added causes strange issues in some cases. I disabled it by default (see https://github.com/whoenig/crazyflie_cpp/blob/master/include/crazyflie_cpp/Crazyflie.h#L14). Perhaps you could give it a try and tell me if it fixed your issues (everything is tested and pushed to master.)

[DennisMelamed]

Seems like it may have been the safelink feature and some mis-configuration on my part, it works now! Thank you so much for your help, and for continuing to support this fantastic project.