If the watchdog is kicking-in because of an assert it would be useful to save that in ram and display it on the console after restarting.

There're two constants defined in drivers/interface/motors.h:

#!c

#define MOTORS_TEST_ON_TIME       M2T(10)
#define MOTORS_TEST_DELAY_TIME    M2T(50)

These constants are used in drivers/src/motors.c:

#!c

  motorsSetRatio(MOTOR_FRONT, MOTORS_TEST_RATIO);
  vTaskDelay(MOTORS_TEST_ON_TIME);
  motorsSetRatio(MOTOR_FRONT, 0);
  vTaskDelay(M2T(MOTORS_TEST_DELAY_TIME));
  motorsSetRatio(MOTOR_RIGHT, MOTORS_TEST_RATIO);
  vTaskDelay(M2T(MOTORS_TEST_ON_TIME));
  motorsSetRatio(MOTOR_RIGHT, 0);
  vTaskDelay(M2T(MOTORS_TEST_DELAY_TIME));
  motorsSetRatio(MOTOR_REAR, MOTORS_TEST_RATIO);
  vTaskDelay(M2T(MOTORS_TEST_ON_TIME));
  motorsSetRatio(MOTOR_REAR, 0);
  vTaskDelay(M2T(MOTORS_TEST_DELAY_TIME));
  motorsSetRatio(MOTOR_LEFT, MOTORS_TEST_RATIO);
  vTaskDelay(M2T(MOTORS_TEST_ON_TIME));
  motorsSetRatio(MOTOR_LEFT, 0);

As you can see, there're cases when M2T is called twice. Although, it's essentially multiplying by 1 with the current settings, it might strike back in some undefined future.

• Bitbucket: https://bitbucket.org/bitcraze/crazyflie-firmware/issue/8
• Originally Reported By:
• Originally Created At: 2013-06-04T05:18:58.320

Have you considered using LibK to provide harware abstraction layer?

https://github.com/mkschreder/martink

There is support for stm32, accelerometers, magnetometers, gyroscopes and many other devices. Also, the library is written to be very lightweight and exposes key functionality through generic interfaces that enforce modular design and high level of code reuse.

Would be nice to be able to store unit beside name and groups for log and param. For example acceleration is currently in g and rotation in degree/seconds

pm.c
vTaskSetApplicationTaskTag(0, (void*)TASK_PM_ID_NBR);
but in tasks.c
void vTaskSetApplicationTaskTag( xTaskHandle xTask, pdTASK_HOOK_CODE pxHookFunction )

Correct ?

When the CF2 enabled client tries to connect to the CF1 firmware it's assuming that the firmware will answer with the number of memories that is available. If this reply is not received the connection procedure will be blocked on the cfclient and it will never enter the connected state.

An answer should be added that reports 0 memories available.

Found in b7154ae.

Steps to reproduce

1. Power on CrazyFlie (tested with CF2 but applies to both).
2. Connect over Nordic.
3. Reset CrazyFlie STM32 CPU. Easiest way: use button on debug breakout.

Expected results

CrazyFlie STM32 comes back up. Maybe connection drops, worst case.

Actual results

STM32 hits assert, cannot reestablish connection, must be power-cycled.

Diagnosis

There's a race condition in queue creation in radiolinkInit. The syslink task is started before the queues it uses (particularly crtpPacketDelivery) are created. Since the syslink task is higher-priority than the task that creates it (system), it immediately preempts.

Normally, no data is available at the nRF UART, and it blocks and returns to sleep before touching the CRTP queues.

However, if the connection is up, the nRF may have a message ready -- in which case syslink tries to process it before initialization has completed.

Because the task that does most of the initialization (system) is so low-priority, there are probably other bugs of this same shape lurking.

Hi,

I currently have three crazyflies. I have recently just flashed all three the Crazyflie 1.0 using the latest firmware from: https://github.com/bitcraze/crazyflie-firmware

1 out of the 3 starts up fine and only makes the 'start-up' melody once. The 2/3 play the sound 'start-up' melody twice, about 1 second apart.

Where I had:

1. cd directory of frimware
2. make PLATFORM=CF1
3. cload PLATFORM=CF1

It updates the firmware fine, and I am able to connect to the crazyflie via the client.

