Thoughts on pulling flight modes into the CRTP commander packet
Posted: Wed May 18, 2016 7:14 pm
Hey -- question mostly for the devs since it's a design question.
In my fork I've got support for "acro" aka "rate" mode as a primary flight mode - it's super useful for PID tuning, FPV flight, and flying a larger quad based on the bigquad deck. Before the stabilizer refactor last month, this was already supported through the parameter framework via two parameters, one for pitch and one for roll. Both had to be set to "RATE" instead of "ANGLE".
For my setup, I bypassed the parameter framework and added a field to the commander packet for "flightMode" which was either RATE or ANGLE for a few reasons:
1) The data contained in a CRTP packet is very closely tied with the desired flight mode.
2) When switching modes mid flight, I was wary of having to take a time out from my stream of CRTP packets to manage a stateful transition through the parameter framework (including acks and so forth). This might be an unnecessary fear but I didn't want to risk it.
3) It vastly reduces the complexity of the Tx. If my code was using the parameter framework, my transmitter would need to keep track of the mode it believes the crazyflie is in. If it got out of sync for any reason (like, if the crazyflie reboots) it would become complicated to recover without also rebooting the tx. The tx would also need code to understand how to use the parameter framework. I'm mostly using a Devo controller to fly, so the firmware should be as simple as possible. With this scheme, I can simply flip one of the switches and it starts sending a '1' instead of a '0' on every packet, switches the stick mix to a nonlinear mix, and life is good.
How would you guys feel about adding a uint16 or uint32 bitfield at the end of the CRTP protocol's commander packet instead of using the parameter framework? That way, all flight modes (rate/level, althold, poshold, future features) could all be safely switched between in-flight with minimal Tx complexity. I don't like breaking the convention of the parameter framework, but it seems like flight modes deserve to be an exception.
I'm going to do it either way for my own use -- is it something you'd want to see a pull request for? If so I'll plan to make it non breaking and put it behind an opt-in #define, etc.
In my fork I've got support for "acro" aka "rate" mode as a primary flight mode - it's super useful for PID tuning, FPV flight, and flying a larger quad based on the bigquad deck. Before the stabilizer refactor last month, this was already supported through the parameter framework via two parameters, one for pitch and one for roll. Both had to be set to "RATE" instead of "ANGLE".
For my setup, I bypassed the parameter framework and added a field to the commander packet for "flightMode" which was either RATE or ANGLE for a few reasons:
1) The data contained in a CRTP packet is very closely tied with the desired flight mode.
2) When switching modes mid flight, I was wary of having to take a time out from my stream of CRTP packets to manage a stateful transition through the parameter framework (including acks and so forth). This might be an unnecessary fear but I didn't want to risk it.
3) It vastly reduces the complexity of the Tx. If my code was using the parameter framework, my transmitter would need to keep track of the mode it believes the crazyflie is in. If it got out of sync for any reason (like, if the crazyflie reboots) it would become complicated to recover without also rebooting the tx. The tx would also need code to understand how to use the parameter framework. I'm mostly using a Devo controller to fly, so the firmware should be as simple as possible. With this scheme, I can simply flip one of the switches and it starts sending a '1' instead of a '0' on every packet, switches the stick mix to a nonlinear mix, and life is good.
How would you guys feel about adding a uint16 or uint32 bitfield at the end of the CRTP protocol's commander packet instead of using the parameter framework? That way, all flight modes (rate/level, althold, poshold, future features) could all be safely switched between in-flight with minimal Tx complexity. I don't like breaking the convention of the parameter framework, but it seems like flight modes deserve to be an exception.
I'm going to do it either way for my own use -- is it something you'd want to see a pull request for? If so I'll plan to make it non breaking and put it behind an opt-in #define, etc.