Showing posts with label maker. Show all posts
Showing posts with label maker. Show all posts

Wednesday, February 15, 2017

There is Nodana...


For those of you who don't know about the 96Boards open-specification hardware platform, it's a design spec for single-board computers (SBCs) that enables SoC vendors to provide their hardware in a standard form factor for increased compatibility.  It's also an engaged community working together to develop applications, software, and mezzanine cards for this ecosystem.

96Boards now has 3 different specifications for 3 classes of application.  There's Consumer Edition (CE), with standardized breakouts for both high-speed and low-speed signals, USB ports, HDMI, and so on.  There's also the Enterprise Edition (EE), which is more for server and networking applications.  It's a larger and more free-form design, with a low-speed header, USB and Ethernet, minimum 1 GB DRAM or expandable SODIMM slots, and optional 1 - 16 x PICe.  Finally there's the brand new IoT Edition (IE) spec.  It's designed to be tiny in order to fit anywhere.

All of these specifications have variants that allow hardware developers to add extra bits to their boards, making this a very flexible way of standardizing the important parts of SBCs.

The big benefit is that you can unite developer communities accross platforms.  The mezzanine card or maker project developed for board A will be compatible with board B, and vice versa.  With support from Linaro, providing a common Linux ecosystem for these boards, not even software compatibility should get in your way.

My honest opinion is that this open specification is very cool.

Gumstix is a 96Boards Partner

Yep, we're in cahoots with the folks at 96Boards and Linaro to bring you compliant hardware.  The release of the AeroCore 2 for Dragonboard 410C was only the start.  At the same time, we added the 96Boards Mezzanine Connector module to Geppetto D2O's library so that users can design their own mezzos for other applications.  If you don't know what Geppetto is, you can learn more by going to the Meet Geppetto page, read my earlier posts, or go straight to and give it a try.

I did a demo for 96Boards OpenHours, hosted by Mr. Robert Wolff (@sdrobertw) and actually flew my MAV, using a Dragonboard and the AeroCore 2 live in my office -- complete with a visit from the "demo demon".  The whole thing's on YouTube.

...Only Joule

So for those of you who don't know, a little compute module was released last year with quite a lot of juice hidden under its heat dissipator. The Intel® Joule™ module delivers unprecedented compute power in a tiny package.  From its two 100-pin Hirose connectors pour USB 3.0, MIPI LVDS,  PCI Express, HDMI, and a lot of what you already expect from COMs and SoCs.  It also houses its own WiFi and Bluetooth hardware.  All with the power of a quad-core processor akin to the Core-I7s you find in your desktop PCs.

Surprise, surprise, Geppetto's got that too!  You can go in and build your own host board using the Intel module and harness most of what it has to offer.

So a Square Peg and a Round Hole Walk Into a Bar...

On one hand you have this fantastic open spec hardware platform [round hole].  In the other, this epic compute module [square peg].  "those will never fit together," you might say (in fact, one 96Boards community member did).  Well, we gumstixians are very resourceful.  And the spec doesn't restrict the SoC's architecture to ARM, that's just the expectation.  So what did we do?  We took all of the components that make the 96Boards Consumer Edition spec great, we wired it up to the Joule connectors, (tested it), gave it a name, and unleashed it on the unsuspecting masses.

And that is how the Nodana 96Boards Consumer Edition (96BCE) for the Intel Joule module came to be.  Here it is:

Gumstix Nodana Features

The Black Sheep

That's right, all you doubters.  Now you can test your 96Boards projects on a powerful 64-bit multi-core Intel chip.  It's the first of its kind -- the first non-ARM 96Boards device.  Take it for a spin and tell me about what you do with it.  You can order it at

x86 IoT Fun

Psst!  We are also taking the IE spec to this dimension.  Our Radium 96BIE board complies with the 96Boards IoT Edition specification and runs the Intel® Curie™ module.  A 32-bit Quark processor  in bed with an ARCv2 MCU, a 6-axis internal measurement unit (IMU) and an independently programmable Bluetooth controller. Check it out at

Friday, July 22, 2016

More on the Areocore 2 for Dragonboard 410C

 As you could probably tell from my earlier post, I'm pretty excited for  the new Aerocore 2 board.  I just posted a short video showing off the board's features and performance that you really should watch if you have any interest in MAVs, drones or swarms.  This board's got some awesome capabilities.

Check out the video and see for yourself:

Thursday, June 30, 2016

RTK Rover Project Chapter 4: Final Stages