• Plays start up melody twice
• When I add thrust there is no response

EDIT: This is what I have printed from the console tab:
IMU: MPU6050 I2C connection [OK].
IMU: HMC5883 I2C connection [OK].
IMU: MS5611 I2C connection [OK].
MPU6050: Self test [OK].
HMC5883L: Self test [OK].
MS5611: Self test [OK].
SYS: The system resumed after watchdog timeout [WARNING]

Has it got to do the with watchdog timeout?

The LED-ring "Tilt" effect is not correctly aligned, see this forum thread for more info.

Hey Bitcraze,

Thanks for the great work on the CrazyFlies. Wanted to just recommend that on this page: http://wiki.bitcraze.se/projects:crazyflie2:development:ota a prerequisite is added (with a link?) to http://wiki.bitcraze.se/projects:crazyflie:devenv:index#setup_on_ubuntu_1304. Took me some time to find and so maybe a link might help others.

Also please let me know if there's a better place to provide feedback for the wiki!

Best, Pete

Using headfree mode front is always in the same direction (on the yaw), even if the Crazyflie is rotating. This makes it a lot easier for new users to fly around. This functionality should be controlled using a parameter so hosts can easily switch it on/off.

This is similar to #26. Currently the code offers no guidance on what the meaning of the values outputted are. Meanwhile other values are defined at least somewhat.

