Controlling the CF with an asynchronous version of the motion commander

[EJKT]

I apologize for the question I posted yesterday or the day before to which I could have easily found the answer in the documentation. There is however still something that is not clear to me: can you control the motion commander asynchronously? This would be useful for me because it would allow making a function that for example takes x and y displacement from the current position as an input and then makes the drone do that. If one were to use the synchronous way of doing things, it would land after this function which is not desired. Maybe there are alternatives, just let me know.

Thanks in advance,

Ethan Thiebaut

[knmcguire]

Hi!

There is an step-by-step example that at least has async logging, but not that for the motion commander I'm afraid: https://www.bitcraze.io/documentation/repository/crazyflie-lib-python/master/user-guides/sbs_motion_commander/.

I'm sure that if you start the motion commander instance in the right way, and find a way to pass that instance to the call back functions, this should be possible. However there is a lot of logic going on in that class that might block it from flying if the connection is setup probably, since it is meant as a wrapper around the basic commander class to make things (supposably) simpler. So if you want to do something special like that maybe the motion commander is not the right place to look.

Their might be an 'easier' way How about you use the commander class instance? This is one step down in high-level-ness, but you are able to more easily send setpoints to the crazyflie (like send_hover_setpoint() ). As it is low level, it needs to be ensured that the setpoint is send constantly with a half-second interval at least.

There are some examples in the python library repo that you could look at that use the basic commander class:

• examples/positioning/flowsequenceSync.py
• examples/multiranger/multiranger_pointcloud.py (this used the send setpoints in async way as well)

[EJKT]

Hi, thanks for the response. The commander class seems to be a good replacement. I am wondering if there exists a way to set the velocity at which at the set_position_setpoint command is executed, just with a flow deck? For example if I want to reach (x,y,z,yaw) in a given time the only way to do that seems to be through computing the roll, pitch, yaw and thrust values and how long they should be maintained. I saw that there is a send_velocity_world_setpoint function, but is this meant for reference frames generated by the flowdeck (as this is relative and not "world"). Anyways please let me know what your solution would be.
Thanks.

[knmcguire]

Ah I think that probably the function 'send_hover_setpoint()' is the one you want! Vx and vy are in body coordinate, yaw is in rate (velocity) and the height is absolute. That is what we use for flowdeck measurements.

I see that the explanation of the function is not correct so I'll update that right away.

[EJKT]

Yes, indeed I saw that function but it does not allow you to set a velocity in the z direction. How would one do that? It cannot exactly be done with regular delays as reaching the given zdistance will be done at a preset velocity.

[knmcguire]

Ah no it does not. You will need to write your own function for that. The problem is that there are preset setpoint types that correlate with the firmware generic commander types, so that will require a firmware change as well.

Another option is to use the send_setpoint directly, and change parameters in the flightmode parameter group , but again there is nowhere within the crtp_commander_rpyt.c that the velocity_body is set to true.

Or you managed to write something that just adds the increment on top of the estimated zdistance at every time that you send the setpoint with the absolute distance, which is what the pointcloud script is doing. It is not ideal but it will prevent you from changing the firmware.

[knmcguire]

The high level commander you could also have a look at. As this is for more onboard autonomy you don't need to send it setpoints every 0.5 seconds, but if you lose connection it won't turn off the motors either.

Here is the api for that: https://www.bitcraze.io/documentation/repository/crazyflie-lib-python/master/api/cflib/crazyflie/high_level_commander/ and it has a go_to functionality that can be done relative of your current position.

[EJKT]

Ok, then it seems that the HL commander is the best way to go. I have checked it out and have seen that in addition to the go_to function there are others for landing, taking off, following trajectories and more. Are these are all made for the flow deck? And what kind of set up do I need in my code for the HL commander? I assume it is different from the commander and motion commander classes.

[knmcguire]

technically they were made for mocap, but they should work for any positioning system, including the flowdeck.

This is an example that uses the hl commander: https://github.com/bitcraze/crazyflie-lib-python/blob/master/examples/autonomy/autonomous_sequence_high_level.py. Just comment out the trajectory parts because that requires quite some space.

I've given a lecture to an EPFL class a while ago, where I explained about the types of commanders as well, so perhaps that can make it more clear: https://www.youtube.com/watch?v=6s8i-nhPjt0&list=PLj9XMmQVSr-C-ZXeWWyZgeZ7C4g6A5nPj&index=2&t=2696s