CajunBot: A Case Study of anEmbodied System

Istvan S. N. Berkeley,Philosophy and Cognitive Science,

The University of Louisiana at Lafayette,(istvan@louisiana.edu)

Two Views, I(From Cowart, 2006)

_ Classicist/CognitivistView

_ 1. Computer metaphorof mind; rule-based,logic driven.

_ Embodied CognitionView

_ 1. Coupling metaphorof mind; form ofembodiment +environment + action,constrain cognitiveprocesses.

Two Views, II

_ Classicist/CognitivistView

_ 2. Isolationistanalysis - cognitioncan be understood byfocusing primarily onan organism'sinternal processes.

_ Embodied CognitionView

_ 2. Relational analysis-interplay among mind,body, andenvironment must bestudied to understandcognition.

Two Views, III

_ Classicist/CognitivistView

_ 3. Primacy ofcomputation.

_ 4. Cognition aspassive retrieval.

_ 5. Symbolic, encodedrepresentations

_ Embodied CognitionView

_ 3. Primacy of goal-directed action,unfolding in realtime.

_ 4. Cognition asactive constructionbased upon anorganism'sembodied, goal-directed actions

_ 5. Sensorimotorrepresentations

Background: The DARPA GrandChallenge 2005

_ In June 2004, DARPA announced their GrandChallenge for 2005.

_ The goal of the Challenge was for teams toconstruct autonomous vehicles that “couldnavigate a challenging course over varyingterrain.”

_ The detailed rules, issued in October 2004,specified that the course would be no more than175 miles (282Km) long and would consist ofroads, trails and off-road desert areas, whichcontained a variety of obstacles.

Team CajunBot

_ The University of Louisiana at Lafayette enteredthe Grand Challenge as 'Team CajunBot'.

_ This team had also participated in the 2004Grand Challenge.

Mechanical Configuration

_ Based upon aRecreative IndustriesMAX IV ATV.

_ Six wheel drive, withskid steering.

_ Powered by 28hpKohler engine.

_ Electrical powersupplied by twoHonda generators.

Sensor Systems

_ Oxford TechnicalRT3000 InertialNavigation System,enhanced by Starfiredifferential GPS, froma C&C Technology C-Nav receiver.

_ Up to Five LIDARlaser obstaclesensors.

Architectural Overview

Hardware Software

Sensors

Actuators

D

r

i

v

e

r

s

D

r

i

v

e

r

s

Obstacle

Detection

Steering

Controller

Path

Planner

Grid, with

obstacles

Set of

waypoints

Special Features of The CajunBotSituation.

_ One of the things that makes CajunBotinteresting in the current context is that thedevice has to operate in a real worldenvironment, in real time.

_ This presents additional constraints upon thekinds of solutions to problems that can be usedwith CajunBot. For instance;

� Sensor outputs cannot be 'idealized',

� The actual manoeuvrability of CajunBot must betaken into account (rather than an idealized version)

� Processes must operate fast enough to preventmishaps.

Real World Solutions to Real WorldProblems

_ In what follows, various subsystems ofCajunBot will be examined to illustrate how thereal world nature of the task at hand influencedthe ways that solutions to particular problemswere implemented within CajunBot.

_ The results show an interesting interactionbetween 'embodied' type solutions and moretraditional solutions.

_ The results are not always what one mightexpect!

Subsystem 1: The Sensors

Hardware Software

Sensors

Actuators

D

r

i

v

e

r

s

D

r

i

v

e

r

s

Obstacle

Detection

Steering

Controller

Path

Planner

Grid, with

obstacles

Set of

waypoints

Subsystem 1: The Sensors

_ In the words of one of the CajunBot teammembers (Tony Maida),

�“...the vehicle moves like a brick on wheels.”

_ Given that CajunBot could travel at speeds ofup to 28 mph (45 Kph), over rough terrain, thismeant that there was going to be an issue ofintegrating the outputs from the LIDAR lasersensors.

_ This was because where obstacles weredetected by these devices would change,depending upon the vertical angle of thevehicle.

Sensors: Possible Solutions

_ There are roughly three ways that the up anddown motion of the LIDAR laser sensors can behandled:

� (1) Use a vehicle with a very good suspension, soas to dampen motions,

_ This was not an option for CajunBot, due to the hardwareavailable

� (2) Mount sensors on a platform stabilized by aGimbel, or other stabilizers,

_ Although this was a strategy used by many teams, costprohibited it being used on CajunBot.

� (3) Mount all sensors on a single rigid platform.

_ This was the solution selected. It turned out to provide asurprising advantage.

Sensor Solutions: Pose

_ The difficulty caused by the up and downmotion of the vehicle was handled by using'pose' data from the Inertial Navigation System.

_ By including this data, it became possible todetermine the complete location the LIDARsystem was actually reading.

