We are rebuilding the input device arch a bit (branch here) to support multiple backends. Using this you can seamlessly switch between different devices, even if they have different drivers. For example you could have one LeapMotion and two gamepads, and switch between them while the client is running. It will also be easy to create new backends, like an UDP or Kinect backend. These will automatically be picked up and initialized when the application starts if it's placed in the /lib/cfclient/utils/inputreaders.
While working on this we also started thinking about other issues we might want to solve while we are digging around in the code. One such issue is the reports about flyaways that we have seen when users fly using wireless controllers. After doing some testing we have seen that when unplugging the USB cable on Windows/Mac OSX will set all the axis to 0, but not on Linux (see this issue). But when using Bluetooth controllers we have a problem. The issue is that this doesn't seem to be detected on an OS level. The BT device will probably be disconnected, but after a long timeout. But until we hit this timeout the application will still get the latest values from the device (as given by the OS) and this might cause problems. One solution that we have tested before (and removed) was using the variance off all the axis to detect a "disconnect". The though is that while flying you constantly change the axis correcting for drift and so on. So reading all the axis (even those not mapped) and calculating the variance we should clearly see when we aren't reading the device any more. The problem we ran into was that some controllers are pretty stiff (like the XBox 360) and then it's sometimes possible to keep exactly the same input during a few seconds, which will then be detected as a "disconnect", set all the axis to 0 and the Crazyflie will drop out of the sky.
To make the situation more complex we also have the mobile devices. Even if we could figure out how to detect disconnect on all OSes (and versions) there's still the mobile clients we have to take care of. The best solution would be to have code on the Crazyflie to detect this, but since we will still get commander packets it won't be seen as loosing connection, it will be business as usual. Another idea might be to check the values of each incoming commander packet, if we get a certain amount of packets in a row with the same data we start lowering the thrust. If there's a real problem with the input device not working any more (like a wireless controller loosing the connection) this effect will be wanted. If the user still has control then the lowering of the thrust will trigger the user to correct it and the commander packets will change. There might be an overshoot here, but it's the best suggestion we have so far (we came up with it while writing this text
). This has to be tested though, as with a lot of designs it might look good in theory but not work out when tested...Does anyone else have any good ideas on how we could solve this issue? Any input would be appreciated