Hover instead of turning off motors

[whizzle]

From this thread: viewtopic.php?f=10&t=3486

If you are using low level commander setpoint and there is no packet for more than 1/2 seconds it is indeed possible to get into trouble: after 1/2 seconds the Crazyflie will try to level its attitude and after 1 second it will cut the motors.

This is not related to the hardware watchdog that guard the software and would reset the micorocontroller, this is a protection mechanism in the commander implementation so the Crazyflie should not reset, but it can make it physically crash.

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.

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?
Kind regards

[arnaud]

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.

[whizzle]

Dear Arnaud,

thank you for your detailed reply.
Can you please tell me if I understood your answer correctly?
Scenario 1:
Crazyradio -------------- Crazyflie low-level commander. Cuts motors due to safety, cause low-level commander does not know anything about sensors.
Scenario 2:
Crazyradio -------------- Crazyflie High-Level commander (e.g. goTo commands). Knows about sensors and e.g. its position. Does send low-level commands on-board (not via crazyradio?) to the low-level commander.

I think it is the high-level commander, which we would like to use but due to lack of knowledge we use the low-level commander.
Are there any examples? I bet yet - will search for it.
EDIT: one example: https://github.com/bitcraze/crazyflie-l ... h_level.py
Is it possible to send trajectories to the crazyflies during flight?
Is it possible to mix trajectories with e.g. goTo commands?

Kind regards

[arnaud]

Yes you understood correctly. The high-level commander is indeed sending low level setpoint from within the firmware, there is a priority mux implemented that allows to switch to the higher priority active setpoint sources automatically.

Both sending trajectory during flight and mixing high-level commands should be possible. The mixing is the usual way high-level commander is used (take-of, then goto to a start position then start a trajectory is a common sequence). Usually sending a trajectory is done when the drone is on the ground, so that it is fully primed when flying, but this is not as far as I know a hard requirement.

One interesting thing to note as well is that you can send a new goto before the previous one has completed, this allows to easily fly smooth trajectory: the goto command plan to reach the target point and stop there, if you send a new goto while the Crazyflie is moving, the planning will start with the current position and velocity as starting state.