_ In fact, this approach actually conveyed adistinct advantage, as it had the effect ofincreasing the effective range of the LIDARsystem

_ This also avoided the 'single point of failure'problem that effected Gimbel based solutions.

Two Further Sensor Problems

_ Occasionally, the INS/GPS system produced'spikes', caused by satellite communicationproblems. This data needed to be filtered outand discarded.

_ The INS/GPS system also suffered from aphenomenon know as 'Z-drift'.

_ The system often exhibited a drift in Z values,reported over time.

_ Even when the vehicle was stationary, a drift inZ values of 10cm – 25cm, could arise. Thiscould cause a flat surface to appear uneven.

Sensor Solutions: Spikes

_ Inputs to this sub-system came from both theINS/GPS system and from the LIDAR scans.

_ The INS/GPS data was filtered to remove anyspikes. This data was then used to compute theglobal coordinates of the LIDAR scans.

_ This avoided corrupted data entering the datastream.

_ When the GPS system suffered a mishap, therewas still data available from the InertialNavigation System.

Sensor Solutions: Z-Drift

_ The Z-drift issue was handled by taking intoaccount the time that a particular global pointwas observed.

_ Global points were thus represented as a 4-Dvalue. This had the format (X, Y, Z, and time-of-measurement).

_ By ensuring that points have a temporaldistance between them of less than 3 seconds,when used in further computations, it waspossible to overcome the Z-drift problem.

Another Sensor Problem: DataIntegration

_ A further problem arose from the fact that thedifferent sensor systems generated data atdifferent rates.

_ The Inertial Navigation System (INS) generateddata at 100Hz, producing data at 10msintervals.

_ The LIDAR laser sensors generated data at75Hz, producing data at 13ms intervals.

_ Thus, the most recent INS reading, when aLIDAR scan is read, may be up to 9ms old.

Sensor Solutions: Data Integration

_ The data integration issue was handled by the'blackboard' system, through which differentCajunBot modules communicated with oneanother.

_ Instead of just fusing the most recent data fromthe LIDAR and INS/GPS sensor systems,global points were computed by interpolatingthe state immediately before and immediatelyafter a LIDAR scan was read.

_ In some senses, this blackboard system wassomewhat analogous to working memory in acognitive system.

Sensor Subsystem: Comments

_ It is clear that the embedded real world natureof CajunBot presented some interestingdifficulties with the sensor subsystems.

_ The solutions to these problems were oftenquite conventional in nature.

_ However, the issue concerning the up anddown motion of the sensors, was less thanentirely conventional and indeed, by takingadditional information about the environmentinto account, CajunBot was actually able to gainan advantage.

Subsystem 2: Path Planning

Hardware Software

Sensors

Actuators

D

r

i

v

e

r

s

D

r

i

v

e

r

s

Obstacle

Detection

Steering

Controller

Path

Planner

Grid, with

obstacles

Set of

waypoints

Subsystem 2: Path Planning

_ Path planning, as a type of search, is avenerable topic in traditional ArtificialIntelligence research.

_ Planning systems can be characterized asbeing 'deliberative', or 'reactive'.

_ “Deliberative systems that embody powerfultechniques for reasoning about actions and theirconsequences often fail to guarantee a timelyresponse in time-critical situations. Reactivesystems that respond well in time-critical situationstypically do not provide a reasonable response insituations unforeseen by the designer.” Blythe andReilly, (1993).

Path Planning: Deliberative vs.Reactive

_ In order for CajunBot to perform successfully, itneeded to employ elements of both strategies.

_ A deliberative strategy would be helpful inensuring that CajunBot reliably reached goalsalong the specified route.

_ A reactive strategy would be helpful in ensuringthat CajunBot avoided obstacles that appearedalong the way.

Path Planning: G-Nav and L-Nav

_ The long range planning system used withCajunBot, G-Nav, was based upon a sequenceof static GPS waypoints, that were held in aroute description file.

_ The local planning system, L-Nav, providedsub-goals that enabled the navigation betweenthe static waypoints.

_ The L-Nav system was able to take into accountthe presence of local obstacles and make theappropriate adjustments to the relevantsubgoals.

Path Planning: L-Nav Metaphor

_ The path planning method used by the L-Navsystem rests upon a metaphor of chargedparticles.

_ The idea is described in Maida et al.(forthcoming) as follows,

_ “...the robot is (say) positively charged and adesired goal is negatively charged. Obstaclesare given the same charge as the vehicle. Thesimulated force vectors can control the steeringof the actual robot in the actual world so that therobot approaches the goal while avoidingobstacles.”

Path Planning: Is L-NavDeliberative, or Reactive?

_ The fact that the L-Nav system enabledCajunBot to escape from dead end canyonshas been suggested as evidence that thesystem has deliberative properties.

