Problems with hello_world.py

[flrnhbr1]

Hi, I am currently starting to work with crazyswarm and crazyflies(2.1).

I installed and configured everything, but I have big troubles with the first hovering with HW.

Everytime I execute the hello_world.py, the crazyflie flips over or flies somewhere.
I already tried to balance everything and also tried to start the drone manually (which is working completely fine)

I also tried to change the drone, but the issue remains.

Is it possible, that I made a mistake, when setting up crazyswarm?

Thank you in advance!

Regards Florian

[knmcguire]

Just to help out for the maintainers: it will be good to mention what kind of positioning system you are using or specifically which decks. If you are using one crazyflie, before flight, you can see in RVIZ if the position is converging and stable by just holding it in your hand.

Also you should let us know on which version of the firmware of the crazyflie firmware you have flashed your crazyflie with.

[flrnhbr1]

Hello,

sorry you are right, I should have written more information.

I use Optitrack system to track the crazyflies with a single marker.

When I start RVIZ the drone position is stable, also when I move it, the position moves stable.
But in the hello_world.py, the data of the optitrack is not even used, so the motion Capture system should not influence the flight. (at least if I understand it right)

I flashed the drone in the crazyflie client with the latest FW (I think 2022.01)

[knmcguire]

Maybe just double checking if changing the controller to 1 (PID) makes any difference as well. But I think that the mellinger default should easily handle take off with a new crazyflie.

[flrnhbr1]

Ok thank you very much for the quick answer in the first place!

I will have a look at this when I am in the lab again and also will try to change to PID.

But regarding the setup of the configurations of the motion capture:
In the script hello_world.py there are only two flight commands --> takeoff, and land.
So I never read or compute data from the Motion capture. Therefore this shouldn't affect it even if the configuration of, lets say the data streaming pane of motive, is false?
Or is the motion capture data used in the calculation of state estimation etc. even if i don't explicitly read it and compute it in the python script?

And yes it looks like there is another one with a similar problem, he quoted my question and posted it to "Issue"

[knmcguire]

As I understand correctly the motion capture data is all handled in the crazyswarm_server ROS node, which should run if the launch file is called. So it is correct that the python script in crazyswarm/scripts/ does not do anything with mocap, with the assumption that it all works correctly on the crazyswarm server side of things.

This overview explains it quite well I think: https://crazyswarm.readthedocs.io/en/latest/overview.html

[flrnhbr1]

Ok thanks, I will have a look at the configuration and hey to change the Controller in the Lab then.

Thank you for the moment.

[knmcguire]

I tried crazyswarm out with the latest firmware in our lab, and it seems to work fine! So there is probably something else going on on your setup. Hope it will be indeed the radio firmware as @whoenig said!

[whoenig]

Perhaps you forgot to update your Crazyradio firmware? This needs to be done even if you use a "recently" bought radio. You can check by either installing an LED ring (should show green) or setting enable_pose_logging to true if the data is transmitted correctly.

[flrnhbr1]

Indeed I did not upgrade the crazyradios firmware. I will try asap.

[flrnhbr1]

I hav now tried to upadate the FW as @whoenig mentioned. Now the drone is flying a bit more stable, but the problem is still there.
I also tried to change the controller to PID as @knmcguire mentioned, but unfortunately this doesn't change anything.

Here i uploaded a video of the flight now: https://youtu.be/COTS-W2y-OM

I have also tried to changed the targetHeight to e.g. 0.5, but the same behavior appears.

[flrnhbr1]

It actually worked, thank you very much.

The problem was, as it seems, the electrostatic field of the carpet. I tried to start the drone from a ESD-Safe plate and it started without problems.
There you can see my first ever succesful flight with the crazyflie and crazyswarm :)
https://youtu.be/2q0vO0YEHig

[knmcguire]

Awesome! Glad that it worked now

So it wasn't necessary to set the send_position_only to True? So you confirmed it was only the static that was the problem?

[flrnhbr1]

I first tried to change the flag to True, but this didn't change anything. Nevertheless the drone flew away somewhere.
And afterwards i tried the plate underneath and it worked.

Therefore I am pretty sure, that this was the problem.

[jpreiss]

The flag indeed should be set to True. But single-marker tracking depends much more on the IMU than full pose tracking, so it's not surprising that a problem with the IMU would ruin a single-marker flight. What was the flag value in your successful flight?

I believe setting the flag to False should cause a crash because the EKF is tuned (by default) to trust the attitude measurement more than the IMU. The PC will be sending identity quaternions for the attitude, so the CF will think it's hovering when it is flying off.

[flrnhbr1]

At the succesful flight the flag was True and i will let it be like that, because it was already mentioned it should be True with Single Marker.