If i put too long Strings in the DEBUG_PRINT() the CF freeze somewhere inside this function (can't see without JTAG).
After Connection with the Client the CF continues, but with bad Printout formatting.

• Bitbucket: https://bitbucket.org/bitcraze/crazyflie-firmware/issue/5
• Originally Reported By: Sascha Heymann
• Originally Created At: 2013-05-14T00:25:32.881

The eSky ET6i transmitter has not only two joysticks and a power on button, it also has three switches and two turning knobs.

Switches:

• could be used to arm/disarm the quadcopter
• Change mode: Easy (low max. pitch/roll/yaw) and Advanced (user defined max. pitch/roll/yaw)
• Lock heading
• Lock height
• turn on Land mode (langing slowly to ground)

Knobs:

• Change max pitch&roll
• Set max speed in %

• Bitbucket: https://bitbucket.org/bitcraze/crazyflie-firmware/issue/12
• Originally Reported By: Mathias
• Originally Created At: 2013-07-03T12:08:29.220

The CF2 firmware should do some sanity checking before allowing to start the motors. If, for example, the PS3 controller is not started but only inserted, the thrust value might be stuck at 100%. If one then connect to the CF2 it will start immediately with thrust at 100%, resulting in a violent crash. It would be preferable to have an arming procedure, for example requiring 0% throttle and neutral stick input before the firmware allows the motors to start.

CMSIS-DSP is a dsp (math) lib optimized for cortex-M and distributed under BSD license. We should add it to the build once the cf1-cf2 merge is completed.

Implementation of I2C2 interface (expansion port) is incomplete. I2C isn't working for peripherals connected via the expansion port. I2C2 write and read commands fail since the interrupts most likely aren't implemented completely - see nvic.c, lines 232 and 237:

https://github.com/bitcraze/crazyflie-firmware/blob/master/drivers/src/nvic.c#L232

Forum thread:
http://forum.bitcraze.se/viewtopic.php?f=6&t=823&start=20

Found in firmware commit b7154ae.

Steps to reproduce

1. Set up Crazyflie with released version of Python client, connected over wireless or USB (doesn't matter).
2. Create a log configuration containing a large-ish amount of data, e.g. motor.m1 - motor.m4 and stabilizer.{pitch,roll,thrust,yaw}.
3. Activate it in the Plotter tab.

Expected results

The data I asked for shows up (best case).

An error is reported (worst case).

Actual results

The Crazyflie's failure lights come on, signalling that something onboard has failed. All air-to-ground telemetry halts, but ground-to-air control authority is retained.

Diagnosis

If the client sends a sequence of log ops that will construct an overlong packet, the firmware happily follows the instructions. This ripples out in two directions:

• It eventually kills off the crtpTxTask,which hits an ASSERT (hal/src/radiolink.c line 159).
• It overruns the buffer in the worker task, smashing its stack and leading to undefined further behavior.

The timestamp of logblocks overflows and logs in nanoseconds rather than milliseconds as stated.

Attatched file is a patch to fix this since access to Pull request section is denied by bitbucket.
Furthermore the patch changes the timestamp to count from the start time of the logblock.

• Bitbucket: https://bitbucket.org/bitcraze/crazyflie-firmware/issue/18
• Originally Reported By: Simon Rasmussen
• Originally Created At: 2013-10-01T16:01:47.284

The timeout for shutting down the Crazyflie down due to inactivity is based on when the last commander packet was received, not when the last radio activity occurred. So if someone would use the Crazyflie only for logging (and not send any commander packets) the Crazyflie would shut down when this timeout is reached.

The timeout should instead be based on the last radio activity.

• Bitbucket: https://bitbucket.org/bitcraze/crazyflie-firmware/issue/17
• Originally Reported By: Marcus Eliasson
• Originally Created At: 2013-09-19T14:41:51.938

The TOC CRC calculated in the firmware doesn't seem to take the variable type into account. Just changing the type of a variable still gives the same CRC.

• Bitbucket: https://bitbucket.org/bitcraze/crazyflie-firmware/issue/20
• Originally Reported By: Marcus Eliasson
• Originally Created At: 2013-12-18T15:51:48.891

The Crazyflie radio supports 32 bytes packets however this line limits the max packet size to 31: https://github.com/bitcraze/crazyflie-firmware/blob/crazyflie2/modules/interface/crtp.h#L33

When the CRTP data size is set to 31 (to send 32 bytes packet), 32bytes packet are dropped somewhere. This needs to be fixed.

The delta time in the pidUpdate function is hard coded and wrong. This should be fixed and it will affect the I-term gain which could be a problem for people that has tuned their PID them selves.

• Bitbucket: https://bitbucket.org/bitcraze/crazyflie-firmware/issue/16
• Originally Reported By: Tobias Antonsson
• Originally Created At: 2013-07-31T16:12:28.686

Hello,
Was doing some code review and noticed this:

      if (rollType == RATE)
      {
        rollRateDesired = eulerRollDesired;
      }
      if (pitchType == RATE)
      {
        pitchRateDesired = eulerPitchDesired;
      }
      if (yawType == RATE)
      {
        yawRateDesired = -eulerYawDesired;
      }

Here. Is the difference in the yawRateDesired calculation on purpose?

When running CRTP over USB we do not detect when the USB has been disconnected and stop sending data (can be seen on red LED). This should be detected and we should switch back to radio.

Reproduce:

1. Start Crazyflie 2.0 and Crazyflie Python client
2. Connect to the Crazyflie 2.0 using uUSB (URI usb://0)
3. Make sure the connection succeeds (the UI should show logging data) then disconnect the uUSB cable
4. The Crazyflie Python client will detect the disconnect, but the Crazyflie 2.0 will continue to send data (red LED blinking) and it's not possible to connect to it again via the radio.

Currently the Yaw is controlled in rate mode. There should be a parameter allowing to switch to absolute mode (with 0 degree being the take-off position).

One use case is to allow for controlling the yaw from an android phone orientation.

• Bitbucket: https://bitbucket.org/bitcraze/crazyflie-firmware/issue/15
• Originally Reported By: Arnaud Taffanel
• Originally Created At: 2013-07-30T06:49:43.409

I updated to the latest code and I get this error when I do a cold boot:

/crazyflie-pc-client/lib/cfclient/ui/dialogs/bootloader.py", line 330, in readConfigAction
channel = GuiConfig.get("default_cf_channel")
TypeError: unbound method get() must be called with GuiConfig instance as first argument (got str instance instead)

It looks like the method is expecting the object first.

Here is the version I updated to:
changeset: 186:559c654235b0
tag: tip
parent: 182:a7a5d0fdbdcb
parent: 185:df4d95d2cd6c
user: Marcus Eliasson [email protected]
date: Thu Jul 04 11:37:15 2013 +0200
summary: Merge of cfheadless branch to default (Closes #59)

• Bitbucket: https://bitbucket.org/bitcraze/crazyflie-firmware/issue/13
• Originally Reported By: Jonathan Byrne
• Originally Created At: 2013-07-05T16:13:23.108

After the Crazyflie is powered on it will start a gyro calibration function. This functions waits for the Crazyflie to become stable/still and then takes the gyro bias. It seems however that if you move the Crazyflie intensely during this phase it can falsely detect that it is stable/still and take a wrong bias.

• Bitbucket: https://bitbucket.org/bitcraze/crazyflie-firmware/issue/2
• Originally Reported By: Tobias Antonsson
• Originally Created At: 2013-05-03T11:58:18.671

When connected with USB the watchdog kicks-in and restarts the Crazyflie 2.0.

Hello,
More code review!

I noticed this

      // 100HZ
      if (imuHasBarometer() && (++altHoldCounter >= ALTHOLD_UPDATE_RATE_DIVIDER))
      {
        stabilizerAltHoldUpdate();
        altHoldCounter = 0;
      }

It seems like this should only be done when altHold == 1 like here? Please let me know if this is incorrect.

As of the 2015.08 release the Crazyflie 2.0 sometimes freezes randomly.

When dropping quickly in altitude or when switching from going full positive roll/pitch to full negative roll/pitch (or vise verse) the Crazyflie will become very unstable and wobbles.

This has been noted in the forums: http://forum.bitcraze.se/viewtopic.php?f=11&t=264

• Bitbucket: https://bitbucket.org/bitcraze/crazyflie-firmware/issue/7
• Originally Reported By: Marcus Eliasson
• Originally Created At: 2013-06-03T14:08:20.619

When compiling from tarball (ex. downloaded from github release page) the version script should detect and use the version of the tarball (or fallback on no version). Currently it is trying to run mercurial which crashed when running on a system that does not have it:

  VTMPL version.c
Traceback (most recent call last):
  File "scripts/versionTemplate.py", line 55, in <module>
    identify = subprocess.check_output(["hg", "identify", "-nitb"])
  File "/usr/local/Cellar/python/2.7.8_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py", line 566, in check_output
    process = Popen(stdout=PIPE, *popenargs, **kwargs)
  File "/usr/local/Cellar/python/2.7.8_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py", line 710, in __init__
    errread, errwrite)
  File "/usr/local/Cellar/python/2.7.8_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py", line 1327, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory
make: *** [version.c] Error 1

Currently the Crazyflie 2.0 supports CRTP over USB, but the Crazyflie 1.0 doesn't. Since the CF1 has hardware for USB device and the data-lines are routed to the connector it's possible to implement.

With the merge of the CF1 and CF2 code-base the higher-level functionality for the USB (like CRTP switching radio/USB and USB protocol) could be reused, it's just the lower-level drivers that needs to be duplicated and adapted for the STM32F103 on the CF1 (basically this file).

Add an independent watchdog that is reset at idle level. If idle level is not running, and the watchdog is not reset, the STM32 will restart. This should prevent run aways in case of deadlocks or other scenarios of faulty code, when the motors are running.

Hi,

I would like to report that in some cases it is possible to (try to) fly while the Crazyflie is charging.

Since the Crazyflie is connected to the charger actual flight is tricky but I don't think it's recommended.

• Bitbucket: https://bitbucket.org/bitcraze/crazyflie-firmware/issue/4
• Originally Reported By:
• Originally Created At: 2013-05-11T14:21:19.476

The crazyflie AND the Esky transmitter has to be restarted to reconnect.

With this improvement the crazyflie should go into listen mode if there is no connection. Then only the Esky transmitter has to be restarted.

Important if CF is lost. Also to get a healthier ON/OFF - button.

• Bitbucket: https://bitbucket.org/bitcraze/crazyflie-firmware/issue/9
• Originally Reported By: Mathias
• Originally Created At: 2013-06-26T22:06:34.952

static CRTPPacket crtpPacket;
float pitch, roll, yaw;
uint16_t thrust;

pitch = ((packet[2]<<8) | packet[3])-PPM_ZERO;
if (roll<(-PPM_RANGE)) roll = -PPM_RANGE;
if (roll>PPM_RANGE) roll = PPM_RANGE;
pitch *= 20.0/PPM_RANGE;

should this be

pitch = ((packet[2]<<8) | packet[3])-PPM_ZERO;
if (pitch <(-PPM_RANGE)) pitch = -PPM_RANGE;
if (pitch >PPM_RANGE) pitch = PPM_RANGE;
pitch *= 20.0/PPM_RANGE;

• Bitbucket: https://bitbucket.org/bitcraze/crazyflie-firmware/issue/19
• Originally Reported By: vision dual
• Originally Created At: 2013-12-08T03:44:29.944

I have added some debug logging to my local mod of Crazyflie firmware and realized that sensfusion6UpdateQ gets a predefined dt=0.004 s (4 ms), but the actual delays between these calls are 8-10 ms.

I have a fix for that: https://bitbucket.org/krasin/crazyflie-firmware/commits/218bf25b6e28b42705636dd8bb0bcac0053c0c53

After the fix, Crazyflie is a bit more stable, which is not surprising, because the internal model now gets the right value of g constant (before that, the copter virtually had a higher gravitation).

If it looks fine, I will create a pull request (right now, I am failing to do that, because I have not figured out how to create a separate branch in Mercurial, and I already have a pull request in default branch: https://bitbucket.org/bitcraze/crazyflie-firmware/pull-request/9/fix-url-to-open-x-imu-algorithm/diff).

• Bitbucket: https://bitbucket.org/bitcraze/crazyflie-firmware/issue/14
• Originally Reported By:
• Originally Created At: 2013-07-26T05:15:13.021

When trying to communicate with a slave that doesn't answer the code is stuck in an infinite timeout loop. E.g. here.

Analysis:
The TIMEOUT is depending on a interrupt function but is also called from within a interrupt function and must therefore have higher priority. Problem lies in that now the FreeRTOS tick interrupt is doing this but this interrupt function must have the lowest priority so a redesign is needed.

Let's go with the following projects:

• Crazyflie firmware
• Crazyflie PC client
• Crazyflie electronics
• Crazyflie mechanics
• Crazyradio firmware
• Crazyradio electronics
• Bitcraze KiCad library

• Bitbucket: https://bitbucket.org/bitcraze/crazyflie-firmware/issue/1
• Originally Reported By: Marcus Eliasson
• Originally Created At: 2013-01-08T09:46:01.505

We should add pmState, canFly and self test status as loggable variables so the client can report back the status to the user.

• Bitbucket: https://bitbucket.org/bitcraze/crazyflie-firmware/issue/11
• Originally Reported By: Marcus Eliasson
• Originally Created At: 2013-07-02T14:27:40.501

If you have more than 5 variables length of a float in a log group this causes the client to tell you that it god something out of TOC

I think the max length for one log packet is reached and it should generate either a second log packet or deny this during compilation

• Bitbucket: https://bitbucket.org/bitcraze/crazyflie-firmware/issue/6
• Originally Reported By: Philipp Mohrenweiser
• Originally Created At: 2013-05-26T14:01:22.550

When running make all, I receive the following error

  LD    cflie.elf
/opt/local/lib/gcc/arm-none-eabi/4.7.2/../../../../arm-none-eabi/bin/ld: cflie.elf section `.bss' will not fit in region `RAM'
/opt/local/lib/gcc/arm-none-eabi/4.7.2/../../../../arm-none-eabi/bin/ld: region `RAM' overflowed by 1608 bytes
collect2: error: ld returned 1 exit status
make: *** [cflie.elf] Error 1
rm version.c

• Bitbucket: https://bitbucket.org/bitcraze/crazyflie-firmware/issue/10
• Originally Reported By: Rob Smith
• Originally Created At: 2013-07-02T04:04:36.015

Move build scripts into the tools directory and update the version template to use information from the build tools

Currently the FPU is not enabled in the Crazyflie 2.0 firmware, this should be done to increase performance.

If a message is sent to a port that's not handled the firmware will just quietly discard the packet. Instead a "not implemented" packet should be sent back to indicate that the message was received, but the functionality is not available. This will make it easier to implement new ports on new platforms without causing backwards compatibility issues with clients.

We should change the default config to build with CLOAD=1 since most people are using the bootloader now.

• Bitbucket: https://bitbucket.org/bitcraze/crazyflie-firmware/issue/3
• Originally Reported By: Marcus Eliasson
• Originally Created At: 2013-05-10T10:46:27.500

The Makefile on master (for CF1) is missing one parameter for the updated cloader script. The last parameter stm32-fw should be added.