_ On the other hand, the real-time obstacleavoidance capacity, appears to exhibit reactiveproperties.

_ In fact, there was little agreement (though muchdebate) over this question amongst members ofthe CajunBot team!

_ L-Nav is probably best thought of as being ablended system.

Path Planning: L-Nav ExpansionRegions

_ Obstacles were represented in the L-Navsystem as having an 'expansion region' aroundthem.

_ This expansion region effectively madeobstacles larger than they really were.

_ The purpose of the expansion region was toprovide a margin of safety, so as to allow for“...imperfect steering or other unanticipatedphysical event[s].” (Maida, et al., forthcoming).

_ Given the potentially catastrophicconsequences of a collision between CajunBotand a obstacle, this was a prudent andnecessary affordance.

Path Planning: Waypoint Filtering

_ A final issue that the path planner had to takeinto account was the limits of manoeuvrability ofCajunBot.

_ Particularly at speed, CajunBot was not able tomake rapid turns or sharp changes of direction.

_ This was handled by first identifying places in aproposed path that would involve a change ofdirection.

_ Potential waypoints in a proposed path werethen filtered to ensure that only paths that wereconsistent with the capabilities of CajunBotwere selected.

Path Planning: Comments

_ The G-Nav subsystem was manifestlydeliberative and traditional in the way that itfunctioned.

_ The L-Nav subsystem, by contrast appears tohave had both deliberative and reactivefeatures.

_ Furthermore, other aspects of the L-Nav systemhad to make allowances for the fact thatCajunBot had to operate in a real worldenvironment and was subject to real worldconstraints.

Subsystem 3: Steering Control

Hardware Software

Sensors

Actuators

D

r

i

v

e

r

s

D

r

i

v

e

r

s

Obstacle

Detection

Steering

Controller

Path

Planner

Grid, with

obstacles

Set of

waypoints

Subsystem 3: Steering Control

_ Steering CajunBot presented some interestingchallenges.

_ This was in part, because the steering systempresented a classic control system problem.

_ As CajunBot turned towards a new heading, itwas necessary to stop turning before the exactnew heading was reached, in order to preventover steering.

_ This problem arose in large part due to the realtime nature of the problem.

_ Both software systems and hardware systemssuffered from temporal lag.

Steering Control: Solution Part 1

_ The steering controller had the current_headingof CajunBot and the desired_heading asprimary inputs.

_ There were other inputs, that encode currentspeed and other information, but they will beoverlooked here.

_ The first step in the process was to computeError, by subtracting present_heading fromdesired_heading.

_ Then the Error_rate was computed, bysubtracting the Error from the previous_error,with respect to the time since the last controlloop execution.

Steering Control: Solution Part 2

_ The Proportional term (P-term) was thencomputed by multiplying the Error by a constantK

p.

_ The Differential term (D-term) was thencomputed by multiplying the Error_rate by aconstant K

d.

_ The constants Kp

and Kd

were set by a trial anderror, in field trials.

_ The Proportional term offered a measure ofhow much error needed to be corrected.

_ The Differential term gave a metric of the rate ofincrease, or decrease in Error.

_ The P-term and D-term were usually of oppositesigns, such that they can cancel one another.

Steering Control: Solution Part 3

_ Finally, the value of the steering command wascomputed as follows:

Steering = Kp(Error) + K

d(Error_rate)

_ Using this method, it was found that thesteering problem could be solved satisfactorilyfor CajunBot.

_ When the results of this system were passed tothe actuators, CajunBot was able to navigatesuccessfully, without running into problems ofover steer, under steer, or falling into oscillatorystates.

Steering Control: Comments

_ Once again, there were some highly dynamicelements that had to be taken into account inthis solution.

_ These dynamic elements were a directconsequence of the embodied nature of theCajunBot steering task.

_ These dynamic elements could have beenabstracted away from, or just ignored if thesystem just had to operate in a highly abstractdomain, which could idealize the environment(i.e. if this system was deployed in a purelyclassical domain).

Subsystem 3: Simulations

Hardware Software

Sensors

Actuators

D

r

i

v

e

r

s

D

r

i

v

e

r

s

Obstacle

Detection

Steering

Controller

Path

Planner

Grid, with

obstacles

Set of

waypoints

Subsystem 3: Simulations

_ Simulation environments were used extensivelyin the development of CajunBot.

_ Given that simulated environments have nodirect contact with the real world, they appear tofall into the 'classical/cognitive' approach farmore than they do the 'embodied' approach.

_ Yet, they played a crucial role.

_ There were roughly two strategies used withsimulations;� Targeted simulations were used to answer

questions about particular problems.

� Comprehensive simulations were used to solve fullsystem integration and testing problems.

Simulations: Targeted Simulations

