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: https://github.com/GumstixExperimental/RTKRover

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

Fun

 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!

Wednesday, June 29, 2016

AeroCore 2 for Dragonboard 410C: DragonDrones?

I'm taking a bit of a break from RTK and robots today because I'm pretty excited about a board we recently released.  I've always been interested in UAVs and drones, and have wanted to build one out of the derelict UAV frames we have lying around the office here.  Well, I may get my chance in the near future.  The AeroCore 2 expansion board for the Dragonboard 410C is now available and is a major upgrade from its Overo and DuoVero counterparts.

AeroCore 2

Innovation in UAV Flight Control


The AeroCore 2 was originally released Fall 2015 for the Gumstix Overo and DuoVero COMs to replace the original AeroCore, adding Spektrum DSM-2 RC connectivity, more communication headers, and GPIOs, and moving GPS off-board with Gumstix the Pre-GO family of boards (which I am currently playing with in my other posts).  The AeroCore family of expansion boards were developed in conjunction with graduate students from Stanford University's Aero/Astro program.  Its small dimensions make it ideal for micro aerial vehicles.

On-Board Autopilot

The AeroCore 2 design includes an on-board ARM Cortex-M4 microcontroller running NuttX RTOS.  It not only manages I/O data in real time, it's also compatible with PX4 autopilot software for fully automated flight.

Higher Level Thinking

The inclusion of a powerful processor in a drone allows for in-flight decision-making, such as low-latency obstacle avoidance, computer vision-based navigation, or swarm applications.  AeroCore 2 boards are designed to connect to Overo and DuoVero COMs, with ARM Cortex-A9 processors capable of these compute-intensive tasks.


Now for Dragonboard 410C

The new AeroCore 2 for Dragonboard 410C, as I mentioned earlier, adds some really cool features to an already spectacular platform.

A New SBC 

The Dragonboard 410C from Arrow is more than a COM, it's a single-board computer that has been built to match the 96Boards CE specs.  With a Qualcomm Snapdragon 410 processor, 1GB RAM and on-board eMMC storage, this credit card-sized SBC is a force to be reckoned with.

The Dragonboard is designed to connect to expansion boards.  Much like the BeagleBone Black has capes and the Arduino has shields, Any board designed to mate with the 96Boards spec can be connected to the Dragonboard.

A compatible connector module has been added to our repertoire of COM
connectors and we've begun designing boards for the 410C.

We started with the AeroCore 2 design.

What's New For AeroCore 2

As good as any design may be, there's always room for improvement.  This includes the tried and true AeroCore 2.  Two exciting new features were added to this iteration that continue to expand the board's functionality.

First, a CSI-2 camera connector was added.  This is a fast communication channel capable of driving HD cameras like the Raspberry Pi camera.

The other big deal is the NimbeLink Skywire 4G LTE modem connector.  Remote control doesn't get much more remote than that.

Designed by Gumstix in Geppetto

Even though you could order the board from the Gumstix store for around $150, your startup/research project/product may require different or additional features. Geppetto is an amazing tool for creating your own custom boards, or for modifying existing ones.  It's a drag-and-drop web interface that allows you to place hardware, from an ever-growing library of headers, connectors, ports, sensors and more, on your design, order it from Gumstix (for a $1999 set-up fee) and receive the final, tested, board in about three weeks.  For more information, go to:
www.gumstix.com/geppetto/

Board designs from Gumstix engineers are freely available and you can clone them to your workspace and change them however you want.  You can get started with the AeroCore 2 for Dragonboard 410C by following this link.

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.

Software

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.


Hardware

A couple weeks ago, I ordered this robot chassis and this motor driver from RobotShop.com. 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!