Posted 27 January 2017

I’m writing this post from the hotel restaurant in Houston, TX, where I am attending a duplicate bridge tournament (one of my many time-wasting interests).  There have been some major changes/improvements to Wall-E2, my wall-following, cat-terrorizing robot,  so I’m taking some time to regroup and think about where I am and where I want to go with Wall-E2.

Wall-E2 has a very ‘simple’ primary purpose – to follow walls and not get stuck.  It has a secondary job of amusing the humans, and terrorizing the cats – but that’s a side-benefit of it’s primary job.  Wall-E2 has been able to follow walls for some time now, and has a reasonable capacity to avoid getting stuck.  However, battery life is limited, and he has to be manually recharged.

In recent posts I describe my efforts to remove the battery life restriction by giving Wall-E2 the capability to charge itself.  This post recaps these changes, and discusses the work needed to integrate the autonomous charging capability into the rest of the system.

Autonomous Charging Subsystem

The autonomous charging system has four components; The  charger module, the  IR homing module, the fixed charging station with its power supply probe and lead-in rails, and the implementation software.  The on-board charging module is complete and has been tested.  The IR homing hardware/software was tested on my old three-wheel robot and provided excellent homing performance.  The fixed station power supply probe design worked well in a bench test with a lab power supply.

System Integration Tasks

Basically, all the new hardware has been designed and tested, at least on the bench with lab power supplies.  Now the challenge  is to get everything integrated into the system.  I see the following tasks:

• Complete the implementation of the fixed charging station.  The lead-in rails and the power probe have both been independently bench-tested, but the two have not been integrated into a complete fixed-point charging station.  Now that I have officially abandoned the under-belly contact array idea, the charging station design has been greatly simplified, so this process is much more straightforward than it might have been.  All I really have to do is connect a +5V power supply to the charging probe, and make sure it  is properly oriented with respect to the lead-in rails.  However, as noted below, there is significant work to be done on the software side to properly manage the charging cycle.
• Integrate the IR homing software from the 3-wheel robot into Wall-E2’s code base.  This may not be all that simple to do. The current navigation/obstacle avoidance code in Wall-E2 is quite complex, so there may well some unintended consequences and speed-bumps in the road to full integration.
• Implement the software required to manage the  the charging  process.  This involves the software to initially detect and then home in on the charging station IR beam, monitor the charging process itself, and then disengage from the charging station at the end of the charging cycle.  As noted above, this may require a significant amount of work.
• Refurbish Wall-E2 and perform system-level testing.  Currently Wall-E2 is missing its entire second-level sensor suite, so this has to be re-attached and reconnected, and the inevitable problems fixed.  The sensor suite isn’t really required for charging subsystem testing, but of course will be for full-up system testing.

Software Integration

On each pass through Wall-E2’s current navigation loop, the algorithm determines what to do  based on the current navigation mode, the current tracking mode, and the current forward distance.

The currently used tracking modes are

TRACKING_LEFT =  tracking wall to left
TRACKING_RIGHT = tracking wall to right
TRACKING_NEITHER = not tracking either wall

The currently available navigation modes are (Currently, only the NAV_WALLTRK and NAV_STEPTURN modes are used):

NAV_WALLTRK = normal wall-tracking mode
NAV_OBSTACLE =  the system is responding to avoid a close-in obstacle
NAV_STEPTURN = the system is (probably) trying to follow an open corner
NAV_STUCK = the system has determined that the robot is stuck
NAV_OPENCNR = the open corner case has been detected

The challenge is to integrate the new ability to detect and home in on an IR beam in order to connect to a charging station to charge the batteries.  In this mode (call it TRACKING_IRBEAM/ NAV_HOMING) the idea is to home in on the IR beam, get captured by the lead-in rails, and connect to the charging probe.  Of course, this all implies that the robot  needs to be charged – otherwise, the charging station should be avoided – not homed in on.  Thus, this capability also implies the need to be able to determine the current state of charge, so Wall-E2 doesn’t spend it’s entire life sucking on the charging teat.  There are only two ways that I can think of to monitor the current charge state; one is to monitor the battery stack voltage, and the other is to use run-time since the last charge as a proxy for charge state.  Either way, this capability will have to be added to the system.

The current navigation code is broken down into three tracking cases – TRACKING_RIGHT, TRACKING_LEFT, and TRACKING_NEITHER.  For each of these cases, new left/right motor motor speed selection is chosen, primarily based on the forward distance reading.   I’m thinking of adding TRACKING_IRBEAM to denote the situation where the battery is sufficiently discharged to warrant charging AND an IR homing beacon has been detected.

Side note: Just came up with a brilliant idea for the case where the robot approaches a charging station, but doesn’t need charging; put some spring-loaded ‘flapper’ doors’ at the entrance to the capture gate such that the forward LIDAR on the upper deck will ‘see’ the flappers, but the IR beam will still be visible by the IR detectors on the lower deck.  When the robot needs a charge (i.e. when the tracking mode is TRACKING_IRBEAM) it can ignore the LIDAR information in preference to IR beam homing, but in normal operation the detection of the approaching flapper gates will cause the robot to execute an avoidance turn – neat (I hope)!

The current tracking mode is determined in the subroutine GetTrackingDir(), which basically computes running averages for the left and right PING distances, and determines which is smaller (if  both averaged distances are > MAX_LR_DISTANCE_CM, then the TRACKING_NEITHER case is declared).  I think I can modify this subroutine to check the battery charge level, and determine whether or not an IR beam has been detected. If both these conditions apply, then the TRACKING_IRBEAM case can be declared.  In the main loop, I’ll have to add an IF block for the TRACKING_IRBEAM case (and maybe change the code to use a switch statement vice IF blocks)

More to come – stay tuned!

Frank