_ Potential Field Visualizations:� These were used extensively in the development of

the L-Nav module.

� Different methods of generating potential field flowmaps were tested, to determine which methodsgave the best results.

� This testing led to an abandonment of the neuralnetwork based potential field generation strategythat was initially used, in favour of using simplelinear potential fields.

_ G-Nav and L-Nav interactions:� Initially, G-Nav invoked L-Nav whenever an object

was detected in sensor range.

� The method of transforming G-Nav and L-Nav intoconcurrent processes was perfected by simulation.

Simulations: ComprehensiveCajunBot Simulations, Early Stages

_ Comprehensive CajunBot simulations wereconstructed by incrementally adding more andmore realism to the simulations, both withrespect to CajunBot and to the environment.

_ The addition of realistic steering delays broughtabout something of a crisis, as this revealedthat even at low speeds, the direction of travelof the system would oscillate, leading tocrashes.

_ Fortunately, it was also discovered from thesesimulations that the adoption of the waypointinteraction system between the G-Nav and L-Nav systems improved these steering issues.

Simulations: ComprehensiveCajunBot Simulations, Later Stages

_ As the integration of the various systems intothe simulations continued, the processcontinued to provide useful information and tohighlight bugs.� Coordinate transformation bugs were detected. For

example, a failure to translate between meters andcentimetres, when reading from the blackboardcommunication system was discovered.

� A few waypoint extraction bugs were also found.

� The L-Nav system was found to give uninformativeerror messages when it encountered unanticipatedtypes of data from the richer simulationenvironment.

� This suggested that a richer simulationenvironment, that used a broader spectrum of datashould have been used in earlier simulations.

Simulations: Simulated Performance

_ Using the simulation environment, the testing ofCajunBot in various simulated situationsbecame possible. This too was informative.� It was possible to determine the performance of the

system when an obstacle (for example, a van) waslocated exactly on top of a G-Nav global waypoint.

� When this eventuality was tested, CajunBotperformed perfectly.

� It was also possible to determine how the systemwould perform under various circumstances, suchas when CajunBot was in a dead end canyon, withthe next way point directly behind the end of thecanyon.

� The simulations showed that CajunBot would alsomanage this situation effectively, for the most part.

Simulations: Comments

_ It is interesting to note that the use ofsimulations was motivated in large part by realworld factors, thus suggesting that embodimentmay not really be quite as far away from theseotherwise classical approaches as might beinitially supposed.

_ Actual system testing has the followingdrawbacks;� It is expensive to conduct,

� It is time consuming to conduct,

� It carries with it a risk of damage to the hardwarecomponents of CajunBot.

_ Simulations were used, in part, to mitigateagainst these drawbacks. They played animportant role in developing, refining andtesting of CajunBot.

CajunBot in Action

A video of CajunBot in the Qualifying round.

The Outcome

_ Having made it through the qualifying rounds,CajunBot competed in the final of the GrandChallenge at Primm, Nevada, with 23 otherteams.

_ CajunBot ran well for the first 17 miles of theChallenge.

_ Then CajunBot was ordered to pause, in orderto provide a safe distance between it and othercompetitors.

_ However, after this pause, CajunBot nevermoved again and was eventually eliminatedfrom the competition.

What Happened?_ Arun Lakhotia, of Team CajunBot described

what happened:

“CajunBot was put in pause mode for about fiftyminutes to allow other oncoming bots on thetrack to clear. In the pause mode CajunBotpulls its breaks fully, which means the motorsare engaged to their maximum capacity.Normally at this state the motor should lock andnot use power. But for some reason, the motorcontinued to drain power, that too very highamperage. A sustain draw of that level of powerfor fifty minutes fried the motor.”

The Underlying Cause_ A few days prior to

the Challenge,CajunBot'stransmission failedand had to bereplaced.

_ When the newtransmission wasinstalled it was half aninch out of alignment

_ This is what causedthe actuator motor tostay powered up andburn out.

_ Engineering failuresare another peril ofembodiment!

Conclusions

_ It is clear that CajunBot made used oftechniques that were consistent with both theClassical/Cognitive view, as well as techniquesthat were consistent with the Embodied view.

_ This suggests that the two views should not beseen so much as competitors, but rather ascomplimenting each other.

_ Thus, the evidence from studying thesubsystems of CajunBot seems to suggest thata compatiblist position on the two views is thecorrect one to take.

_ Furthermore, as the philosopher of sciencePaul Feyerabend has notoriously argued,employing more than one methodology on aproblem has distinct advantages.

Acknowledgments

I wish to thank Anthony Maida, Suresh Golconda,Arun Lakhotia, and the rest of the CajunBot Team

for all their assistance in preparing this talk.

For further details on CajunBot, seehttp://www.cajunbot.com.