Hexiwear based GPS-AHRS for Nikon hotshoe

I have been working on the GPS-AHRS hotshoe for a while. The initial complete prototype was built around the Xadow platform. It is one of those continuous iteration projects, I wish someone puts me out of misery and brings out a COTS solution that is affordable soon.

I put the idea for the GPS-AHRS on the Hexiwear platform and received a free Hexiwear dev kit to built it with, a great deal. The Hexiwear has lots of toolchains for building projects with, including the Kinetis Design Studio from NXP and ARM MBed. This makes development on this platform a breeze. It also comes with a lot of sensors : barometer, gyro, accelerometer and magnetometer are all included. It has built in BLE for communications and a 16bit OLED screen. The only missing links are GPS, Nikon camera interface and a sensor fusion algorithm to obtain Euler angles/quarternions from raw motion data.

I already have working MBed code for sensor fusion and I have successfully tested reading all the motion sensors over I2C, so this should be easy to put together in the next few days.

I also compiled the stock firmware in KDS and did some small changes to show the Magnetometer data as part of the UI. This was relatively simple simply involved attaching a listener to one of the messages already being broadcast in the RTOS and a hacked up page to display the results. The results of this code can be seen below.

Nikon Hotshoe IMU with Xadow Modules

Hotshoe GPS-IMU in enclosure

We take lots of oblique images from a helicopter for our high-resolution 3D modelling service - Aero3Dpro. While photogrammetry and aerotriangulation lets us establish the position and orientation of these photographs afterwards from a relatively poor initial GPS and no IMU, just after capture there is no indication how well an area is covered from different angles. This can be a pretty difficult proposition anyway, especially in the presence of narrow allies and tall buildings. However with a good initial GPS-IMU one could build a low resolution model of the city literally on the fly.

All the components that get packed into the GPS-IMU

So I set about building a system that fills this niche, a camera hotshoe mounted system with a reasonably accurate GPS and IMU. There are already a lot of existing Xadow modules which satisfy the requirements of the system. I just had to cook up a few more as described in a previous post to cater for the unique requirements for interfacing with the camera and logging the data.

1. Xadow Barometer
2. Xadow 9-DoF IMU (can be combined with 1 above in the new 10-DoF IMU)
3. Xadow GPS  (the NMEA from the stock one does not agree with the Nikon so looking at a UBlox based version)
4. Xadow OLED
5. Xadow-M0 with MBed support
6. SPI to Dual-UART with SC16IS752, this is necessary because the only available UART on the Xadow-M0 is consumed by the GPS. We need 2 more UART's to send data to BLE module and camera at 4800 Baud.
7. Xadow BLE Module  
8. Xadow SD for logging locally in case BLE connection is patchy or a non-Nikon camera is being used which does not allow geotagging over UART.

A lot can be done when all these modules come together to party, the mBed code is available here. The android app for receiving the GPS-IMU data over BLE and predicting the camera foot print is still in the works. If anyone wants to take the app development up as an excercise I can provide the source. In conclusion I must thank Kris Winer for excellent IMU test beds and sample codes which helped me get started down this path.

GPS-IMU on hotshoe mount

After all the electronics came the enclosure and hotshoe attachment system. I designed something rough in blender using a trace of the stacked PCB's and got it locally 3D printed by 3D Hubs and Andrew Karas. This mounts nicely on the hotshoe, but the openings for reset, USB and cable to camera are not neat, a more aligned box is in the works.

Making MBed and Arduino compatible Xadow Modules (in Reflow Oven)

I have designed a long chain of Xadow modules by now, including right angled side chains. These include:

1. Xadow SD (CD4050) - Which allows using upto 32GB Micro SD Card and good read/write speeds due to the driver IC.
2. Xadow Serial (SC16IS750) - Which adds 1 UART and 8 GPIO ports, with jumpers to allow upto 4 modules in chain.
3. Xadow MultiSerial (SC16IS752) - Which adds 2 UART's (theres is not enough space for the GPIO's)
4. Xadow IO (PCA0539) - Which adds upto 16 GPIO ports using I2C

I have tried various suppliers to gather all the components, various PCB manufacturers as well as solder stencils from OSHStencils. Here is the breakdown of my experience so far in prototyping some very small single boards using SMD only components.

Chain of Xadow modules - GPS, Oled, 9-DOF IMU, Barometer, Dual-I2C Uart (Bluetooth), Xadow-M0, Xadow-SD (Left to Right)

PCB Manufacture:

DirtyPCB - They use SeeedStudio for manufacture and fulfilment, but get bulk discounts and I love the Gerber preview option, no extra charge black PCB's and option to get extra PCB's in a batch. I have got gold finished PCB's from them as well these look rather good.

SeeedStudio - My first test PCB's were made here.They also provide an assembly service and a library of commonly used parts. In most cases I have managed to get 80% of the PCB assembled in China with 20% hand soldered at home, mainly crystals and main IC's.

OSHPark - This is the made in the USA solution to Hobbyist PCB's. They produce PCB's in a signature purple colour, which I guess is a soldermask colour no serious industrial PCB maker wants. The ENIG finish PCB's look rather good. The preview function is also handy. However the DRU for checking PCB's is a bit strict in terms of clearance at the board edges, vias are not automatically tented and signals require greater separation leading to a low density PCB overall.