Well it's time to wrap up the RTK project.  My rover is driving nicely. I now have a Pre-GO, Pre-GO PPP, WiFi antenna, 4x AAA battery pack and my motors connected to my Gumstix BBB Rover cape, And my Gumstix Pi Compute Dev Board is rigged with my Pre-GO PPP SMA and antenna, as well as its own battery pack.  I have not, sadly, finished my automated driving software, but that's going to be a little time-consuming, so I'll stick with what I've got.

The Plan

I am going to simultaneously track my rover with RTK, PPP and standard GPS as it circumnavigates one of the tennis courts.  I'll be steering it from my laptop, logging the raw datastream from the two GPS modules with the BBB and the RTK solution data by way of the RTKLIB Windows tools on my laptop.
Then I'll plot the data and share it in my next post.

Sadly, the skies aren't co-operating today so I'll have to put the experiment on hold until the weather clears.

The Hardware

Now that I have everything assembled for the final experiment, here's a manifest of the primary components I used and where you can get them:

This is what it looks like all put together:

There's only one GPS header on the Rover cape so I had to solder the cable for the second Pre-GO directly to the BBB connector header.  Now it looks like this:

The Software

You can check out the git repository at:

I'm only using RovCtl for this experiment, but I intend to finish my automation software somewhere down the road.


 I have to admit I've been testing my rover control software a bit more than necessary.  Honestly, how can you resist driving a little robot all over the
office, chasing co-workers to the coffee machine, etc.  For kicks, I taped a camera to the bot and recorded my shenanigans.

I think the BBB's batteries were running low.  There were a couple of moments when there was noticeable lag between command and response, but I still managed not to hit anything too hard.  With a full charge and some clear weather, we'll have this experiment wrapped up in no time.

Check out the video above to see how it did.

Up Next: Results!

Friday, June 17, 2016

RTK Rover Project Chapter 3: Rover

Well, I've taken a short break from RTKLib this week.  I spent my time preparing My BeagleBone Black and Gumstix BBB Rover cape for the arrival of my bot.  Sure enough, it arrived mid-week.  It's a substantial kit:

The Build

Unwrapping and assembling things is one of my favorite activities.  In short order, I had assembled the mechanical components and my rover was ready for the electronics.

 As an added touch, and because I absolutely hate these screw connectors, I jury-rigged this double-pitch right-angle pin connector for my PWM/analog input. And yes, that's yellow electrical tape holding the motor controller down.  I wasn't willing to wait for the recommended double-sided foam tape.  Seems to be working fine.  I might just add some mounting holes for it after this project's done.

The Code

I took some time to put together some test code and the start of a PWM library to get some wheels turning.  I haven't had the patience to comment it, but it's here.  Before hooking it up to the robot, I tested it out with some LEDs:

 Yep, they dim in response to my input.  I think it's time.  Of course the square wave output from the PWM has to be converted into an analog signal.  The manual for the Sabretooth 2x12 motor controller recommends a 10kOhm resistor and a 0.1uF capacitor like this:

No problem.

And the Test

Complete success.  Time to get data from the IMU and integrate my code into the RTKRover code.

NEXT TIME: Data, data, data.

Friday, June 10, 2016

RTK Rover Project Chapter 2: The Early Development Stages

I am working diligently on my RTK project and have hashed out a lot of the details.  I've made progress in software, my hardware is on the way, and some of the specifics have been hashed out.  Here's my progress.


RTKLIB is not a trivial API.  Coding an automated base-station / rover application from scratch would take more time than I can dedicate to this project.  So I have taken the two apps that pertain to my needs and have begun making modifications to them.

First off, I need a background communication channel for instructions from the base station and data from the rover.  The easiest way to do this, of course, is to set up a TCP socket.  Str2str, an app that takes the data stream from your GPS device, converts it into a universal format and redirects it, uses sockets to stream GPS data between rover and base, but its use is obfuscated away in the depths of the library and isn't configured for secondary data structures. Likewise with rtkrcv, the rover-based workhorse that interprets the SNR data to get a hyper-accurate fix.

What I've done using a very straightforward abstraction layer for the standard gnu-sockets library, Simple Sockets, is built a back-channel for data from the rover's IMU, as well as its precise coordinates (which I am well aware I could get for free from rtkrcv, but would have to cherry pick. Besides, I may as well retransmit it to where I want it since I need the second socket port anyway) to the base station, and for waypoints for the rover.

