deactivating a deck

[dominik.natter]

Hi guys,

I am currently performing tests with the Crazyflie's in two settings: once with and once without relying on UWB. So far I am simply mounting / unmounting the UWB deck to differentiate between the two cases. However, it would be more convenient to just disable the deck, even if it is still mounted. Is there a way to do so? (I am posting the question here and not in the Loco section as it might be the same for any deck)

I tried to change the parameter deck.bcDWM1000 in the cfclient, but I cannot change any of the variables within the "deck" group. (seems to be a read only parameter). Both the parameter loco.mode as well as the parameters kalman.robustTwr and kalman.robustTdoa just deal with which UWB to use, not whether to use it.
From my current understanding the UWB is included automatically in the estimator as soon as the deck driver is initialized. So blocking that initialization could be another way, but it does not sound very straightforward (e.g. I could change suppress it by hard-coding deck.bcDWM1000 == 0 in the driver initialization and then re-flash the drone).

I am looking forward to your input!

Best,
Dominik

[arnaud]

Hi,

There is unfortunatly no easy way to do that generically and, as you noticed, all "deck.*" parameters are read-only. They are only indicator of the current deck initialized, not a control.

What makes this hard is that the decks are initialized at startup, before the system has reached the "started" state and so before you can do anything with it. Also, there is no mechanism in place to stop anything: once a deck is initialized the only way to stop it is to reset the system.

The easiest I can think about would be to compile a version of the firmware that do not initialize the deck you do not want. You can for example filter decks by name in this loop and skip calling init (and then test in a loop lower down) for the deck you want to exclude: https://github.com/bitcraze/crazyflie-f ... .c#L56-L68. This is the simplest generic solution I can think about but it will require flashing the Crazyflie back-and-forth between experiments (which can be done without touching the Crazyflie so maybe it is a good compromise ...).

A more lps-specific approach would indeed be to block data from being pushed in the estimator. Unfortunatly this has to be done independently for twr, tdoa2, tdoa3. Adding a parameter to these files and an if around the function call that pushes data to the estimator would allow to soft-disable the update while the Crazyflie is running.

[dominik.natter]

Hi Arnaud,

thank you for the quick response! I will most likely go with one of your ideas, as they are less tedious and probably less demanding to the hardware than constant un-/mounting.

Maybe as a related follow-up: Imagine an autonomous mission, where the crazyflie might land temporally and after some time fly again, and it relies on the multiranger for obstacle avoidance during flight. In order to be as economical with the energy as possible I thought about disabling the multiranger deck in periods where the drone has landed temporally (because no obstacle avoidance is needed then). Judging from your second paragraph this will also not be easily possible, right? I assume one would again need to work with some workarounds, like reducing the laser frequency and range to its bare minimum. (Potentially this is a very hypothetical question, given that the multiranger deck might only draw a fraction of the power that the motors consume).

[arnaud]

Hi Dominik,

The multiranger would be quite easy to disable since it contains an i2c GPIO chip connected to all the ranging chip disable pin (this was required since they all start on the same address so they are started and their address is changed one-by-one at startup, thanks ST ...). This would require quite some change in the driver though to enable switching between active/sleep mode.

For a more generic solution, the Crazyflie contains 2 MCU: the STM32 as main MCU and the nRF51822 for radio and power management. The nRF chip is able to switch OFF the STM side as well as all connected decks. This will make the Crazyflie consume much less power. For even more power save it would be possible to put the nRF to sleep as well and to wake it up on a schedule or over the radio, but this is not implemented at all yet (fun fact: the nRF is always ON in the Crazyflie, is is in deep sleep when you switch off the Crazyflie and is woken-up by the button. There is an option to wake it up from a deck pin as well).

There already is some radio packet to switch ON and OFF the STM side independently of the nRF: https://github.com/bitcraze/crazyflie-l ... py#L58-L66. There is no examples but this is done independently of a CF connection: you need to disconnect the Crazyflie and create a PowerSwitch object with the righ URI.

[dominik.natter]

Hi Arnaud,

as usual a very detailed answer from your side - thanks for this interesting information! The idea of switching off all decks might not be applicable in our case, as we'd like to keep some decks alive, but it's certainly interesting for the community. Should we ever progress in this direction will I come back with an update here.

[sonalford]

Hi Arnaud,

thank you for the quick response! I will most likely go with one of your ideas, as they are less tedious and probably less demanding to the hardware than constant un-/mounting.

Maybe as a related follow-up: Imagine an autonomous mission, where the crazyflie might land temporally and after some time fly again, and it relies on the multiranger for obstacle avoidance during flight. In order to be as economical with the energy as possible I thought about disabling the multiranger deck in periods where the drone has landed temporally (because no obstacle avoidance is needed then). Judging from your second paragraph this will also not be easily possible, right? I assume one would again need to work with some workarounds, like reducing the laser frequency and range to its bare minimum. (Potentially this is a very hypothetical question, given that the multiranger deck might only draw a fraction of the power that the motors consume).

A great idea, I still ask myself what would happen if the frequency and range of the laser were to be reduced to a minimum.