I have the Crazyflie 2.0 running gps using the Titan-2 module. Firmware is in an advanced development stage (feasibility patchwork), but eventually hope to get a working position hold capability. Effort so far has been running the gps indoors without SBAS/WAAS corrections, and will soon be testing it outdoors with better visibility to the Galaxy 15, Telesat Anik F1R or Inmarsat 4F3 satellites that provide corrections over the western U.S. and hopefully begin to see 3D/DGPS position fixes.
Later the Crazyflie 2.0 with Titan_2 was tested outdoors, it auto synchronized with the Galaxy 15 satellite to obtain WAAS corrections and successfully produced a 3D/DGPS fix.
Best regards,
Jack
Last edited by jackemoore on Fri Apr 29, 2016 12:53 am, edited 2 times in total.
Hi,
I previously reported integrating the Titan-2 driver source code gtgps.c into the crazyflie-firmware 2016.02 (Feb 17) and into a different and newer baseline found in GitHub 2016.04 (Apr 18). Both are now running successfully in the Crazyfkie 2.0. In addition, the Titan-2 firmware on the prototype deck has been upgraded to add output binary mode in addition the standard NMEA mode. My next task will be to add binary mode processing into the gtgps.c deck driver.
One work-around that still puzzles me in trying to enable the deck driver, I saw messages on the Console Tab in cfclient like {Found 1 deck memory; Memory Error: wrong header ID; Deck 0 has corrupted OW memory; No driver will be initialized}. I was able to get around this by removing one pin between the prototype expansion deck and the Crazyflie circuit board (i.e. disconnected what the prototype deck expansion board was doing to pin PB8 (OW). Comments on this error condition would be appreciated. I assume a change to the prototype deck is one solution.
As the GT-GPS is only in prototyping stage we have not allocated any VID/PID for it and the OW memory is probably blank. However for these situation you can force a driver to start. That way you should not have to remove the OW pin.
Do you have a fork of the code on github so I can have a look and help out?
Hi,
I have a config.mk in “tools/make” directory, but the deck OW memory error occurs before the driver can be enumerated using config.mk and this error causes it to be bypassed. My understanding is the CFLAGS += -DDECK_FORCE=bcGTGPS loads a deck driver that has no memory. However, the prototype Titan-2 expansion board has circuity tied to pin PB8 OW. A snippet of my code that registers the driver is as follows:
I've looked but haven't figured out how to allocate a VID/PID and setup the OW memory that accepts the prototype expansion deck with U1 and U2 tied to pin PB8 OW. By removing the OW pin, the driver enumerates successfully (using config.mk).
Hi,
A few work in progress comments:
(1) My prototype GT GPS deck driver now includes Binary Mode processing of position fix data and data appears on the GpsTab in PC cfclient.
(2) The original delay of 500ms after a "uart1Init(115200);" baudrate setting can cause a timing problem in the receiver and the delay needs to be increased.
(3) When the Crazyflie 2.0 is turned off, the PB7 expansion pin (WKUP) cannot source enough current/voltage level when connected to the battery backup input on the GPS receiver (VBACKUP pin that preserves the GPS real time clock, last location, ephemeris and almanac data held in internal SRAM memory). This was commented on in some earlier posts (June 01-03 2015 Crazyflie 2.0 with GPS). At some point I'd like to investigate tying PB7 (WKUP) and PB6 (N_I01) together to see if their input pull up resistors will supply enough current and hold the voltage to at least 2.0V and above.
Best regards,
Jack
Hi,
Examination of the GT Gps Titan-2 module binary mode output looks like the altitude value is height above the datum (WGS-84) ellipsoid (in meters) rather than height above the geoid (mean sea level). I believe we require hMSL and I have asked GlobalTop to look into this.
Best regards,
Jack
I'm sharing my work-in-progress feasibility software code for adding an onboard GPS deck driver (for the GT Titan-2 GNSS module) and for a compass controller module (that processes measurements from the onboard magnetometer). These have been integrated into one of the latest commit releases for the crazyflie-firmware and that was downloaded from Github crazyflie-firmware-master 2016.05.12. Also provided are the changes made to the crazyflie client-python-master 2016.05.12 source code that are compatible with the firmware changes.
This work has been uploaded to "http://Github.com/jackemoore/New-GPS-Additions" and the README.md file provides a few clarifying comments. The individual source code modules themselves contain a few additional detail comments.
In the repository there are four folders, one set of two supports the firmware and the other set of two supports the client-python source code. The folders marked “changes” contain the modified modules in their respective holding folders. Only the modules actually changed are included. The folders marked “originals” contain copies of all those modules that were actually modified, but are the untouched originals. Modules that have not been modified in any way have all been excluded from the uploaded folders.
I'm hoping to get some feedback on the work to-date and possibly receive some recommendations to help expedite the next step and continued integration into the restructured position controller and position hold function.
Thanks in advance for looking into this work-in-progress effort.
Before attempting to adapt this project work to the position hold mode, the altitude hold mode section was used as a springboard. The motivation for this is three fold: (1) Evaluating horizontal position hold performance might be an easier task with the crazyflie already in altitude hold mode. (2) The current weight of the crazyflie with the GT Titan-2 expansion board is ~ 36 g and it was felt that the thrust method for maintaining altitude hold might be problematic. (3) Familiarity with the new restructured stabilizer code is improving, but still far from really appreciating the clever nuances of this excellent design work by Bitcraze.
The barometric altitude based method has been implemented in place of the thrust method. It appeared that in order to input vertical position from the sensor (modeAbs) there also needed to be input from the controller (throttle stick changes) via velocity data (modeVelocity). Not having found a way to do this in the existing code, a new mode was created (modeAbsVel). Once this was incorporated, a comparison between the existing method and the new method appeared to yield comparable results. Casual tuning of the pid position z-axis developed a new set of Kp, Ki, Kd values. Unknown is how much improvement remains possible with better tuning. Altimeter measurements are very noisy in the one meter region, The existing low-pass-filter appears to have a 3db cut-off frequency of 1 Hz. Additional filtering (e.g. 2 Hz fc) appeared to make the overall performance worsen.
For vertical testing purposes, two nylon threads evenly spaced 30 mm apart were attached to a floor plate, threaded though the crazyflie port and starboard mounting holes, and the ends of the threads attached to the ceiling (with a sponge bumper protector at both ends).
Initial testing was with a basic crazyflie without the gps on-board and the battery mounted on the underside of the control board. Qualitatively, the sensor-method compared favorable with the original thrust-base method. Having felt somewhat comfortable with this a crazyflie mounted with the GT Titan-2 expansion board was evaluated. Again, the battery was mounted on the underside. Initially, the thrust-based method failed to hold altitude. As expected the default thrustBase is insufficient. Switching to the altimeter-based method, the roll/pitch stability was poor. After seeing a recent forum post from “arnaud” regarding more aggressive pid tuning settings that can handle windy condition, these appeared to greatly improve the attitude performance after liftoff. The altimeter-based method seemed to work well, but some signs of attitude wind-up (Ki = 500) began to slowly crop up. Although there may be other explanations.
It should also be noted that a crazyflie weight of 36 g might be problematic, where the battery is unable to deliver enough surge current to keep the crazyflie stable when the battery voltage reaches 50%. In additon, the flight time on the battery looks to be very limited.
The work-in-progress firmware changes for all the above have been uploaded to the previously mentioned repository. The latest branch is gtgps-2 and soon to be gtgps-3.
Not sure any of this is of keen interest to anyone, but it's an update on progress to-date.
Best regards,
Jack
Last edited by jackemoore on Sun May 29, 2016 1:46 pm, edited 1 time in total.