I also removed the console for rtkrcv. This won't be necessary as the base station will issue all the required commands to the rover.

The next step is to make this whole thing ARM-compatible and set up some makefiles.  The makefiles are easy, even if my format is a little naive.  I don't have a lot of experience in writing them so they're fairly verbose and don't use much in the way of macros or regular expressions.  Now that the build process is nicely automated, I need it to cross-compile.

There were a few compatibility issues, but most of them were solved by installing or updating glibc.  The worst transgressor of all was Simple Socket's use of vsprintf() to collect and format a list of arguments into text.  The problem is the function requires a list of arguments of arbitrary length.  something along the lines of:

foo(char* format,...)

I replaced vsprintf() with sprintf() and so far it hasn't broken anything (fingers crossed).

Now it's cross-compiling and running on both the BeagleBone Black and RPCM.  Next step is getting motor control and IMU data working.


A couple weeks ago, I ordered this robot chassis and this motor driver from The chassis was on backorder so my shipping date got pushed back but I got an email this morning and my equipment is en route.  I also grabbed some 4-cell AA battery cases and barrel connectors from DigiKey for my two boards and I have some NiMH and LiPo cells to choose from here in the office from previous AeroCore 2 tests, which will work well for powering the robot's motors.  I've considered adding IR proximity sensors for obstacle avoidance, but that's just icing so I'm going to skip it, at least for now.

The Plan

Here's what our autonomous robot will do. It will receive waypoints from the base station and, using the magnetometer, it will navigate to that waypoint.  As it moves, It will transmit its coordinates, including altitude, to the base station along with its heading and pitch from the IMU.

A motivated individual (potentially myself later) would be able to generate an accuarte 3D mapping of the terrain the robot traverses.  Kind of sounds like a good surveying technique.

Up next: robot and data test!

Friday, May 20, 2016

RTK Rover Project Chapter 1: RTK and RTKLIB

Not long ago I posted about getting the Pre-GO PPP GPS modules up and running on BeagleBone Black with our Gumstix BBB Rover cape.  Now that I have them working on both this and the Gumstix Pi Compute Dev Board, it's time to take the GPS fun to the next level.  So what can we do with two incredibly accurate GPS modules running on tiny devices?  How about Real-Time Kinematics?

RTK eliminates the jitter experienced by solitary GPS receivers using differential techniques.  It requires a base station with known co-ordinates and a mobile reciever. By using the difference in signal-to-noise (SNR) ratios and phase for common satellites, RTK algorithms can cancel out atmospheric effects that can pollute geopositioning results.  I won't go into incredible detail here since Navipedia has a great wiki on the subject.
This image shows the GPS/GNSS data in pink and the RTK results in green of a rover driving around in a  6-meter circle.

So why do we care about RTK?  It's primarily used for surveying, but there are many situations when a robotic rover may want to track its path, report its exact position or navigate to a given waypoint with a high level of accuracy.  That's what I'm excited about.  I'm going to rig an automated robot with a BBB and Rover cape, use my RPCM rig as a base station and use the GPS data to control the rover.

First we have to get some RTK software up and running.  There aren't a lot of options for this in the open-source world, but the biggest name is RTKLIB.  It's not only an open source library, but it also includes a complete set of GUI and CLI apps to get you started.

Sadly, the GUI elements are written for Windows, so there's no chance of using them on the Pi Compute dev board, and I'll have to monitor operations from my laptop.  But the str2str and rtkrcv command line programs are the two most important elements of the software suite for my needs. these applications, and eventually their source code, will be the backbone of the RTK project.  The easiest way to compile these for ARM Linux is to download the source code onto your BBB and Raspberry Pi and compile them natively.  I ran into a little linking problem after I cross-compiled the applications on my PC and tried to run them on the COMs.  In the end, it was just far less hassle to go native.

Having set a precedent with the Gumstix Pi Compute Pre-GO PPP project, I felt I had to build a fancy box for my Gumstix BBB Rover.

I got the COMs equipped with their expansion boards, Pre-GO PPPs and antennas and wrapped up in a nice package.  With the RPCM being my base station, I used a Pre-GO PPP SMA so I could use a more sensitive antenna.  This will get me a more accurate fix on the rover's position.  The antenna I'm using is the Dominator AA.161 from Taoglas.  The BBB Rover has an on-board TI WiLink8 WiFi and Bluetooth modem that requires a u.FL antenna, and I'm using the Pre-GO PPP with the built-in antenna.

