In that message I described the behavior of the low level commander packets. The assumption is that these packets are sent at regular interval to control the Crazyflie in real-time. The idea is that if you are controlling Crazyflie using these packet, the high level position and trajectory control is done outside, and so if there is no news from it for too long there is no way of knowing if it is still safe to follow the same setpoint and cutting power to the motor is the safest things to do
Are we able to change this?
It seems odd to me, that the crazyflie is not trying to hover in those cases. I mean it has all those sensors, so it should now, its at this or that height. Turning off motors at a height of lets say 3 Meters does not make sense to me.
The firmware is open source so everything can be changed
. Though, I do think that this needs to be solved at a slightly higher level. At this low level, the setpoints are sent directly to the control loop and the control loop has no way of knowing if the sensors are working correctly. So if you have a fly-away because of a misbehaving ranging sensor for example, trying to maintain altitude would result in the Crazyflie continuously flying away, cutting the motor as soon as contact is lost is however a much more sound default behavior.
I saw in the crazyswarm documentation:
goTo(goal, yaw, duration, relative=False, groupMask=0)
Move smoothly to the goal, then hover indefinitely.
How did they achieve this?
The goto command is implemented using the high-level-commander. It is a module running in the Crazyflie firmware that controls the Crazyflie using low-level commander commands. Once you activate the high-level commander, it will send low level commander packets at regular intervals and so you will never be able to hit the low level watchdog. Of course this makes the Crazyflie become much more autonomous and depending of the context you might want to have a way to send a radio packet to stop the motors (we have built an e-stop button that broadcasts the emergency stop packet on a couple of channel at the office, I could document it if people are interested of building something similar).
So I see two way forward if you want to achieve higher level of autonomy when loosing radio communication:
- Use the high-level commander. It can be used from Crazyswarm as well as from the python Crazyflie lib
- Make an app that runs in the Crazyflie and implement different behavior when the connection is lost. For example in that thread, an app that makes the Crazyflie softly lands when the connection is lost has been implemented:
viewtopic.php?p=20729#p20729
There has been talk about having these kind of advanced behavior integrated in the Crazyflie firmware. I still do not think it should be activated by default, but it is certainly something that would be interesting to have as an integrated option in the firmware.