Crazyflie 2.0 with GPS

[t_walker_21]

Thank you for sharing your firmware.

[t_walker_21]

Jackemoore,

I have tried to compile your code within the Virtual Machine terminal by using the 'make all' command when I am in the correct directory. At first, it gave me an assembler message saying "fatal error: can't create bin/startup_stm32f40xx.o no such file or directory". So I copied the 'bin' folder from the original firmware, and pasted it in the folder with your firmware. Now it is saying "make execvp: ./scripts/print_revision.sh: Permission denied" recipe for target 'print_version' failed"

How did you get your code to compile?

[jackemoore]

Hi,

I have very little knowledge or know how about using VM, linux ubuntu, and the embedded links, resources, and special handling of the existing projects in the workspace. Also, the makefile appears to be linked to local git control. Loading a new project into the per-configured workspace is a bit of a mystery to me. I go into the projects folder and create a new folder for my new project (e.g., naming it cf2-stm-gps-ubx). Then I copy the existing crazyflie-firmware project in eclipse and paste it. Instead of using the default folder I unclick this and select the new folder just created in the projects folder. I then download the zip file from github (in this case
https://github.com/jackemoore/cf2-stm-gps.git in the gpsubx branch) using the firefox web browser which places it into the home download folder. After extracting the zip file in this folder, I copy the drivers and modules folders and the makfile module and paste them in the newly created project folder (cf2-stm-gps-ubx), which replaces the ones already there. Instead of the entire folders I could have just as easily only copied the specific modules mention in my earlier post. Going to the make target area in eclipse, use Make CLOUD which should build successfully (ignore the two warnings about DMA functions that are unused and at some point needs to be cleaned up). Then clicking Flash using radio to download the firmware. I haven't seen a step-by-step tutorial for the proper way to do this, but the above works for me.

[jackemoore]

Hi

I need assistance from crazyflie developers to help complete my current efforts in integrating an e-blox gnss receiver with the crazyflie 2.0. The m8 receiver breakout board (1.5 g weight) that I'm using doesn't have flash nor battery backup memory. Assistance data must be supplied to the receiver after switch on in order to substantially reduce the time to first fix (ttff). Such data is freely available online and I need help in collecting and making this available within cfclient.

U-blox is deprecating ebx-aid-* messages and switching to using ebx-mga-* messages, They now offer multiple gnss assistance (mga) services on network servers for m8 and future receivers. An access token is required to use this service, but it is free upon registration (there is mention of access tokens used by other clients on the internet and the one I tried worked as well).

U-blox offers example libMga source code (I have a copy) that's freely available (it's written in cpp) to use in windows or linus and handles the protocol with the servers and collection of ebx-mga-* binary messages. Adapting this example code to obtain time, position, ephemeris, almanac, etc. and making the data available within cfclient (either in python and/or leaflet) is what I'm looking for help for (initially, I prefer a windows environment). Of course, if the crazyflie developers have better things to do, see a better or preferred approach different from this, that would be understood/fine.

Supposedly, online data validity is on the order of 2-4 hours for ephemeris (ttff 3 seconds) or up to 35 days for almanac (ttff 5-20 seconds or longer under adverse signal conditions). Also, data is available for u-blox u7 or earlier receivers (ebx-aid-*).

In anticipation of somehow having assistance data available to the cfclient, I've created a new port where information about satellites, signals and messages can be sent over the crazyradio pa between the crazyflie and cfclient. From cfclient I'm able to read ebx-* messages from either a data file or from memory and transfer them to the cf2 and gnss receiver. I've looked briefly at using online gps yuma data, but this doesn't provide ephemeris which is required for a shorter ttff.

Thanks in advance for your answer(s).

[jackemoore]

Hi,

It appears that the u-blox mga online/offline services currently require the receiver to send messages back to the server before continuing to download assistance data. This may be a bit too demanding and possibly overload what the crazyflieradio is already handling. I'm waiting for a response back from u-blox about decoupling the online receiver requirement. Until then, I'm moving forward with generating time, position and almanac ebx-messages to download to the receiver after power-on. Without ephemeris data the ttff will be a little longer.

[tobias]

Great to hear that it is going forward!

I'm not totally sure what you are asking help with. The Crazyflie has the ability to power the backup memory in the GPS if that would help. You can do this by using the nRF51 output on the deck (expansion) port N_IO_1 and setting it high since nRF51 is always on. It can supply up to 5-10mA this way.

[jackemoore]

Hi