With the binaries and data files on the boards, I started experimenting, streaming data from the COMs to my laptop and trying to get a fix.  I tried a myriad of config files and, after some digging, I put together this file. The commands therein are transmitted to the u-blox NEO-7P on the PPP boards and instruct them to transmit tuples that are normally blocked across the UART channel.  These strings carry the phase data of the satellite signals which RTKNAVI, the GUI I use on my laptop, uses for RTK solutions.

After some trial and error, I began to see SNR data.  It looked something like this:

The top graph is the data from the BBB, and the bottom from the RPCM.  Each bar represents the SNR from a satellite.  In order to get a solution, the two computers have to be able to get a strong fix (shown as a colored bar) on several common satellites.  Unfortunately, the window in the office only provides half a constellation.  Not nearly enough for RTK... Barely enough for a single fix.
My little computers are getting their fix.  Tux is helping.

 Clearly, I need to get outside.  That'll have to wait until next week.  In the meantime, I'm all set up, apart from a battery pack for the BBB, to do some real testing.

NEXT TIME: The great outdoors, differentially.

Monday, May 16, 2016

Gumstix Pi Pre-GO PPP Project Chapter 5

I took my equipment to the tennis court yesterday and gathered some data.  When I arrived, I was saddended to discover that the two main courts were occupied so I went to the last one. Ten minutes at each of the eight corners I'd mentioned before  gave me quite a bit of data.  When I plot it on Google Earth, it looks like this:

OK so something's wrong.  First off, the orientation Google's image is clearly incorrect. Secondly, there's that tree!  It's covering the entire back-right corner!  I might be able to go again some other time, but let's make some observations first.  Looking at the inner corners, [LBS, RBS, LFS, RFS], the dimensions are reasonably correct.

What it looks like to me is that the court sits on a slope, which I hadn't considered to be a major source of error.  I had assumed that the courts would be level but, having been there for some time, they have most likely sunk in places and bubbled in others.  I may have had more luck had I acquired access to Wimbledon,  but the fact of the matter is I'm trying to measure exact distances with chunks of metal free-falling high above the earth and no fixed point of reference on a surface with random elevations.

Here is my conclusion for this project:  The Pre-GO PPP works beautifully with the Raspberry Pi Compute Module through the Gumstix Pi's UART breakout connection. It is able to measure GPS position with decimetre-level accuracy and sub-decimetre jitter.  However, measuring distances with sub-metre-level accuracy is next to impossible using GPS coordinates alone.

There are many reasons.  First off, environmental factors, such as trees and bridges will drastically increase dilution of precision.  Reason number two is explained above.  Lastly,  I can't seem to get enough court time to collect all my data points.

Clearly, a new strategy must be employed.

Up next: BBB Rover and RTK

Monday, April 4, 2016

Pre-GO PPP and the Gumstix BBB Rover Cape

This is not going to be a long post.  Basically, I got the Pre-GO PPP working with the BeagleBone Black almost effortlessly through the Gumstix BBB Rover cape.  Rover was designed to be a remote-controlled robotics cape with dual PWMs for motor control on either side of the board, WiFi and Bluetooth connectivity and a whole lot of GPIO.  Conveniently enough, it has the 5-pin GPS header module on-board as well.

I downloaded the custom Yocto image, loaded it on to an SD card and fired it up.  Right away, I was able to see the raw GPS feed over a serial connection to UART04 but the image I had lacked the GPSD client tools.  After I disabled the IP-over-USB service and the BeagleBone's Ethernet controller and my router stopped arguing, I apt-got the tools and monitored the GPS data for a while.

It's confirmed, the Pre-GO PPP works great with the BBB Rover cape.

Meanwhile, I've completed my final test for the RPCM + Pre-GO PPP and am in the midst of analyzing the data.  I'll be posting my findings soon...

Monday, March 7, 2016

The Gumstix Pi Pre-GO Project Chapter 3: I can't Rely on Google Maps.

There was a nice break in the weather yesterday and I managed to get outside to take some readings.  I set up on an exposed hilltop with my laptop, my Pre-GO-to-go and my smartphone.  I was hoping that I might find some kind of survey marker with exact GPS coordinates at the base of the flag pole, but no such luckI fired up my Pi, gave it a few minutes to warm up, and connected it and my laptop to my phone's WiFi hotspot.

With no guarantee of clear weather, I decided to do a quick test and grab four different data snapshots over a 15 minute window.  I'll formulate some more informative tests for when the weather is better.  For now, I just want to see how accurate it is.

