Tuesday, March 19, 2013

2-8 Basic Skeletal Following without SLAM

In parallel with the design and construction of the rocker-bogie prototype, I've been investigating navigation and mapping techniques using visual SLAM.   SLAM (Simultaneous Localization and Mapping) is a technique for using landmarks and probability to:
  1. discover landmarks and create a map of the robot's environment
  2. use the map and current sensor readings combined with probability to estimate the position and orientation of the robot on the map. 

As a precursor to training porterbot to map out and navigate around household environments, I wanted to use a Microsoft Kinect to experiment with visual SLAM.  The Kinect has an API for getting vision and skeleton data, so my goal was to take this data and try to perform exploration and mapping on a single level of a house.  I looked around for a reasonably affordable platform based off the Kinect and found TurtleBot, a platform that uses the Kinect for vision, an iRobot Create for movement, and a user's laptop for processing and control.
Turtlebot ready to roam

I already had a Kinect, so I ordered the Turtlebot platform parts and purchased an iRobot Create separately.  The Turtlebot chassis parts are very straightforward to put together; it took me less than an hour to put it all together.  It comes with a custom build of ROS (Robot Operating System) to get jump-started.  Instead of using ROS, I decided to use Microsoft Robotics Developer Studio because it has a very detailed API to make full use of the Kinect.  It also has built-in support for communicating with the Create, so I thought it would go very smoothly.  I had some difficulty working with Robotics Studio, but eventually managed to get a Service talking to both the Create and Kinect simultaneously. 



For my first goal, I wanted to get skeleton data from the Kinect, find the distance to the hip-center joint of the person data, and then send commands to the Create to rotate so the person was centered.  I'm won't post code at this point since the Robotics Studio code is largely throw-away so I can understand the process.  I used my kids (Ethan, Zoe, and Phoebe) as subjects for the initial experiment, which you can see from the above video worked pretty well.  The USB wires connecting the ICreate and Kinect to my laptop were pretty annoying, but I'll figure out some way to secure my laptop for further testing.  On to SLAM mapping!


Tuesday, February 12, 2013

DC Robotics club meetup

My parents, wife and a few others had been pushing me recently to start looking for possible collaborators in developing Porterbot; especially considering my lack of expertise into the electrical and mechanical aspects of robotics development.  I'm not sure if it's fate, total random chance, or God nudging me along, but as it so happens there was a Robotics Meetup group started in DC in late November.  I had randomly landed on their website and had signed up, but couldn't get to any of their meetings until this January when I managed to go to a Robotics Hardware Primer workshop held by them in Adams Morgan.  

It was very interesting; I picked up a lot of useful information about 3D printers and stepper motors.  Also some good tips about reducing costs in ordering robot parts.  I'm not sure if I'll meet anyone who is particularly interested in what I'm working on, but I do recommend the group to any aspiring roboticists in the Washington DC metro region.

3-4 Design basic stock-parts Rocker-bogie Chassis

Mechanical engineering is not a strong suit of mine, so I thought to start off with it would make sense to build the first prototype of porter bot as a stock parts bot, with no custom parts.  The basic structure of the rocker bogie suspension was familiar to me from seeing some other projects posted on the web (here and here).  I knew I wanted to design the bot in a 3D drawing or CAD program.  After investigating some possible offerings, like SketchUp and SolidWorks, I settled on an open-source animation and modeling software package called Blender.  It was free, had wide community support, and had some integrations with a physics engine called Bullet Physics.  Eventually I want to simulate the porter bot in different physical environments to facilitate unit testing before going commercial, so that was a big selling point for me.  Blender is not ideally suited for CAD modeling since it's aimed more at animation or game development tasks, but I thought it had a very good tool-set for being free and was far easier to install and manage than other open source modeling packages I've tried like Rhino. 

After deciding on Blender, I had to figure out where to get robot stock parts.  There are surprisingly few robotics parts vendors online; I ended up relying on McMaster Carr for general parts, Lynxmotion (now part of Robotshop) and their Servo Erector set, and ServoCity for the actual Hi-tec servos.  I decided not to do a hardcore engineering analysis for the first prototype, but happened on a very helpful paper sponsored by the South Korean government that did a theoretical study on the best configuration for a rocker bogie suspension.  I used their general recommendations and then used my best estimate of the dimensions of each of the stock parts online to design the robot in Blender.  

Porterbot version 1.0
After ordering all the parts based off my Blender design, the total came to around $700 (not including the cost of the i.mx53 android brain), which is a lot steeper than I expected.  I don't think the costs are intrinsically that high (after talking to some roboticists with more experience than me), so hopefully I can build the basic chassis and suspension for half that cost when I start looking at putting porter bot into full production.  Stay tuned for details in the coming weeks as I start to make Porterbot version 1.0 a reality.