I am yet to try PCBPool and local Australian and New Zealand options, but they are beyond the budget of hobbyists. Once I start manufacturing my designs I shall surely give them a go. Local hackerspace recommended #hackvana and I had a great chat with them as well.

Component Sourcing:

AliExpress - Components are a bit hit and miss, had the wrong ones sent at one point. All the ones tested work.

EBay - Probably same sellers as AliExpress. Similar performance, no bad shipments so far.

Element14 - Next day delivery is amazing for quick prototyping. The part search system has improved a lot and they even have an Eagle library for most of the common parts.

Samples from TI, Maxim and ON Semi - Nothing is as good as free stuff delivered express. All parts are detailed with CAD models (albeit in .bxl).

Stencil:

OSHStencil - The holes are a bit too big, probably because I did not shrink the solder mask enough. Great otherwise.
Homecut - Cut on a Trotec laser Speedy 100 from Mylar and Kapton. The laser has a bi

t too much power, so pads need to be shrunk even more.

Overall it has been a great learning experience and I have probably spent more on research than I would have spent buying a hotshoe IMU like the solmeta off the shelf. However in the end the product does exactly what I would like it to do. Next step - find a suitable 3D printer on 3D Hubs and get an enclosure built, also complete the MBed code to make it all work.

Accurate positioning with UBlox Neo-6P and STM32

The Ublox Neo-6P provides raw clock phases and ephemeris suitable for use in post-processing based accurate positioning, or even RTK solutions using RTKLib.

STM32 with Eclipse was fairly messy to set up and depending on which version of GCC and CoreSupport libraries you use their are a few bugs to iron out. Used Code-Sourcery Lite toolchain, but compiled version did not behave as original firmware did. There are Eclipse based STM32 development commercial support from Atollic, and there were hacks to get the debugger Atollic packages working for ST-Link using the free options, but in the recent incarnation they have locked it down to TrueStudio only. I had to resort to OpenOCD for my debugging needs, it works like a charm with standard Eclipse settings, but I managed to nuke my STLink driver in the process and had to work hard to get it back.

Importing to GrafNav is fairly straight forward via the UBX converter, but it gives no indication on how it converts events, and you need sufficiently long logs to pick up any ephemeris. UBlox Receiver protocol is a must read for configuring the NEO-6P properly and monitoring the logs to ensure GPS lock. I am looking into the STM32 demonstration samples to add some more functionality to the project, including external interrupts from a camera for event marking and a GPS lock acquired status LED.

Where am I .... all the time

Okay lets start by clearly stating the futility of position, every defintion of position requires a reference frame. It would be pretty messy to define where I am relative to the centre of our galaxy at all times, the super-massive blackhole makes measuring time there pretty messy as well. I could define my position better in ECEF or ENU or in most cases Platte Carre. I set out to build a project which could define where I am at all times for the posterity and essentially keep a track of my spime. My spime is the only thing I have absolute natural rights to, everything else can be taken away and be subject to argument with sufficient legal juggling. Come to think of it even the personal spime is not inviolate, meh reading to much Hannu Rajaniemi. Android My Tracks is pretty good, but a phone sometimes feels like too many eggs in one basket, I don't want to leave it lying around in the car dash gathering sunlight.

The project is mainly based on a Seeeduino stalker board with a convenient Bee socket. I plugged the UBlox Neo-6M based GPS Bee there. Data logs go to a 2GB SD card and Lipo power is backed by a 1w solar cell. The GPS constantly spits out NMEA strings which get logged to the SD card as long as power and space is available. A log with 2 days worth of data took up 45Mb, so I can hold about 3 months of data. Unfortunately the 2000mAh battery died after 2 days of continous use, with some solar recharge while in use. Since the battery death, in order to prevent melt down in harsh sunlight and continuous use, I have added a USB charger option as a stop gap. This should hold the fort till I plug in the quartz/heat powered charger for use while hiking and the mini windmill for use while wind surfing. Eventually the SD card will blow off into star dust after I have had my fun and extracted and time and location of said fun, but hey SD cards are more expensive per-ounce than gold.

Testing uBlox GPS accuracy with Gumstix

The Gumstix Verdex comes with a GPS Expansion board which carries a uBlox GPS module spitting out data in NMEA format. It also has power supply for an active GPS antenna and I got a simple one to test things out with.

I had the antenna up on the ledge and logging for a few minutes. The whole thing points to the fact that unassisted GPS cannot really be trusted. Here are the logs graphed.

The GPS will need to be supplemented with assistance from CORS stations, IMU and possibly ultrasonic or laser range finders on board the flying UAV platform. We can try out a newer ublox with online almanac update features, but I doubt that performance will be much better.

Together with GPS the other power consuming part of a UAV system is the control radio. Thanks to the emerging Zigbee radios we can do with very low power receivers and great range from the XTend modules (advertised at 40miles). With these we can obtain near real-time high level control interfaces and synthetically coded channels.