Significant interaction is required between the u-blox mga client online/services and their gnss/gps receivers. My initial assessment is the crazyradio may have trouble handling the workload that is required to support this and at this time don't propose further action with this client to obtain real-time ephemeris data.

From cfclient I'm now able in real-time to load (url to U.S. Coast Guard Navigation Center) current yuma almanacs for the gps salellites and pass this data via the crazyradio to the u-blox m8 gnss receiver. In addition PC system time and approximate reference position (lat, lon, alt) are also provided to aid the receiver. I'm now working to verify the expected ttff performance improvement under different signal conditions.

Sending data over the crazyradio has had some issues and caused adding a watchdog timer to detect lost crtp/syslink data packets expected at the cf2. In addition, some packet transfers have had very uneven time delays. Range is not an issue and I've yet to examine switching channels and data rates to attempt to mitigate noise problems. A good thing is I haven't seen any bad data packets.

Regarding the u-blox max m8 pico breakout board, the memory power is tied directly to the receiver power and I don't know how easy it would be to separate the two. However, using the nRF51 output is an excellent suggestion and worth investigating further. Thanks again for your idea.

Question: from the cfclient and/or cf2 side is it possible to query crtp about a packet that has not successfully been transferred? I'm unfamiliar with the crtp handshaking and what the cf2 & cfclient do when there is bad data detected, retries or there is an overrun condition.

[tobias]

We found a bug in the data transfer protocol which you might experience. It most often re-sent data when it didn't have to, creating time delays as you experience. Pull in that bug fix and it might work better.

Also by default the nRF51 timeslots BLE and Shockburst which lowers the bandwidth. Build the nRF51 firmware with "make BLE=0" and you will get better Shockburst bandwidth (and no bluetooth). Also set the air data rate to 2Mbit if you don't need very long radio distance to increase bandwidth.

If the communication works as designed the up-link (CR to CF2) data should be safe. It will retry until the data is sent (and ACK received) or it will drop the connection.

Do you have your code in a fork we can have a look at and maybe give you some pointers?

[jackemoore]

Hi

Thanks for the bug fix information. I initially tried only replacing __init__.py into my build and had a run time error 'param instance has no attribute', line 166 in function paramtoc_updated_cb(self). My build changes are a bit extensive, but clearly I need to do the reverse and map my build changes into the new bug fix build. Is the cfclient with bug fix only for Linux and if so, would it be possible to get a windows version?

I'm having trouble flashing my nRF51 change to turn on N_IO_1. In my VM Eclipse environment I modified the Makefile setting to S110 ?=0 and BLE ?=0. Then in Make Target I did a “clean”, “all(no BLE)” and “flash”. I held the CF2 power button on for 3 seconds waiting for M2 to flash before doing “the “flash”. The error I see is “open failed - in procedure transport and procedure init” What am I doing wrong? I'm trying to do the flash using radio. Do I need to use a cable? I tried a cable and it didn't work.

The V_BCKP pin on the M8 gps needs to be 3.0V and draws 100 uA so N_IO_1 should be sufficient. What is the voltage on this pin? If higher than 3.6V, I'll try a resistor voltage divider network to bring its voltage down a little lower.

[jackemoore]

Hi
Didn't have any success porting my changes into the bug fix build and running it on windows. Perhaps I need a bug fix build for windows to succeed. I then tried applying the 6 additions and 5 deletions from the “fixed resending bug #172” to my build. I'm still seeing some occasional packets arriving after my watchdog timeout of M2T(4000) while waiting for a packet to arrive. On average I'm seeing 2 of these delayed packets when sending almanac data comprising of 124 packets (75% of packets have length 29 bytes and 25% length 7 bytes). In addition, I'm experiencing on average 9 lost packets while sending the almanac data. I think I have code workarounds for the lost and delayed packets, but more testing is needed to verify this. The downside is the time it takes to send almanacs to the gps receiver.

Using the bootloader in cfcient I was able to load the stm32 and nRF51 bin files. However, when I tried including the nRF51 bin file generated using VM Eclipse all(no ble) build ,it failed with M2 led staying solid and unresponsive to the power on/off switch. Going back to nRF51 version 1.1 restored the cf2 to properly working. I would still like to turn on N_IO_1 and I'd appreciate any help to get a bin file that does this and works in CF2. By process of elimination I assume the output pin is enabled by “nrf_gpio_pin_set(PM_CHG_EN);” in pm.c. Also, I assume when enabled it should provide 3V.