Page 1 of 1

Questions regarding passing (x,y,z) coordinates to the CF2

Posted: Mon Feb 05, 2018 9:56 pm
by OUideas
Hello all,

We are a small group of undergraduate and graduate student researchers using several Crazyflie 2.0 quadcopters in our lab to do work on autonomous UAV guidance. Currently, we are using tracker balls with a VICON system to collect position data, and have been somewhat successful in controlling the CF2 using the vision library ( and sending roll, pitch, yaw, and thrust commands.

Our immediate goal is to be able to send (x,y,z) set points directly to the CF2 via CFClient, but have been unable to figure out how it can be done, so:
1. Is it possible to pass (x,y,z) coordinates to the CF2? How?
2. If it is not possible, what is the best way to calculate roll, pitch, yaw, and thrust commands?
3. Is the vision library the most up-to-date PID controller available?

Any help would be greatly appreciated. If you need more information on our setup or methodology, please let us know.

Re: Questions regarding passing (x,y,z) coordinates to the CF2

Posted: Tue Feb 06, 2018 5:51 am
by arnaud

1. Yes, it is possible, there is an 'extpos' port where you can send an externally acquired position. For example this dev branch of the client is using it: ... If you want the position estimate to be used you need to force the Kalman filter estimator in Crazyflie. This is done by compiling the firmware with "ESTIMATOR=kalman" in tools/make/

2. The attitude estimate will be calculated by the Kalman filter. The attitude setpoint will be calculated by the internal PID loop, see the autonomousSequence example in the lib for sending position setpoints. On a side note, there is another controller available that is much more performant for trajectory following: Though the control packet for it is not yet implemented in the Python lib, it still requires ROS.

3. No, the internal PID controller is the up-to-date controller. This repos was done at a time where we did not have internal controller in the Crazyflie.

Do not hesitate to keep us updated of your progress :-).

Re: Questions regarding passing (x,y,z) coordinates to the CF2

Posted: Tue Feb 06, 2018 2:57 pm
by OUideas
Thanks for your speedy reply!

Currently we are attempted two different methods to send the CF to a commanded position. The first (and most ideal) is to send a set-point directly to the CF. The second, and what appears to be the most common, is calculate the control efforts (roll, pitch, yaw, thrust) with a PID controller and send to the client over the control port (local:1212).

For sending set-point commands directly, we did look through the crazyflie-lib-python examples early on, however our understanding is that the lib-python talks directly to the radio (in turn the CF) and by-passes the client completely. We would like to keep the functionality of the client if possible while sending set-points. So my question is, can we send set-points (x,y,z) to the crazyflie through the cfclient with an existing port? If there is not an existing port, is there a way for us to implement one?

As a side note, we have also successfully sent external position messages with vicon by adding an external position thread inside of cfzmq We have yet to implement this into cfclient since we are sending raw control commands to the quad, but will be implementing the same position thread inside cfclient if a set-point (x,y,z) command can be sent through cfclient. ...

Thanks again, we really appreciate any insight.

Re: Questions regarding passing (x,y,z) coordinates to the CF2

Posted: Tue Feb 06, 2018 3:38 pm
by arnaud
The client branch I linked to is doing basically what you did in the zmq client but in a tab instead and using the lib functions.

Sending position setpoint to the Crazyflie is the standard way of having an autonomous Crazyflie, I am not sure it is so common to send attitude and thrust setpoints anymore (since the Crazyflie has a Kalman filter and a PID controller). We should also soon be able to send attitude measurements in the Crazyflie.

Unfortunately, sending position setpoint from the client has not been implemented yet. This is something we will have to work-on to integrate Qualisys and other mocap in the client. The main problem is that currently the gamepad input subsystem sends setpoints at high rate and there is no API or system to switch to another setpoint source. We have to re-architecture the full input subsystem of the client.

If you do not connect any gamepad to the client no setpoint are sent from the input subsystem so you should be able to send position setpoint the same way the lib examples are doing it. This is the only solution I can think about until we re-architecture the client.

By the way, how would you envision the UI to switch between gamepad attitude control and zmq position control, would it be clear enough to switch to zmq input and allow your scripts to send position?