Unable to Trigger Figure 8 Flight Pattern Despite Successful Hovering

[jc-bao]

I'm experiencing an issue where I'm unable to trigger a figure 8 flight pattern while I have successfully deployed the policy to the drone and it hovers well.

I have tried adjusting the rlt.wn value to 4 before and after takeoff – the drone didn't transition from hovering to executing the figure 8 pattern.

To signal the flight controller, I used the following button in cfclient as I don't have a gamepad in hand.

Could anybody provide some guidance? Is this the correct method to trigger the flight controller?

[jonas-eschmann]

Hi @jc-bao thanks a lot for trying our code!

I never tried the button you are referencing but from the code it looks like it is sending a different packet than the one send for hovering from the gamepad. The modified firmware is listening to the latter one as the signal to activate the policy.

I implemented it as a "dead man" switch so it is easy to switch between the original controller and the policy for testing. But because of this it needs to be sent continuously. I was using one button on the gamepad to trigger the hovering (using the original controller) and another one to activate the policy. In this way, during testing, it was easy to switch back to the original controller by just releasing the policy activation button when e.g. the policy went crazy.

But unfortunately, there seems to be a bug with the button assignment in the cfclient so I had to hard-code it in the config. Additionally, requiring a modified cfclients and cflib (containing the additional activation message for the policy) seemed like a big requirement and complication for people to try it out (you can still find them as submodules in ./controller/external So I decided to just "hijack" the HOVER message (which is mapped to the shoulder button of the controller by default).

You can check if the policy was triggered in the logs tab of cfclient.

Now that I was thinking about it again, we might not need a modified cflib because we could just send the command via the META_COMMAND_CHANNEL. I created a script to trigger the different modes (on the trigger-script branch). Note that I modified the firmware slightly to disable the motor-warmup for mid-air switching between the controllers. The controller submodule on the trigger-script branch should point to the newest commit (you might need to do git submodule update -- controller). I've added the commands to compile it without Docker as well README.MD.

Please let me know how it goes! Fingers crossed on my side! 🙂

[jc-bao]

Thank you for your detailed response! After reviewing the modified controller and firmware, I've grasped the key issue here.

The learned controller is invoked via a modified META_COMMAND_CHANNEL. Additionally, the inclusion of the standard controller from the crazyflie firmware in your rl_tools_controller.c enables the online switch (Please correct me if I am wrong). This is a clever workaround—great job!

I will be testing your script to determine if the learned controller gets successfully activated. As I am unable to view your modifications to the source code of your customized cfclient and the crazyflie lib python, I was wondering if you might provide a trigger script that features an online controller switch? Alternatively, could you share the setpoint structure of your meta command?

On a side note, I found that I am unable to clone the rl_tools_controller submodules (e.g. cfclient, cflib etc) included in learning_to_fly. Is it possible that these are private, deleted, or simply outdated? My assumption is that updating rl_tools_controller to the latest commit should solve the problem (though the cfclient still points to an empty repo). Would you like to resolve that?

Thank you once again!

[jonas-eschmann]

Yes, you are right about the META_COMMAND_CHANNEL!

The meta-command is actually empty, it is just repeatedly sent to signal that the policy should be active.

Sorry, my response might have been a bit confusing (I got the idea for the trigger.py script while writing it). Using the trigger.py script you should be able to trigger the policy for taking-off and hovering as well as for trajectory tracking using the original/stock cflib (tested using v0.1.14). Please refer to the comments I added to the readme on how to use it.

I had hacked the meta-command into the modified cflib and cfclient but I think the trigger script is the cleaner solution (also considering the gamepad button mapping issue). Additionally, I hacked some code to feed the motion-capturing position and orientation (yaw) reference from the cfclient. These were very specific to the setup in our lab and not a clean solution so I removed the submodules for now. I'm planning on moving the trigger.py script to the asynchronous API in the future and adding the motion capture reference feeding in there (but I don't have access to the mocap system right now).

I added an additional mode to the trigger.py script (takeoff_and_switch) which is better for initially testing policies (because they are not subject to the ground-effect and optical flow/z-ranger behavior (during takeoff). Additionally, the setpoint difference is lower.

[jc-bao]

Cool! Thanks for the update; that's very helpful.

I noticed that you have also integrated the built-in controllers in the Crazyflie firmware, such as pid and mellinger, in your rl_tools_controller.c file by setting use_orig_controller. I am wondering if we can switch controllers by changing that?

[jonas-eschmann]

Yes, you are correct, with the rlt.orig / use_orig_controller you can compare the controllers, e.g. for trajectory tracking. The mapping is the same as in the stabilizer.controller: PID: 1, Mellinger: 2, INDI: 3, Brescianini: 4

[jc-bao]

I think with the provided information and script my issue is fully addressed. Thank you!