The PPP in Pre-GO PPP stands for Precise Point Positioning.  PPP provides centi- to decimeter-level accuracy so, even if Google doesn't drop its pin directly on the flagpole, my data points should be very close together.  I have to assume that Google Maps co-ordinates are going to be somewhat skewed.  Without an accurate geodetic survey marker, I can't be certain.

When I got back to the office, I dropped some pins on the map and here's what I came up with:

The outlier is my initial result.  The tight grouping south west of it are the three other results I recorded.  They sit about 1.5m away from the outlier but are all within 12cm of each other.

I found this blog post that confirms my assumption about Google's geodetic accuracy.  If you compare my Maps screen shot to his, it looks like the skew is about equivalent.  I trust my results over Google's now.

So I still have not concrete baseline measure of accuracy.  I really want to know if my horizontal co-ordinates, when HDOP (horizontal dilution of precision) is less than 1, are accurate at the decimetre level.

To that end, my colleague sent me a link to, where I found a survey marker nearby.  GPS enthusiasts have, thankfully, taken the time to accurately measure its geographic position.  OK great, but I have been rained out.  I guess the next test is going to have to wait awhile.  While we wait, let's see if the Pre-GO works with the BeagleBone Black and the Gumstix Rover cape.

Next Time:  Pre-GO and the BeagleBone Black Rover Cape

Thursday, March 3, 2016

The Gumstix Pi Pre-GO Project Chapter 2: Pre-GO Packaged to Go

So, while we're debugging the UART header, I thought I may as well get some results from the Pi using the FTDI cable. With the help of a USB hub, a WiFi dongle and some masking tape, I set the Pre-GO up on the window.  I figured if I was going to get any kind of signal anywhere in the office, this would be it.

I SSH'ed in and ran gpsmon. This is a great tool related to GPSD that spits out human-readable GPS data in real time.  It looks something like this:

Yep, my Pi kind of knows where it is... within 10 metres, that is.  Not good enough for a Precise Point Positioning (PPP) GPS module.  I have to get it outside to get accurate geolocation.

Good news! The UART problem was resolved with a single line:


I appended this line to /boot/config.txt and said goodbye to the FTDI converter.  With the bulky USB cable and hub gone I decided to get my gear ready for test.

A circuit board with a delicate makeshift UART connection is not easily transported.  Not to mention the need for a power cord makes taking my rig on the road a bit of a challenge.  No problem. Tape, scissors, and a shipping package, combined with a little time gives you this:



Next Up: Where am I, Precisely?

Friday, February 26, 2016

The Gumstix Pi GPS Project Chapter 1: Break it out and get it running

As my first gadget project as Gumstix Guru, I'm going to connect a Pre-GO PPP GPS to a Raspberry Pi Compute Module by way of the Gumstix Pi Compute development board, pictured below.

Getting Started

I could just build a board in Geppetto with the GPS connector on it, but I've already got my Gumstix Pi in hand.  The Pre-GO communicates over a UART connection, a header for which the Gumstix Pi has.  The trick is that I need to manually rig the connection.  Easy enough.  Let's break out the Pre-GO's header:

I made a point of labelling each one of the wires just to make life a bit easier later on.

Of minor concern is the fact that the pitch of the Pre-GO's header is considerably smaller than that of the dev board's UART header so I had to use a finer gauged wire.  Not a big deal but they aren't a good fit for my jumper wires.  My solution?  Easy:  Fold 'em.

Next I decided to forgo the extra mess of jumper wires and go straight to the jumpers.  A nice way of keeping the rat's nest to a minimum.  Oh, and my labels fell off.

First Power-Up

At this point I'm very excited.  The board's all hooked up, the Pi module is in place and it's time to plug it all in.  Hope I didn't forget anything!
Once Raspbian is up and running, I go hunting for my GPS module to no avail.  What's wrong?  Why isn't it working?

Time to go to the test bench to make sure the module works. 
  • Board configured for 3.3V - check
  • Connectors attached correctly - check
  • Waveform resembles data output - check
So I hook it up to an FTDI-UART adapter and check its output.  Looks like GPS data to me:

The Verdict

Okay so the Pi is working and the GPS module is working, they're just not talking to each other.  So the UART header isn't configured correctly.  I'll get that sorted out later.  For now, I'll just hook it up with the FTDI adapter and get some results.

Next Up:  Raspberry Pi CM and GPSD