Crazyflie cannot be stable when take off, it flipped onto the ground.

[lkyfly0765]

Hi @whoenig ：
I just figure out the crazyswarm-server issue and trying to test the hover_swarm.launch with the given figure8_csv.py trajectory. But when I run python figure8_csv.py in another terminal window, the crazyflie respond to take off, and suddenly flipped down to the ground. I uploaded the video here https://youtu.be/dJ-tqMDjkeY.
As you can see, when I enter the python figure8_csv.py, the crazyflie just take off and quickly flipped down to the ground. What may cause this problem?Also, the LED ring is always green shows that the connection quality is good. But why that happened? I am confused about that. I have the same issue with #115 , but after reading that issue, I cannot solve it out.

I have updated the crazyflie's firmware using the Option 2 provided in https://crazyswarm.readthedocs.io/en/latest/usage.html#crazyflie-preparation.

I am using the optitrack as the mocap system, and use the motionCapture rather that libobjecttracker. I have created a rigid body in Motive software. To confirm the coordinate system is correct, I move the crazyflie manually and see that in Rviz the position information is correct. So I think the coordinate system is not the reason to cause the flip problem.

And there is a strange thing that when I launch the hover_swarm.launch, I press the start button on the Xbox360 joystick, there is no response on the xterm window or the crazyflie. I cannot let the crazyflies just take off and holding the x/y position they were originally placed in. It seems that the joystick is unusable. Is there anything wrong with my setting?

Thanks！

[hanzheteng]

This is usually because of having bad state estimation.

1. Try using estimator 2 and see if it's getting better.
2. Make sure your external mocap update is received by crazyflie. You can check topic and message graph by rqt_graph. Also, you can try printing the message out and see if it's reasonable.
3. As far as I know, for time being, crazyswarm framework is only compatible with old version (below 2.0) of Motive. Because the new version of Motive has changed their data structure. Also, Motive provides a different axis layout (Y up) by default, which needs to be taken care of.
4. For joystick, please check if the joystick node is working normally and is able to receive the control signal. If so, continue to check if this signal is passed to other nodes and handled correctly. If not, continue to check what's wrong with the joystick connection. This is a general debugging plan.

[jpreiss]

@lkyfly0765 were you able to resolve this?

[ColsonZhang]

This is usually because of having bad state estimation.

1. Try using estimator 2 and see if it's getting better.
2. Make sure your external mocap update is received by crazyflie. You can check topic and message graph by rqt_graph. Also, you can try printing the message out and see if it's reasonable.
3. As far as I know, for time being, crazyswarm framework is only compatible with old version (below 2.0) of Motive. Because the new version of Motive has changed their data structure. Also, Motive provides a different axis layout (Y up) by default, which needs to be taken care of.
4. For joystick, please check if the joystick node is working normally and is able to receive the control signal. If so, continue to check if this signal is passed to other nodes and handled correctly. If not, continue to check what's wrong with the joystick connection. This is a general debugging plan.

what's the "estimator 2" means ?

[hanzheteng]

@ColsonZhang See

crazyswarm/ros_ws/src/crazyswarm/launch/hover_swarm.launch

Line 21 in 53e5058

estimator: 2 # 1: complementary, 2: kalman

[ColsonZhang]

@ColsonZhang See

crazyswarm/ros_ws/src/crazyswarm/launch/hover_swarm.launch

Line 21 in 53e5058

estimator: 2 # 1: complementary, 2: kalman

Thanks a lot!
Now I am using the estimator : 2.
But actually I have tried flying 6 crazyflies at the same time for many times, and the result is usually that there're always one or two crazyflies falling to the ground.
So now I begin to wonder whether It is the radio PA's fault?

[hanzheteng]

@ColsonZhang Probably reached the maximum bandwidth that a PA/channel can communicate. If I remember correctly, there is an option to disable logging or something that can reduce the bandwidth usage. Check documentation and issues before. I haven't been working on this for a year; just a rough idea in mind.

[swarm5]

@ColsonZhang请参阅

