wjwwood.github.io

SparkFun LCD

2015-04-20T00:00:00+00:00

I’ve had this SparkFun LCD break lying around for a long time. I think I ordered it back in 2010 along with my mbed and never took the time to get it working. I was doing some electronics stuff today and I noticed it in my electronics tackle box and I thought I’d give it another go.

First off, this is the board I’m talking about:

https://www.sparkfun.com/products/retired/8600

I was able to pretty quickly find a library called gLCD which let me get it going pretty easily. I did run into trouble compiling it, but it was easy enough to fix up. However, the source was not in any VCS I could find (I downloaded it from http://www.railways-in-miniature.co.uk/gLCD.zip). So I “forked” it into a repository on my GitHub account and pushed the origin code and afterwards my patch which gets it working on Arduino versions >= 1.0:

https://github.com/wjwwood/arduino-glcd

After getting it to compile, I should mention I was compiling the TestPattern example which comes with the library, I reasoned out how to wire it up to my Arduino Mega that I was using. I connected things according to this:

//You can use these variables to set the pin numbers
const char RST = 8;
const char CS = 9;
const char Clk = 13;
const char Dat = 11;

And additionally I connected vin to my 3.3v pin on the arduino and the vbatt to the 5v pin. Then it just worked:

So that’s neat, but I was doing some more digging around and noticed this thread:

https://forum.sparkfun.com/viewtopic.php?f=15&t=15448

In summary, there is an inductor on the board (it’s blue with 221 written on it) which gets really hot:

And sure enough I touched my finger to it and it was hot! The conclusion on the forum was that it should be replaced with an inductor which can handle more current (around ~500ma). But another suggestion was to replace one of the resistors with a different value, which some reported helped.

I ran out of time to actually try that, but maybe I’ll give it a go next time I pull it out of the box.

Received Structure.io Device

2014-04-05T00:00:00+00:00

On Friday I finally received my Structure.io device from my backing them on Kickstarter!

Obviously I wanted to see if it worked with the openni2 ROS drivers, so plugged it into my MacBook and ran the openni2.launch launch file in the openni2_launch package. I was easily then able to then subscribe to the depth image using rqt’s Image View plugin:

I ran into some trouble getting the point clouds to publish, but I think that has to do with some assumption about the device that the ROS driver is making. I think it may be assuming that it has a color camera and so it will try to output colored point clouds. I am not 100% certain about that, but I will probably try to dig into the issue at some point now that I have the device in hand.

I guess I shouldn’t be surprised that it mostly worked out-of-the box, but it is exciting to me because I think this device could make an excellent alternative as a robot sensor because it is smaller than even the ASUS Xtion’s, it doesn’t have a color camera (which in many cases is not needed for a small robot), and it is designed to be mounted to things. In fact the Structure.io guys have CAD files for the device so you can 3D print your own mounts for it.

I have been slowly accumulating pieces for a robot and I think this might be the obstacle avoidance sensor for that project when ever I really get it going.

Serial v1.0 Released

2012-06-19T00:00:00+00:00

After several months of work, Serial v1.0 is out! Serial is Cross-platform serial (rs-232) library written in C++. You can grab it at my github page:

http://wjwwood.github.com/serial/

Or you can browse the documentation:

http://wjwwood.github.com/serial/docs/v1.0/index.html

A short list of the features:

Windows, Linux, and OS X support
Permissive license (The New BSD License)
Support for custom baudrates (where supported)
Flush the I/O separately, and block until writing is complete
Control handshaking lines
Block for changes in handshaking lines (Linux and Windows)
Complete timeout control (interbyte, per call, and per byte timeout components)
Minimal dependencies (cmake)
Support for ROS (ros.org) as a unary stack

For many months now, my friend John (http://greaterthaninfinity.com/) and I have been working on a cross platform serial library written in C++. We surveyed the web and found that there really wasn’t a well designed and easy to use serial library that made any effort at being portable (Windows, Linux, OS X). We really like PySerial and we wanted something as simple and straight forward as that for C++. Initially we found that Boost had good portability in its serial library, part of boost.asio, but it was verbose and over complicated, and still didn’t provide portability for actions like, flushing the serial port, setting the hand shaking lines, etc… So we set out to write one from scratch with a custom built unix and windows implementation, and an ABI compatible single interface modeled after PySerial, but with a few changes. Most notably is that the timeout system mimics the Windows serial timeout struct, and therefore has five parameters for controlling read/write timeouts. This behavior is achieved in Unix systems by using select to figure out when to read, rather than relying on Unix’s read command for timeout behavior, which exactly how PySerial does it.

I am really excited to see it finally out, and there are several people outside of our lab here at Auburn already using it, and finding bugs =p (v1.0.1 is due out soon). If you decide to give it a whirl and find problems please open an issue on github: https://github.com/wjwwood/serial/issues/new

South's BEST Regional Robotics Competition

2011-12-02T00:00:00+00:00

Today is the first day of the South’s BEST Regional Robotics competition hosted at the new Auburn University Arena in Auburn, AL. This is the final competition event for the BEST robotics middle/high school robotics program this year. 50 teams and thousands of middle and high school students are here to compete for robotics, display booths, oral presentations, website design, and much more. The main part of the competition will be tomorrow, Saturday December 3rd, and will have 8 seeding rounds, semi-finals, and finals to determine the BEST team in the south east!

The competition will be live streamed tomorrow here: http://best.eng.auburn.edu/souths-best-stream.html

I have a live photo stream on flickr: http://www.flickr.com/photos/64029232@N07/sets/72157628251429949

WarEagle BEST Competition!

2011-10-08T00:00:00+00:00

Today is the WarEagle BEST Hub’s middle/high school robotics competition!

We are at Wetumpka High School in Wetumpka, AL and we have 16 middle and high schools here pitting their robot design against each other in this local competition of the Bugs! BEST game!

You can find details on the game this year here.

You can follow the scores with your iPhone, Android, or on the Web!

WarEagle BEST Mall-day

2011-09-27T00:00:00+00:00

This past Sunday was the Mall-day for the WarEagle BEST hub. On Mall-day the kids bring their robots to a local Mall to try out their robots on a competition field and to survey the competition. This year there were some interesting looking designs ranging from a worm gear made from sheets of PVC to a 4-wheeled differential drive robot with scissor arm.

Since all of the hubs have had kick-off already I can share some of this year’s game rules with you. The theme of this year’s game is Bug’s, and your robot is supposed to collect bugs and food for the bugs and move them to different locations. For example, you might choose to collect one of the “flys” (two styrofoam spheres that are glued together) from the cabinet and place it in the “wood pile” (an obstacle course made of 2x4’s). I think the teams have gotten a good start this year and I am excited to see what comes of WarEagle BEST and South’s BEST.

</embed>

I have been part of BEST for over 10 years now and I have help almost every conceivable role: student, mentor, referee, volunteer, A-Team (game day technical support team). My roommate Michael Carroll, who has been doing this just as long as I have, has been an integral part of the planning and technical logistics for WarEagle BEST’s hub events as well as the up coming South’s BEST this year. If you are unfamiliar with BEST I would encourage you to find out if a hub is near you and get involved!

ROS and Stage4 on OS X

2011-09-23T00:00:00+00:00

So for my autonomous mobile robotics class I am taking this semester my class project is going to be a new coverage path planner for the Autonomous Lawnmower. We have decided to develop this planner in simulation and as we surveyed the landscape (MORSE, Gazebo, Stage, and Custom built) we landed on Stage.

Problem though, the stage that comes with ROS didn’t work on OS X, but thanks to Richard Vaughan’s recent work on Stage4, OS X is back in action as a supported platform.

Another problem, stageros, the wrapper for Stage to interact with ROS, was designed for a pervious Stage API and didn’t compile. So we set out to update rosstage to support Stage4. We managed to get everything to point where it worked on OS X and Linux.

After spending some time fixing the issues (mostly trivial things) we discovered that Vaughan head already done most of this in the trunk of ROS’s stage unary stack, doh.

https://code.ros.org/gf/project/ros-pkg/scmsvn/?action=browse&path=%2Fstacks%2Fstage%2Ftrunk%2F&pathrev=37480

Anyways long story short we managed to get Stage4 and ROS playing nice on OS X and Linux and now our class work can proceed. The only difference between my changes and Vaughan’s was that I decided to resolve the Stage4 dependency with Homebrew rather than in the ROS unary stack.

Here is the brew Formula:

https://raw.github.com/wjwwood/homebrew/daf127d92166fcd57427e481c7b3c0f746dd3e28/Library/Formula/stage.rb

I recommend using HEAD until a stable tag comes out (brew install --HEAD <url>).

rViz on OS X, Success Reloaded! (10.7)

2011-09-06T00:00:00+00:00

I managed to get rViz running this evening on OS X 10.7 using homebrew as the package manager!

More details will follow soon, in the mean time:

https://github.com/wjwwood/ros-osx/tree/master/electric-lion-homebrew

Screenshot!

MORSE Progress Report

2011-08-01T00:00:00+00:00

I have been working on getting MORSE to a point that I can use it to develop some simple obstacle detection and avoidance algorithms. The vehicle I am trying to emulate is a Polaris EV with an automation package on it from Kairos Autonomi. The vehicle pulls a fiberglass trailer with Electromagnetic sensors on it which are used to find and discriminate UXO (unexploded ordinance) for the US ARMY Corp of Engineers. In this video I am using ROS to issue commands to the simulated vehicle (due to decent ROS support in MORSE atm), but on the real system our team has a monolithic stand-alone app with plans for moving to JAUS. Here are some screen shots and a short YouTube video. Here is a video of the actual vehicle (I'm not in that video).

Top Story: Automow Team Takes 2nd

2011-06-22T00:00:00+00:00

We made the front page “featured” news on Auburn’s website!

http://ocm.auburn.edu/featured_story/lawnmower.html

Here’s a photo:

My Segway RMP Library: libsegwayrmp

2011-06-21T00:00:00+00:00

I have been working a library for interfacing with the Segway RMP series of mobile robots. You can find the source online at https://github.com/segwayrmp/libsegwayrmp, and the documentation at http://segwayrmp.github.com/libsegwayrmp/. I decided to take this step because I needed several things in a rmp library that I couldn’t find all in one place. Those things included:

Cross Platform

I do all my work on Linux computer, but I like to use my Mac when ever possible as well, but also we have some projects here that run on Windows still and I need to be able to support that too. Most of the libraries I looked at had a pretty one-off feel to them and therefore only worked on one OS. A few libraries had some polish but still lacked support for Windows and Linux in the same library. Sadly, I cannot say for certain that my new library works on Windows yet, but there is absolutely no reason it shouldn’t and I just need to test it out and fix any small problems I run into. The big difference is that my library considered cross platform portability from the beginning, so even if I don’t use it on Windows for some time, there is no glaring incompatibility that will keep it from running on Windows when the time comes.

Open Source

For most of the libraries I looked at this isn’t a problem as they are generally GPL or BSD, but I like to stay away from GPL when possible. To that end my library is permissively licensed under the BSD license. For those who don’t know that means copy it, use it, sell it, integrate it, just mention you got it from my library.

Support both Serial and USB

This is the big one, there are basically three ways to interface with the Segway RMP: CAN, USB via FTDI’s D2XX Library, and Serial.

Interfacing with CAN

In order to interface with the RMP via CAN you needed to have an older model that came with a third party CAN2XXX device for linking it to your computer. I have seen systems that use the kvaser CAN interfaces and others that used the popular PCAN interfaces. Either way, this is an old and outdated method for interfacing with the RMP’s and now they all have USB connections that provide access to the CAN bus through a USB packet interface using an FTDI FTD245BM Chip. Since this is an out of date method and there many different interface specific concerns, my library doesn’t support CAN directly, though my generic RMPIO class allows for easily making a CAN interface work.

Interfacing with USB

The USB interface that now comes on all Segway RMP’s is made possible by the FTDI FTD245BM Chip used in the “UI” component of the RMP these days. If you aren’t familiar with the way that the FTDI driver system works there are basically three different ones for most of their devices. First there is the D2XX driver. This driver provides only a USB (now libusb based) interface to the chips, which gives the programmer much more in depth control and access to FTDI chip specific commands and provides a, presumably, more efficient interface for reading and writing to the serial like devices. This is in contrast to the VCP driver from FTDI, which allows the Operating System to use the FTDI device like a legacy com port, showing up in Windows like ‘COM1’ and in POSIX like ‘/dev/ttyUSB0’ or similar. This is now the default type of interface in Linux and in fact you have to forcefully remove and blacklist the ftdi_sio and usbserial drivers in the kernel to prevent the VCP style representation of the device. This was problematic for me because I use Linux for everything and most all of the libraries only supported the D2XX style interfacing for the RMP. Therefore I had blacklist the ftdi_sio driver from capturing the device, but this is a blanket operation, meaning that any other FTDI devices would also not show up as serial ports. I didn’t like this. The last type of driver is Windows only and is called the CDM (Combined Driver Model) which allows for dynamic switching from VCP to D2XX.

Interfacing with Serial

Like I said, the fact that using the RMP as a USB device on Linux meant that I couldn’t use other FTDI devices like serial ports was a potential deal breaker for me. There for I set out to write a driver for the RMP that would use the VCP style interface for communication. I did this, using my serial library, and I was successful after only a week or so. But, I realized that I couldn’t use the VCP driver on Mac… So I decided to add the ability for my driver to optionally use either USB or Serial to interface with the RMP. This took more time, but finally I have a solution for right now and I plan to add more of the features I wanted later.

Other Design Considerations

In addition to the things I was looking for in a library, capability wise, I needed to consider something else. I originally wanted to just extend someone else’s library, but I considered the fact that it wasn’t exactly without baggage. To be fair my library has a dependency on my homebrew serial library, but it is optional and easy to install. I needed my library to work in a monolithic stand-alone application, in a ROS package (for my work), and a MOOS Application in another svn repository (for my co-workers). Therefore I took great care in designing the build system in particular to be flexible, portable, and gracefully degrading.

Watch here for a ROS package: https://github.com/segwayrmp/segway-rmp-ros-pkg

For the MOOS Application, email me.

For the monolithic-application, email me.

Results

To recap I wanted several things for my new Segway RMP library and here is where it stands:

Open Source:
- BSD Licensed
Cross-Platform Support:
- Linux
- Mac OS X
- Windows (Needs testing)
Multiple Interface Types:
- CAN (Will not support, unless someone asks and has hardware to test it with)
- USB (Supported on Linux, Mac, and Windows (needs testing))
- Serial (Supported on Linux, Mac, and Windows (needs testing))

I hope that this library will help others at some point and don’t be afraid to ask questions or post bugs on the tracker: https://github.com/segwayrmp/libsegwayrmp/issues.

Inadvertent Map of Broun Hall

2011-06-21T00:00:00+00:00

I was showing off my Segway RMP 200 robot with a Kinect on it to some kids here on an engineering camp and I let them drive it around after the presentation and I forgot I had SLAM running with the Sick LiDAR and they inadvertently made a pretty decent map of the basement of Broun Hall =D.

RViz on OS X, Success!

2011-06-17T00:00:00+00:00

After working with my friend John, we have put together a decent one-stop-shop for solving the issues encountered when trying to compile ROS, and specifically RViz for OS X. The solution we managed to find is a combination of building all macports as +universal, limiting the system to 1 version of Python (2.6.x for us), and forcing all of ROS to be build as i386 with the CMAKE_OSX_ARCHITECTURES="i386" environment variable. This strategy is based on a comment on a ticket by Dave on the ros-pkg trac.

And here is a snapshot!

We have our wiki page that details the steps involved on github, here:

https://github.com/wjwwood/ros-osx/wiki

Most of the things on the wiki are solved problems that are either tickets that have been solved up stream but haven’t been backported to diamondback yet, or are simple tricks to getting ROS, and macports to play nice. Hopefully the guide won’t even be necessary once Electric Turtle is released.

I am very pleased with the performance(~20% cpu use on data in screenshot below), but there are still some usability issues, some of which I have noticed on my VM’s too, I have been keeping track of them and I hope to make tickets for them soon and maybe even try patches for them.