Working on a new input device architecture

Today we were supposed to post the next part of the RPM measurements. But since we are’t finished with the analysis yet we thought that we would post some info on what we are working on. Since Christmas we have been working on and off on a new architecture for the input devices in the Crazyflie Python client. A while back we started discussing the possibility of “hooking in” different backends that could be used for input data like LeapMotion, Gamepads, sockets and so on. It’s something that we have been wanting to do for a while, but other things have always been prioritized. But during Christmas a forum request triggered the work. Users wanted to be able to change the LED-ring effects directly from the controller. We had some code for this lying around, but since the switch from PyGame to PySDL and Linux devices this wouldn’t merge easily. So we thought we might as well take this opportunity to implement what we wanted :-)

Below is a brief overview of the architecture and a description of the different parts:

Crazyflie Python client input device architecture

Each backend is implemented as a single Python file in the directory /lib/cfclient/utils/inputreaders. When the application starts up each of the files are picked up and initialized, so for anyone that wants to create their own backend it’s pretty easy. A list of successfully initialized backends is created. Once the application is started a scan of the input devices will be requested. Each of the backends will do it’s own scanning and together a big list of available devices will be created. Each of these implement a specific API for opening, closing, scanning and reading the device by using their respective backends. The higher layer (Input) now has a list of available devices that it can open and read. But to make sense of the data read from the devices a mapping needs to be created to set which axes/buttons effect what parameters. There’s a number of parameters that can be changed, the main ones being roll/pitch/yaw/thrurst for controlling the Crazyflie. In order to make the mappings as flexible as possible each mapping has a scale and offset. It’s also possible to split axis, so two axis on the device can effect the same parameters (like having yaw on bumper buttons). Normally (for PySDL2 and linuxjsdev) all axis are between -1 and 1 and buttons are either 0 or 1. But using the mappings it’s possible to have other values, like for the LeapMotion. When the LeapMotion is read it return the roll/pitch/yaw/height as read from the device. Using the mappings offset and scaling these values are transformed into usable values for roll/pitch/yaw/thrust. Here’s a step by step walkthough of how a device is read:

• Input: Each 10 ms the open device is read
• InputDevice: Asks the backend for reading the device
• Backend: When read two arrays are updated, one for the buttons and one for the axes. If the device is event based all the events are consumed before updating
• InputDevice: Takes the raw values from the backend, iterates though them and updates a list of highlevel parameters accordingly. This returns a dictionary with keys like roll/pitch/yaw/thrust
• Input: Pre-processes the values of the parameters, like only calling callbacks when there’s a state shift (button 0->1 or 1->0), slew-rate limiting the thrust, dead-band and trimming
• Input: Calls special callbacks (such as alternative functions and emergency stop)
• Input: Calls callbacks registered for control data (roll/pitch/yaw/thrust). For this there are two registered callbacks, the UI and the Crazyflie object (crazyflie.commander.send_setpoint(…))

So how does this help the original problem of setting parameters from buttons? In this change we have also included two new buttons, alt1 and alt2. These can be mapped just like any other buttons in the configuration dialog. When these buttons are toggled (0->1 and 1->0) all the registered callbacks are called. The idea is not mapping them graphically to specific parameters, it’s for enabling users to easily (with one line of code) register for these and be able to act on them. For instance setting the LED-ring headlights on/off or changing the effect of the LED-ring.

When we are poking around in the code we are also looking at fixing some other issues, like how to handle when Bluetooth controllers go out of range (see this topic in the forum). We are hoping that everything will be finished and merged when the next release of the client. Also a big thanks to everyone that’s contributed code for the input reading, it’s made things a lot easier!

Today we also released new firmware for the Crazyflie 1.0 and a new Crazyflie Python Client. We have now fixed the client compatibility issues between the Crazyflie 1.0 and 2.0. We are also happy to report that next week the LED-ring and the Crazyradio PA should be back in stock.