Crazyflie 2 with GPS
Re: Crazyflie 2 with GPS
Thanks, good to know Jack! Do you know it this is true for the accelerometer as well?
-
jackemoore
- Member
- Posts: 75
- Joined: Mon Apr 06, 2015 6:47 pm
Re: Crazyflie 2 with GPS
Hi,
Sorry for being a bit overzealous about my opinion on the compass calibration method I've implemented. Unfortunately, DJI is not open source and how they do things in their firmware is unknown to me. However, I do have considerable operational experience with their products. If your question about the accelerometer relates to what they have done in firmware, I'm only able to shed a little light on how they handle this sensor. The IMU sensors (accelerometer, gyroscope and compass) can optionally be calibrated using their Assistant Software on a PC, by placing their product on a gravitational level surface and then deriving xyz offsets after minimizing steady state variances. In the case of the compass, this static and level sensor calibration must then be followed by the spatial (horizontal and vertical) orientation calibration with respect to the gravitational force line.
Best regards,
Jack
Sorry for being a bit overzealous about my opinion on the compass calibration method I've implemented. Unfortunately, DJI is not open source and how they do things in their firmware is unknown to me. However, I do have considerable operational experience with their products. If your question about the accelerometer relates to what they have done in firmware, I'm only able to shed a little light on how they handle this sensor. The IMU sensors (accelerometer, gyroscope and compass) can optionally be calibrated using their Assistant Software on a PC, by placing their product on a gravitational level surface and then deriving xyz offsets after minimizing steady state variances. In the case of the compass, this static and level sensor calibration must then be followed by the spatial (horizontal and vertical) orientation calibration with respect to the gravitational force line.
Best regards,
Jack
Last edited by jackemoore on Tue Jul 05, 2016 1:51 pm, edited 1 time in total.
-
jackemoore
- Member
- Posts: 75
- Joined: Mon Apr 06, 2015 6:47 pm
Re: Crazyflie 2 with GPS
Hi,
I've submitted a pull request to crazyflie-firmware for replacing the gtgps.c module. If this is not what you recommend, please feel free to modify, remove or close it out. Or let me know what you want different.
Best regards,
Jack
I've submitted a pull request to crazyflie-firmware for replacing the gtgps.c module. If this is not what you recommend, please feel free to modify, remove or close it out. Or let me know what you want different.
Best regards,
Jack
-
jackemoore
- Member
- Posts: 75
- Joined: Mon Apr 06, 2015 6:47 pm
Re: Crazyflie 2 with GPS
Hi,
Branch gtgps-7 was created and contains the latest firmware updates. This commit contains the latest updates involving changes to function compassGyroBias() in compass.c. Gyro bias updates in imu_cf.c and thrust tilt compensation in controller_pid.c are included in this build. In order to enable gyro->yaw drift compensation using the calibrated compass, CFLAGS += -DGYRO_MAG_FUSION_ENABLE must be added to config.mk.
Perhaps another qualification regarding eeprom retention of compass calibration values is that bootloading firmware into the crazyflie that is something other than a gtgps-6 or a newer gtgps commit, will effectively erase the calibrations values. In this case, after downloading a gtgps commit, the compass will need to be calibrated once again.
I have not conducted any kind of thorough parametric analysis of the gyro->yaw performance, but here are a few of my recent observations.
The gyro->yaw appears to have a drift on the order of 5 or more degrees per minute when using the latest imu_cf2.c module from the github crazyflie-firmware-master. In the plotter tab picture, the compass.yawGyro (blue trace) is shown along with making a few manual crazyflie yaw changes. It also shows that the gyro->yaw has very little noise.
The compass (magnetometer) is a little noisy and is on the order of +/- 2.5 degrees without showing any drift. This is shown as compass.yawMag (magenta trace).
The fusion of yawGyro and yawMag is shown as compass.yawFusion (green trace). It's noise level is about +/- 1.5 degrees without drift. After a manual change in yaw, the gyro->yaw appears to lose some absolute value in the sensor fusion of gyroscope and accelerometer readings. This causes some adjustment period in the yawGyro & yawMag fusion process, but then is corrected.
This cursory examination, might lead to different conclusions, but one is that when the compass controller is available in the firmware and it has been properly calibrated, setting yawGyro equal to yawMag may provide a decent yaw measurement source for the crazyflie.
I'd be very interested in seeing comments from those much more knowledgeable about this subject.
Best regards,
Jack
Branch gtgps-7 was created and contains the latest firmware updates. This commit contains the latest updates involving changes to function compassGyroBias() in compass.c. Gyro bias updates in imu_cf.c and thrust tilt compensation in controller_pid.c are included in this build. In order to enable gyro->yaw drift compensation using the calibrated compass, CFLAGS += -DGYRO_MAG_FUSION_ENABLE must be added to config.mk.
Perhaps another qualification regarding eeprom retention of compass calibration values is that bootloading firmware into the crazyflie that is something other than a gtgps-6 or a newer gtgps commit, will effectively erase the calibrations values. In this case, after downloading a gtgps commit, the compass will need to be calibrated once again.
I have not conducted any kind of thorough parametric analysis of the gyro->yaw performance, but here are a few of my recent observations.
The compass (magnetometer) is a little noisy and is on the order of +/- 2.5 degrees without showing any drift. This is shown as compass.yawMag (magenta trace).
The fusion of yawGyro and yawMag is shown as compass.yawFusion (green trace). It's noise level is about +/- 1.5 degrees without drift. After a manual change in yaw, the gyro->yaw appears to lose some absolute value in the sensor fusion of gyroscope and accelerometer readings. This causes some adjustment period in the yawGyro & yawMag fusion process, but then is corrected.
This cursory examination, might lead to different conclusions, but one is that when the compass controller is available in the firmware and it has been properly calibrated, setting yawGyro equal to yawMag may provide a decent yaw measurement source for the crazyflie.
I'd be very interested in seeing comments from those much more knowledgeable about this subject.
Best regards,
Jack
Last edited by jackemoore on Mon Jul 18, 2016 3:39 pm, edited 1 time in total.
-
jackemoore
- Member
- Posts: 75
- Joined: Mon Apr 06, 2015 6:47 pm
Re: Crazyflie 2 with GPS
Branch gtgps-7 was revised and contains the latest firmware updates. This commit contains the latest updates involving changes
to function compassGyroBias() in compass.c. Gyro->yaw drift compensation has been disabled. The code computing drift correction in function compassGyroBias() has been simplified and appears more robust than the previous implementation. However, it appears that the couple of degrees of noise being applied to gyro->yaw is too severe and can cause yaw instability.
The corresponding plotter traces for yawGyro, yawMag and yawFusion for this update are shown below:
yawGyro is without drift correction as well as stabilizer.yaw (not shown). Further investigation is needed to see if the drift correction noise level, originating from yawMag, can be reduced to the current level of gyro->yaw.
Best regards,
Jack
to function compassGyroBias() in compass.c. Gyro->yaw drift compensation has been disabled. The code computing drift correction in function compassGyroBias() has been simplified and appears more robust than the previous implementation. However, it appears that the couple of degrees of noise being applied to gyro->yaw is too severe and can cause yaw instability.
The corresponding plotter traces for yawGyro, yawMag and yawFusion for this update are shown below:
Best regards,
Jack
-
jackemoore
- Member
- Posts: 75
- Joined: Mon Apr 06, 2015 6:47 pm
Re: Crazyflie 2 with GPS
Hi,
Branch gtgps-7 was revised and contains the latest firmware updates. This commit contains the latest updates involving changes to function compassGyroBias() in compass.c. Gyro->yaw drift compensation has been disabled in this commit. It can be enabled by setting CFLAGS += -DGYRO_MAG_FUSION_ENABLE in config.mk. The noise level on yawFusion (yawGyro & yawMag) has been lowered to the point that when enabled (gyro->yaw is set equal to yawFusion), it no longer disturbs the crazyflie yaw stability when flying. As mentioned earlier, gyro->yaw appears to lose a small amount of absolute value when the crazyflie is subjected to attitude dynamics, but the yawMag drift compensation appears to handle this.
One task on my list of things to investigate is to simplify compass calibration using the device controller. The current implementations requires three buttons or equivalent actuation's to communicate when to do a calibration, when to take readings of a full circle rotation of the horizontally held crazyflie, when to take full circle vertically orientated crazyflie readings, and finally when to calculate a new set of calibration parameters using these readings. One thought is to eliminate the extra buttons, detect switching of the position hold mode switch (on/off) 6 to 10 times in quick succession, use one or more of the crazyflie LEDs to indicate when to do the horizontal rotation, use a different LED indication when to do the vertical rotation, internally recognize when the full circles have been completed and then automatically calculate the calibration parameters.
Best regards,
Jack
Branch gtgps-7 was revised and contains the latest firmware updates. This commit contains the latest updates involving changes to function compassGyroBias() in compass.c. Gyro->yaw drift compensation has been disabled in this commit. It can be enabled by setting CFLAGS += -DGYRO_MAG_FUSION_ENABLE in config.mk. The noise level on yawFusion (yawGyro & yawMag) has been lowered to the point that when enabled (gyro->yaw is set equal to yawFusion), it no longer disturbs the crazyflie yaw stability when flying. As mentioned earlier, gyro->yaw appears to lose a small amount of absolute value when the crazyflie is subjected to attitude dynamics, but the yawMag drift compensation appears to handle this.
One task on my list of things to investigate is to simplify compass calibration using the device controller. The current implementations requires three buttons or equivalent actuation's to communicate when to do a calibration, when to take readings of a full circle rotation of the horizontally held crazyflie, when to take full circle vertically orientated crazyflie readings, and finally when to calculate a new set of calibration parameters using these readings. One thought is to eliminate the extra buttons, detect switching of the position hold mode switch (on/off) 6 to 10 times in quick succession, use one or more of the crazyflie LEDs to indicate when to do the horizontal rotation, use a different LED indication when to do the vertical rotation, internally recognize when the full circles have been completed and then automatically calculate the calibration parameters.
Best regards,
Jack
Re: Crazyflie 2 with GPS
You are constantly making progress, great to see!
What about making a calibration tab in the cfclient? This can be used to calibrate accelerometer and gyro later on as well. Could be inspired by this gui for freeimu.
What about making a calibration tab in the cfclient? This can be used to calibrate accelerometer and gyro later on as well. Could be inspired by this gui for freeimu.
-
jackemoore
- Member
- Posts: 75
- Joined: Mon Apr 06, 2015 6:47 pm
Re: Crazyflie 2 with GPS
Hi,
A new branch has been added to the repository. Branch gtgps-8. This new branch and new commit contains the latest updates involving changes to compass.c and small changes to commander.h and commander.c. The code change simplifies compass calibration using the device controller.
The prior implementation required three buttons or equivalent actuation's on the device controller to communicate when to perform a calibration, when to take readings of a full circle rotation of the horizontally held crazyflie in the horizontal plane, when to take full circle vertically orientated crazyflie readings in the horizontal plane, and finally when to calculate a new set of calibration parameters using these readings.
This new approach eliminates the extra buttons by detecting the switching of the position hold mode switch (toggle on/off) 5 times in quick succession (within a 5 second period). The M1 LED becomes a solid green indicating when to begin rotating the horizontally held crazyflie. After 350 degrees is detected. the the M1 LED turns a solid red indicating when to begin rotating a vertically held crazyflie. When internally recognizing the 360 degrees circle is completed, the calibration parameters are automatically updated. Then the M1 LED returns to its normal flashing red condition. Once the calibration procedure has begun and the M1 LED is a solid color, if necessary the procedure can be aborted by repeating the 5 times toggle of the position hold mode switch.
When the M1 LED is green, readings begin when the crazyflie roll and pitch angles are both less than +/- 25 degrees. When the M1 LED is a solid red, readings begin when the roll angle is more than +/- 65 degrees and the pitch angle remains less than +/- 25 degrees.
The original plan was to put the nose down (pitch -90 degrees), but a quirk in the current baseline firmware prevented this. Currently, the port side must be down or the starboard side must be down for the vertically held crazyflie horizontal rotation segment.
Two issues with the baseline crazyflie-firmware-master appear to be problem areas. {Issue #1} The stabilizer.roll is properly bounded by +/- 180 degrees, but the stabilizer.pitch appears to be improperly bounded by +/- 90 degrees. When the crazyflie pitch goes through the nose down (-90 degrees) or nose up (+90 degrees) orientation, the yaw angle goes crazy. Module sensFusion6.c is the source of this issue, but changes are not confirmed. This issue may already be noted in the forum under the topic “Adjusting Pitch, and Changing yaw and roll”. {Issue # 2} When the crazyflie is first started, system.c calls ledseqRun(SYS_LED, seq_alive); when the startup tests are passed. This affects M1 LED flashing red. Later imu_cf2.c calls ledseqRun(SYS_LED, seq_calibrated); when the imu is calibrated. This module fails to make a call ledseqStop(SYS_LED, seq_alive); before the new call which uses the same LED and color.
Best regards,
Jack
A new branch has been added to the repository. Branch gtgps-8. This new branch and new commit contains the latest updates involving changes to compass.c and small changes to commander.h and commander.c. The code change simplifies compass calibration using the device controller.
The prior implementation required three buttons or equivalent actuation's on the device controller to communicate when to perform a calibration, when to take readings of a full circle rotation of the horizontally held crazyflie in the horizontal plane, when to take full circle vertically orientated crazyflie readings in the horizontal plane, and finally when to calculate a new set of calibration parameters using these readings.
This new approach eliminates the extra buttons by detecting the switching of the position hold mode switch (toggle on/off) 5 times in quick succession (within a 5 second period). The M1 LED becomes a solid green indicating when to begin rotating the horizontally held crazyflie. After 350 degrees is detected. the the M1 LED turns a solid red indicating when to begin rotating a vertically held crazyflie. When internally recognizing the 360 degrees circle is completed, the calibration parameters are automatically updated. Then the M1 LED returns to its normal flashing red condition. Once the calibration procedure has begun and the M1 LED is a solid color, if necessary the procedure can be aborted by repeating the 5 times toggle of the position hold mode switch.
When the M1 LED is green, readings begin when the crazyflie roll and pitch angles are both less than +/- 25 degrees. When the M1 LED is a solid red, readings begin when the roll angle is more than +/- 65 degrees and the pitch angle remains less than +/- 25 degrees.
The original plan was to put the nose down (pitch -90 degrees), but a quirk in the current baseline firmware prevented this. Currently, the port side must be down or the starboard side must be down for the vertically held crazyflie horizontal rotation segment.
Two issues with the baseline crazyflie-firmware-master appear to be problem areas. {Issue #1} The stabilizer.roll is properly bounded by +/- 180 degrees, but the stabilizer.pitch appears to be improperly bounded by +/- 90 degrees. When the crazyflie pitch goes through the nose down (-90 degrees) or nose up (+90 degrees) orientation, the yaw angle goes crazy. Module sensFusion6.c is the source of this issue, but changes are not confirmed. This issue may already be noted in the forum under the topic “Adjusting Pitch, and Changing yaw and roll”. {Issue # 2} When the crazyflie is first started, system.c calls ledseqRun(SYS_LED, seq_alive); when the startup tests are passed. This affects M1 LED flashing red. Later imu_cf2.c calls ledseqRun(SYS_LED, seq_calibrated); when the imu is calibrated. This module fails to make a call ledseqStop(SYS_LED, seq_alive); before the new call which uses the same LED and color.
Best regards,
Jack
-
jackemoore
- Member
- Posts: 75
- Joined: Mon Apr 06, 2015 6:47 pm
Re: Crazyflie 2 with GPS
Hi,
A new branch has been added to the repository. Branch gtgps-9. This new branch and new commit contains the latest updates involving changes to sensfusion6.c The code change in function sensfusion6GetEulerRPY() corrects roll, pitch and yaw when roll or pitch nears +/- 90 degrees and when the crazyflie tumbles or flies upside-down.
It also facilitates performing compass calibration when the crazyflie is vertically held with the nose up or nose down. Before this code change, only starboard side down or port side up could actually be used. This commit does not change this limitation, but a future commit will take advantage of the modified Euler angles and not have such orientation restrictions.
In function sensfusion6GetEulerRPY(), the new code handles the conversion from quaternion to Euler angles when yaw hits the singularities near a +/- 90 degree pitch angle. This situation also known as gimbal lock, is handled specially. The pitch angle is now +/- 180 degrees instead of +/- 90 degrees. In addition, some numerical instabilities have been corrected when certain quaternion values are used within the arctan2(n,d) trigonometric function.
Not tested, but the new Euler angles should work better in the special cases the crazyflie tumbles or is flown upside down.
Best regards,
Jack
A new branch has been added to the repository. Branch gtgps-9. This new branch and new commit contains the latest updates involving changes to sensfusion6.c The code change in function sensfusion6GetEulerRPY() corrects roll, pitch and yaw when roll or pitch nears +/- 90 degrees and when the crazyflie tumbles or flies upside-down.
It also facilitates performing compass calibration when the crazyflie is vertically held with the nose up or nose down. Before this code change, only starboard side down or port side up could actually be used. This commit does not change this limitation, but a future commit will take advantage of the modified Euler angles and not have such orientation restrictions.
In function sensfusion6GetEulerRPY(), the new code handles the conversion from quaternion to Euler angles when yaw hits the singularities near a +/- 90 degree pitch angle. This situation also known as gimbal lock, is handled specially. The pitch angle is now +/- 180 degrees instead of +/- 90 degrees. In addition, some numerical instabilities have been corrected when certain quaternion values are used within the arctan2(n,d) trigonometric function.
Not tested, but the new Euler angles should work better in the special cases the crazyflie tumbles or is flown upside down.
Best regards,
Jack
-
jackemoore
- Member
- Posts: 75
- Joined: Mon Apr 06, 2015 6:47 pm
Re: Crazyflie 2 with GPS
Hi,
As of July 11, 2016 the map used in GpsTab no longer works. The provider MapQuest says they don't do maps anymore, but use Mapbox. An interim workaround to crazyflie client source code involves changes to module map.js.
The url in the L.tileLayer section of code 'http://otile{s}.mqcdn.com/tiles/1.0.0/osm/{z}/{x}/{y}.png?x' can be replaced with 'http://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png'. And the "attribution: ... ," and "subdomains: ... ," portions removed leaving only "maxZoom: 18,".
Best regards,
Jack
As of July 11, 2016 the map used in GpsTab no longer works. The provider MapQuest says they don't do maps anymore, but use Mapbox. An interim workaround to crazyflie client source code involves changes to module map.js.
The url in the L.tileLayer section of code 'http://otile{s}.mqcdn.com/tiles/1.0.0/osm/{z}/{x}/{y}.png?x' can be replaced with 'http://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png'. And the "attribution: ... ," and "subdomains: ... ," portions removed leaving only "maxZoom: 18,".
Best regards,
Jack