Puckbot – Collector Robot Post-Mortem

Building and programming the Puckbot was a fascinating project.  I have attempted to build similar robots a few times over the past couple of years,  but I never really devoted the time toward creating a stable, reliable behavior-based framework first.  Earlier frameworks utilized different techniques that were weak in execution, difficult to debug, and unpredictable.  With my latest venture using RobotC, I spent some real time working on the framework.  The framework was the least of my worries on this robot.  It functioned as designed and is easy to add behaviors to, easy (easier) to debug, and certainly robust enough to create viable autonomous robots.

Implementing the collector robot with Lego Mindstorms NXT and my RobotC behavior-based framework was completely rewarding.  I still have to laugh a little when I watching the robot move around the arena, collecting pucks and delivering the successfully to the light.  Of course, I thought out the sensors and behaviors, of course there is a ton of information and study on the collector in my books, but to see it actually do the job for real was special.  I have to admit, I was a little unsure if I could pull it off.  There are a lot of behaviors working in concert, all with their own set of parameters to fiddle with, and so many things that could have gone wrong; They had in the past…

Wow!  Watching the robot in figure out what to do, and doing it by its self, is what it is all about. 

What Went Right

As you can see, I am proud of this accomplishment as a whole.  When I break down the components, there are many things I learned, that really worked well.  Here are a few.

• Learning that one front bumper is enough in many cases.  Like most of you, I almost always create my front bumpers with two bumpers (left & right).  I starting thinking about it, and wanted to try to use only one input for the bumpers and found I was not giving up too much advantage by implementing one bumper.
• Going a step further and adding a light sensor to the same port as the bumpers. In my case, I was able to work around the limitation of having light sensor and bumper readings on the same port and I saved inputs for other sensors.
• By implementing sensor drivers, I also created a standard set of functions to communicate with the sensors.  The idea was to create a function like FrontBumper.isBumped() so that in the future, a behavior that implements this function does care about the implementation or configuration of the sensors, only is the front bumper was bumped or not.  The driver performs the calculations and returns whether or not the bumper is engaged. (note-I did not say pressed).  The bumper be physically implemented to be “isBumped” when pushed or not pushed depending on the design.
• Creating a sensor driver for the differential light sensor also shined for me.  By creating a driver that supplied standard methods and values, multiple behaviors could use the “triggers” for their own purposes without complicated, customized logic in each behavior.  Look at the code to see what I mean; Especially with the differential light sensor.  Seeing or not Seeing a light is critical to the operation of the robot.  The driver return true or false.  Calculations are done internally to the driver to determine thresholds, etc…  Several behaviors use the common functions.
• The Differential Light Sensor auto calibrates.  When I first created the robot and coded some behaviors, varying light sources in my office caused many confusing problems for the robot (and me!).  The differential light sensor driver attempts to do the hard work no matter the environment lighting by storing hi, lo, and current values and doing calculations to automatically configure thresholds and return meaningful information.

What Were Some Challenges

• The Puckbot manages several behaviors at once.  Trying to understand programmatic failures is not always easy to determine.  I found that by disabling all behaviors but one or two really helps to find issues.  By implementing only LIGHT HOME, I was able to move the robot manually into position, and watch trigger points and see the homing action.
• Speaking of homing, There were times when the robot would home in on the light source only to get too close and “loose” track of it because the light sensors saw a similar value, but did not directly see the light.  Kind of like going cross-eyed trying to see the tip or your nose.  The robot would crash into the wall behind the source and escape most of the time, but it looked clumsy.  At least there is some inherent graceful degradation, even in my simple NXT robot.
• Wall following utilized the front bumper, which was on the same input port as the down pointing light sensor.  While touching a wall, the robot is unable to determine if it has captured a puck.  It is effectively blind at times.
• On this topic, one weakness of the hierarchical behavior model is the paradox it can create at times where it seems one behavior should be higher priority than another in some cases, and lower in others.  BUMP FOLLOW and DARK PUCK were victims of this.  Generally, bump follow must be high on the list above BUMP ESCAPE since it only triggers sometimes, but what if the robot encounters a puck along the wall while following?  DARK PUCK is pretty low in the list and should not be above the escape behaviors or the robot might crash into a wall carrying a puck and not be able to escape.  I need to think more on this, but I think the answer may be to create a new, special case, behavior above BUMP FOLLOW for when a puck is encountered while following a wall.
• Physical design caused interesting challenges.  For example, I changed the puck catching mechanism several times to maximize capture.  I even changed the design after I posted nice pictures on the design in this blog.  I was not capturing pucks when they were near the front wheels.  Compare the video with the pictures in the blog and you will see differences (if you look close).
• I noticed the robot seemed to get stuck in a loop in a few cases where it was away from the light source, and carrying a puck.  I think the robot starts to turn toward the light source with a puck, but the puck slips from the catch.  The light sensor looses it momentarily, and the light source is not strong enough to attract the robot, so it starts to CRUISE.  At that point, the puck slips back into the catch and starts the loop over.  It is a complex case of canyoning and surprised me when I first saw it.  The robot appears to orbit the light source for a time before giving up.  I would like to revisit that scenario, but it is difficult to trigger when you are trying.

Last Thoughts

All in all, the Puckbot collector robot was a complete success.  It can collect four pucks and deliver them to the light source successfully most of the time in less than 5 minutes.  There are some cases when a puck gets trapped along a wall or in a corner and the robot fails, but most of the time it succeeded.  I will certainly revisit this robot and tackle these weaknesses.