can i turn off LEDS during automated flight?

[Newk]

Hi,
This question might be a bit strange, but we found it esthetically not fitting to have our drones shine colourful LEDs during their performance.
We think we should be looking at the code in crazyflie-firmware-master\src\hal\src\ledseq.c but maybe we got that wrong because our efforts on that did not show any results on the light-patterns it makes.

We basicly want the LEDs function normally during bootloader and self-test before... and then in the normal ready/flightmode we wan't nothing to light up at all. That should be possible right? We figure we just don't know how and where even.

Cheers,
Beorn

[arnaud]

Hi Newt,

for 3 of the LEDs the ledseq.c file is definitly the way to go. For the last LED, on the nRF51, it will require some software modification. This is something we have wanted to do for a while so I can help with that. What did you try and did not work?

As an alternative way of doing it, what about having a parameter called "blackout" or something similar that switch off all leds? That way you can set this parameter from ROS when you launch your system and you will not have to have a special firmware.

Best,
Arnaud

[Newk]

That "blackout" option would of course be awesome! Is this possible by tomorrow night?
(we have the presentation on friday, and want to do final rehearsals and tests on thursday)
If not on this short notice, some way of changing it in the firmware without being able to switch it from ROS wil also be okay.

We got help from a programmer with knowledge of C but not any of this system, so please bare with this :3
There is no comments for the changes too.

files attached

Greetings from our little team!

[arnaud]

I see that you have tried to modified the code (at least in the -3 file) but ledseq is a led sequencer: it runs sequences of ON/OFF events on the leds. So you could just modify these sequences and you would be done for the stm32 side:

Code: Select all

diff --git a/src/drivers/src/led_f405.c b/src/drivers/src/led_f405.c
index 67e05e8..4b6bd96 100644
--- a/src/drivers/src/led_f405.c
+++ b/src/drivers/src/led_f405.c
@@ -119,7 +119,7 @@ bool ledTest(void)
 
   // LED test end
   ledClearAll();
-  ledSet(LED_BLUE_L, 1);
+  // ledSet(LED_BLUE_L, 1);
 
   return isInit;
 }
diff --git a/src/hal/src/ledseq.c b/src/hal/src/ledseq.c
index 3107297..12e1ff3 100644
--- a/src/hal/src/ledseq.c
+++ b/src/hal/src/ledseq.c
@@ -60,7 +60,8 @@ static ledseq_t const * sequences[] = {
 
 /* Led sequences */
 const ledseq_t seq_lowbat[] = {
-  { true, LEDSEQ_WAITMS(1000)},
+  {false, LEDSEQ_WAITMS(1000)},
+  {false, LEDSEQ_WAITMS(1000)},
   {    0, LEDSEQ_LOOP},
 };
 
@@ -72,7 +73,7 @@ const ledseq_t seq_armed[] = {
 
 const ledseq_t seq_calibrated[] = {
 #ifndef CALIBRATED_LED_MORSE
-  { true, LEDSEQ_WAITMS(50)},
+  {false, LEDSEQ_WAITMS(50)},
   {false, LEDSEQ_WAITMS(450)},
   {    0, LEDSEQ_LOOP},
 #else
@@ -97,7 +98,7 @@ const ledseq_t seq_calibrated[] = {
 };
 
 const ledseq_t seq_alive[] = {
-  { true, LEDSEQ_WAITMS(50)},
+  {false, LEDSEQ_WAITMS(50)},
   {false, LEDSEQ_WAITMS(1950)},
   {    0, LEDSEQ_LOOP},
 };
@@ -111,25 +112,25 @@ const ledseq_t seq_altHold[] = {
 };
 
 const ledseq_t seq_linkup[] = {
-  { true, LEDSEQ_WAITMS(1)},
+  {false, LEDSEQ_WAITMS(1)},
   {false, LEDSEQ_WAITMS(0)},
   {    0, LEDSEQ_STOP},
 };
 
 
 const ledseq_t seq_charged[] = {
-  { true, LEDSEQ_WAITMS(1000)},
+  {false, LEDSEQ_WAITMS(1000)},
   {    0, LEDSEQ_LOOP},
 };
 
 ledseq_t seq_charging[] = {
-  { true, LEDSEQ_WAITMS(200)},
+  {false, LEDSEQ_WAITMS(200)},
   {false, LEDSEQ_WAITMS(800)},
   {    0, LEDSEQ_LOOP},
 };
 
 ledseq_t seq_chargingMax[] = {
-  { true, LEDSEQ_WAITMS(100)},
+  {false, LEDSEQ_WAITMS(100)},
   {false, LEDSEQ_WAITMS(400)},
   {    0, LEDSEQ_LOOP},
 };

As you can see in the diff, there is a bug for the blue LED that forced me to disable it completely in the LED driver.

For the last blue LED you need to disable it in the nrf51 firmware: https://github.com/bitcraze/crazyflie2- ... ain.c#L114