Sometimes, things just aren’t the way you would implement them. Today, I saw two features that shouldn’t be combined at all.
I’m currently working on a C# only backend for the drone. One thing to be done there is to implement the AT commands. It all went well until I discovered an interesting behavior of the AT*REF commands.
AT*REF is used for the following things:
- Start the engines and turn them off
- Set the emergency mode
The manual says the following:
- Bit 8 is used for emergency calls
- Bit 9 is used for starting and stopping the engines
- The other bits should not be used
- So, if nothing should be done, 0 should be sent to the drone
So I sent 0 to the drone, followed by 512. The drone did not start. But now, when I started the engines using the C++ library, whenever the drone took off, it moved to an extreme angle (to the left and forward) and crashed against the wall. Even a drone reset did not work.
Here’s what Parrot doesn’t tell you:
- AT*REF is also used to set trim values on your drone
- When sending AT*REF, you should not send zero, but a predefined default value plus zero
- Trim values are never reset, even if you reset the drone
The first point in the list is “just” bad design. Not mentioning anything about it in the developer manual is not really nice, either. But not resetting these values when the drone is reset is really horrible.
I couldn’t figure out how to reset the trim values programatically, by now. Anyway, thanks to the Parrot developer forum, here’s a way how to recover from bad “AT*REF” values:
- You have to telnet the drone (192.168.1.1:23).
- When there, move to /data
- Delete the two files “trims.bin” and “fact_trims.bin” in there
When you’ve done that, your drone should be able to fly straight, again.