crazyswarm/ros_ws/src/crazyswarm/launch/hover_swarm.launch

Line 21 in 53e5058

estimator: 2 # 1: complementary, 2: kalman

非常感谢！
现在，我使用估算器：2.
但是实际上我已经尝试多次同时飞行6只crazy蝇，结果通常是一到两个or蝇掉到地上。
因此，现在我开始怀疑这是否是无线电PA的故障？

I encountered a problem similar to yours. I wonder if you solved it?

[ColsonZhang]

There is a parameter which controls the log frequency in the file hover-swarm.launch. The default value of the frequency is 10, and I modify the value to 1. After the operation, the situation will maybe get better a lot.

[swarm5]

thank you for your sharing.

1. You have reduced the log recording frequency, but have you tried to turn off the log function? If you turn off logging ‘enable_logging: False’ in hover_swarm.lauch, will the effect be better?
2. When I fly 10 cfs, there are always one or two unstable. I am using usd to record logs, and I am currently testing.
3. I noticed your name. Are you also from China?

[ColsonZhang]

1. Because I did not have enough time, I did not find out how to disable the log. It is seemed that aasign enable_logging = False ia not useful. Maybe you can view the swarmserver.cpp to fond it out.
2. I used the crazyswarm to fly 6 or 4 crazyflies. Before I modified the log frequency, there were always 2 crazyflie ubatable. After I reduce the frequency, It was better.
3. Yes, I come from CHINA.

[easy98]

Hello,

I also have the same problem, did you solve it? Thanks.

[lkyfly0765]

Hi @whoenig , During my recent experiments, for optitrack users, there are some important settings need to be configured, they are not in the crazyswarm website. May be you should add them.

1. Cannot receive the rigid body data from the Motive server. This may cause “crazyswarm-server-2 process has died” issue.
The original program which use the Natnet SDK is much more usable than the VRPN, but there may have some issues with the build-in Natnet program named optitack.cpp. It’s really a convenient way to check the connection issue with the help of NatNetSDKCrossplatform.
Please check the doc to familiar with the program. Especially, for Ubuntu 16.04 users, you have to change the boost version to 1.65 at #L3 of the CmakeLists.txt, or you may encounter some compile issues.
If you cannot receive the rigid body data from the Motive server via the mcr program in NatNetSDKCrossplatform, please check that the multicast interface in Motive-Data streaming-Advance , it should be 239.255.42.99 as default (see more at natnetsdk). Importantly, there is no need to change it to the IP of the server computer where Motive is running, just leave it as default. Also please check that in optitrack.cpp(crazyswarm) or multicast_receiver.cpp (NatNetSDKCrossplatform), the Multicast address is same with Motive setting.

 Checklist:

1.	The Firewall on both Motive running computer and Ubuntu is set to disable.
2.	The Datastreaming-Broadcast frame data is turn on, the Local interface is selected to 
the IP address where Motive is running (not loopback).
3.	ONLY Stream Rigid Bodies is set to true(or turn on). 
If the object_tracking_type is set to motionCapture, you should ONLY turn on the Stream 
Rigid Bodies, the Labeled markers, Unlabeled markers and Asset markers should set to 
False( or turn off), or the crazyswarm program cannot recognize the data type then cause 
the process has died error. (I just use the crazyswarm in motionCapture mode, if you use
 the libobjecttracker, ONLY the Unlabeled markers should be set to Ture ( or turn on) theoretically.)
4.	Check the Multicast Interface is set to default, and in optitrack.cpp (crazyswarm) or  
multicast_receiver.cpp(NatNetSDKCrossplatform) the Multicast Address is same with 
the Multicast Interface.
5.	Change NatNetSDKCrossplatform to the bug-recv-issue branch. 
In this branch, Hoenig made the multicast listen address configurable. In Xterm, you 
should use $ ./mcr <IP-where-motive-is-running> <IP-where-crazyswarm-is-running> 
to run the program, and this should resolve the data-receive-issue.
**You should run the mcr program separately in an Xterm window and keep it running during the experiment time!** 

In my view, the crazyswarm is using the old version of NatNetSDKCrossplatform, which you may encounter the date receiving issue. If the step 1 to 4 is not work for you, just clone the bug-recv-issue branch and run the mcr program separately in a Xterm window, keep it running all the time. Then you can launch the hover_swarm.launch and see the cf’s in Rviz. May be the bug-fixed version should be build-into the crazyswarm.

2. The relationship between the rigid body ID with the cf ID in allCrazyflies.yaml.
@netkimjh has introduced how to use the Rigid Bodies function for Optitrack in pull, but there is a misunderstanding at

A name of rigid body is not important. You can name it as what you want. However, its order is important!

In Motive, if you open the asset property pane to check the property of each rigid body, there is a streaming ID, you can set the streaming ID to any number. In mcr software, it output the streaming ID number as the head of the position data. In crazyswarm, the crazyflies id in allCrazyflies.yaml is assumed equal to the cf-URI’s last two numbers, also equals to the Streaming ID in Motive. Which means that there is no need to create the rigid body in order from cf1 to the last cf, all you need to do is just make sure that the Rigid body’s streaming ID in Motive is equal to the crazyflies’ id. You will not need to delete all the rigid bodies and recreate it when you change the markers configuration.
In Motive, the default streaming ID is the order you create the rigid body. I guess that’s why @netkimjh said the order is important. However, you can change the streaming ID at any time.

---

---

---

@whoenig Here I still have one question.
I found that when I use more markers, and I have changed the battery to a higher volume, the mass of the crazyflie is increasing. It may cause the unstable hover even can not take off perfectly. In the crazyflieTypes.yaml L25 & L26, there are two parameters, mass and massThrust. I think that the mass is the weight of the crazyflie, but I am not sure what's the definition of the massThrust, could you please help me to figure out what is the relationship between mass and massThrust?
I have tried to increase the mass parameter, it obviously improve the hover and trajectory quality.

Thanks with regards.

[whoenig]

Thanks a lot for your insightful comments. I am planning to update the documentation accordingly, based on your feedback.

For your question: massThrust is just a scaling value that roughly speaking converts the mass to the required PWM values. If your CF is heavier, you can either tune mass or massthrust by setting the I-gains to 0 and ensuring that the Crazyflie is flying at its designated height. If it flies too high, reduce either mass or massThrust, if it flies too low increase one of the values.

[jpreiss]

I suggest tuning mass instead of massThrust. Increasing massThrust will effectively increase the controller gain values as well, while increasing mass will correct the feedforward gravity compensation term without making the controller more aggressive.

[lkyfly0765]

Thanks for yours explanations.
In my experiment, I increase the mass to the real weight value of my crazyflie, and I set the massThrust to 140000 (the default value is 132000), the crazyflies take off more stable and it will not flip to the ground. But if the massThrust is set too high, the crazyflie’s rotors will output a high speed when taking off and cannot takeoff stable( flip to the ground). I agree with @jpreiss that the massThrust will make the controller more aggressive and the control output will be poor. I will try to tune the mass instead of massThrust.
Based on yours comment, does that means the mass parameter is just a parameter that doesn’t need to equal to the real mass value(weight) of the crazyflie?

[jpreiss]

If you need to make it very different from the true mass of your Crazyflie, something else may be wrong. I would suggest setting it to the true value and if you still have problems, double check the motors/props/etc and try tuning the PID gain values of the controller in your launch file.

[HaomiaoLuoLlanio]

Hi, @whoenig @jpreiss
I have a similar problem. Here is the video describes the scenario I encountered. (https://youtube.com/shorts/HIPpsuHnaOU?feature=share). I used the Xbox USB joystick and pressed the trigger to send the taking off command to the crazyflie, however it just jumped on the ground. This is the new one. I can make the other old ones taking off on the ground. Did I miss something on the configure file?
Here are vehicles and software I used:
Motion capture system: OptiTrack, Motive 2.0
Crazyflie: 2.1
Joystick: Xbox USB connection
ROS: crazyswarm, Rviz