A CLASSIC Robot

Cricket, LogoChip, and Sonar Sensing Independent Craft

Adrien Grise
Tom Kneeland

 

Overall Project Goal

Current Implementation

Project History, Planning, and Milestones

BotFest Issues

Goals for Remainder of Semester

Final Schedule

Project Code

 

Overall Project Goal

Our goal is to build a mobile robot with the ability to navigate a maze, locate a token, and then exit the maze and inform other robots how to locate the token.

 

Current Implementation

We have kept the implementation as simple as possible. The mobile base is built of Legos and consists of a tank tread drive system with enough room to fit a Handy Cricket, the 91.305 development board, and a breadboard. The tank tread drive system distributes the weight of the various logic components, while providing adequate directional control. (See Figure 1 Below)

Figure 1: Overall Design

The Handy Cricket is the main controller for the system. It interprets data provided by 3 sonar sensors, makes appropriate navigation decisions, and controls the motors driving the treads. It also has the ability to convey its navigation information to other similar robots via its IR port. (See Figure 2 Below)

Figure 2: High-Level Block Diagram

For an initial implementation we built a tri-sonar Cricket bus device (See Figure 3 Below). This device controls three sonar devices providing distance (in centimeters) to the Handy Cricket over the bus when requested. The three sonars are connected to the mobile platform at 45-degree angles providing the Handy Cricket with a coarse 90-degree view of its forward surroundings. It is our intention to use two additional sonar inputs, and only those 5 sonar inputs, to navigate the maze. The heart of this device is a LogoChip, which seems to have enough computational "horse power" to continually poll a series of sonar sensors, and respond, upon request, to the Handy Cricket with up-to-date distance readings from all of them.

Figure 3: Tri Sonar Bus Device Design

One of the built-in sensor inputs on the Handy Cricket will hopefully be used with an additional sensor for detecting our "token". For simplicity, we plan to use some kind of a magnet reed switch to detect when our robot drives over the target area.

 

Project History, Planning, and Milestones

 

Originally, we had planned for a mobile robot that could navigate itself around a maze. Ideally, it would locate a target somewhere in the maze, exit the maze, and then instruct another robot to go in and retrieve it.  While we feel this is an achievable goal, this idea has slowly been scaled back to fit within the confines of our semester.

 

We first had to decide what we could accomplish for BotFest.  With approximately 4 weeks from when we started to when we needed to be ready to present our initial phase of our project, we decided to break up the development in to separate milestones:

 

Sonars: How do they work? (BotFest –4 weeks)

We were successful in determining how to wire up and implement a sonar within the first week of our project. We were capable of getting a "value" that represented some distance to a solid object; however, the value did not directly correspond to a specific metric/standard scale. With a bit of tweaking we were able to get a LogoChip-based function to report the distance to a target within roughly +/- 3 centimeters.

 

Using a sonar sensor is fairly simple. There are only two signals that must be dealt with. The first is the "trigger" which tells the sonar device to issue a "ping". It is an "active high" pulse sent by the LogoChip. The second is the Echo Out response from the sonar. This signal is driven high by the sonar device when it issues its ping, and then set to zero when the ping is received.  To calculate distance, the LogoChip tells the sonar sensor to issue a ping, and then it waits for the sonar sensor to indicate the ping was detected. The time between the trigger and echo response is used to calculate the distance using the speed of sound in centimeters. Through trial and error it was determined that using a "waituntil" for the echo response to be set to zero resulted in a very poor measurement. It was suspected that this was related the latency introduced by the Logo virtual machine. We instead implemented this waiting period as a spin loop with an incrementing counter. Using the counter value and the oscilloscope we measured the approximate duration of one iteration of the loop in milliseconds (equal to 3.2ms). This constant is then multiplied to our loop counter to determine the number of milliseconds until the echo is received.

 

The function that triggers the sonar device and calculates the time until the pulse is received is implemented in the "sonar" function which is called by the function "ping":

 

to sonar :trig :echo :trig_port :echo_port
    setping_time 1
 
    ; Set init bit, ping sent out when init is cleared
    setbit :trig :trig_port
    clearbit :trig :trig_port
 
    ; Wait for echo to be raised, signals
    ; that the ping has been sent 
    waituntil  [ ((testbit :echo :echo_port) =  1) ]
 
    ; Wait for echo to be lowered, signalling that
    ; the ping has been received 
    loop
    [
        ifelse ((testbit :echo :echo_port) < 1)
        [
            setping_time (ping_time * 3.2)
            stop
        ]
        [
            setping_time (ping_time + 1)
        ]
    ]
end

 

It should be noted that this function is parameterized to support querying any of the sonars connected to the device. We also utilize the "stop" command to terminate the function when we have received our echo response.  The calculation of the distance in centimeters is performed by the function "ping" called by the "main" routine:

 

to ping :trig :echo :trig_port :echo_port
 
    sonar :trig :echo :trig_port :echo_port
 
    ; sonar_dist = distance in centimeters
    setsonar_dist ((ping_time / 2) * 3.3145)
 
    if sonar_dist > 127
    [
        setsonar_dist 127
    ]
end

 

It simply takes the time, in milliseconds, reported by "sonar", divides it in to to account for the fact that we are not measuring the round trip time of our pulse. It then multiplies this value by a constant value which represents the number of centimeters sound travels in one millisecond.

 

The rest of the LogoChip code is concerned with the actual bus device implementation. It can all be found in the "main" routine, which first initializes the various LogoChip bus pins using the "init" function:

 

to init
    write portb-ddr $2B
    write portc-ddr $05
    clearbit s0_trig s0_trig_port
    clearbit s1_trig s1_trig_port
    clearbit s2_trig s2_trig_port
    clearbit s3_trig s3_trig_port
    clearbit s4_trig s4_trig_port
 
    setwhich_sonar 0
end

 

It then sits in an infinite loop. Its first priority is responding to bus requests by the Cricket for distance measurements. It is assumed that the Cricket is busy plotting the movement of a mobile robot and therefore should encounter as little latency as possible. When the device is not responding to a CricketBus request it is polling the sonar sensors in a round robin fashion, one sensor per iteration of the loop. The variable "which_sonar" is used to keep track of which sensor should be scanned during a particular iteration. The results of each sonar sensor is stored in its own global variable, one for each sonar sensor connected to the device.

 

A 2-wheeled bot with a 3rd stationary "peg" was built as well. This proved to be extremely fragile and continuously broke down. A new design would be required.

 

Cricket-Logo Chip Bus: Inter-process communication (BotFest –3 weeks)

Using our earlier lab as a base, we were quickly able to have the LogoChip communicate to the Cricket the distance value determined by our sonar function. The Cricket will send a request via a ‘bsr’ command to the LogoChip requesting a reading from a specific sonar.  Each sonar was in turn polled and a data set of the current sonar values was then available for navigational analysis.  This code was packaged in the read_sonar_sensors function call:

 

to read_sonar_sensors
    ; Call to the bus device and ask for its four sonar readings
 
    ; Our first bus write/read will address the Sonar device directly,
    ; the subsiquent bus writes/reads are not addressed to a specific
    ; device, but are needed to read in all the values returned by
    ; the sonar device
 
    sets0_dist bsr $180
    sets1_dist bsr $181
    sets2_dist bsr $182
    sets3_dist bsr $183
    sets4_dist bsr $184
    …
end

   

A 4-wheeled bot was developed in parallel to hold the Cricket and the LogoChip breadboard and replace the 2-wheeled-bot. 

 

Figure 4: 4-Wheeled robot

Cricket code was now developed to help drive the bot forward and an initial attempt at obstacle avoidance was attempted.  The bot would move forward and upon the detection of a wall, would stop and beep.  This was successful.  A small code change to the Cricket tried to make the robot turn left instead of just stopping, but the bot’s motor lacked the torque necessary to turn the bot.  Another design change was required.

 

Chassis: Mechanics of motion with Lego  (BotFest –2 weeks)

A new “tank”-styled bot was developed allowing the bot to turn much easier than before. 

Figure 5: New "tank"-styled robot

Upon installing the Logochip and the Cricket, however, the power drain was too much for the Lego motors.  Either the bot was too heavy, the batteries too drained, or there was not enough torque to move to bot forward.  An additional gear was added to the bot to increase its torque.  Additional testing proved that the torque was enough and basic obstacle avoidance was tested again.  The bot’s sonar limited it’s turning angle, however, leaving the bot turning only about 45-degrees before moving forward into the contact with the wall.

 

Milestone Slippage: Extra Sonars & Power  (BotFest –1 week)

Over Spring Break, instead of working on basic navigation, we needed to work out the kinks of our simple bot mechanics and add some extra sensors to help determine object locations.  Two additional sonars were added at 45-degree angles off the front sonar.  Navigational algorithms on the LogoChip were updated to poll all three sonars serially and report values back to the Cricket. 

Figure 6: Tank robot with new frontal 3-sonar array

Navigation: Phase 1: Wall Avoidance  (Target date: BotFest!!!)

Electric power seemed to be limiting the bot.  A decision was made to wire the two 4-AA battery packs of the bot together to provide move voltage to the Lego motors. A voltage regulator was added after power spikes were noticed when resetting the Cricket due to the linked power supply.  Navigation algorithms were updated and more testing was done.  The bot could now successfully (and comparatively quickly) avoid collisions with solid objects in front of it, turning to avoid them until all was clear ahead of it.  The code to do so was developed by trial and error as the necessary power and directional changes of the motors were not known at the initial time of development.  The code to implement the wall avoidance looked to see if any of the 3 forward-facing sonars detected an object within 20 centimeters and if so, set a flag to indicate a front collision warning.  Commands were then given to reverse the direction of the left-side motor and cause the bot to turn left until such a time when all 3 sonars indicated there was no frontal collision warning.  At that point, the collision flag would be cleared and the motors set to drive the bot forward again.  This was coded in the main function as the following:

 

to main
 
     …
 
    loop
    [
        setfront_warn 0
 
        read_sonar_sensors
 
        ifelse s0_dist < 20
        [
           setfront_warn 1
        ]
        [
            ifelse s2_dist < 20
            [
               setfront_warn 1
            ]
            [
                if s3_dist < 20
                [
                   setfront_warn 1
                ]
            ]
        ]
 
        ifelse front_warn = 1
        [
            beep
 
            if turn_mode = 0
            [
                setturn_mode 1
 
                ; Determine if there is more room to 
                ;   the left than the right
                ifelse s1_dist > s4_dist
                [
                    ; left turn
                    b, thisway
                    ab, on
                ]
                [
                    ; right turn
                    a, thisway
                    ab, on
                ]
            ]
 
 
        ]
        [
           setturn_mode 0
           b, thatway
           a, thatway
           ab, on
        ]
  ]

 

 

The bot was presented at BotFest and was fairly successful in demonstrating most of what we had hoped to show.

 

 

BotFest Issues

While we did accomplish the goals we had initially set out for our project for the BotFest presentation, we had several reach goals that we did hope to have enough time to fulfill, but were unsuccessful due to timing constraints.  These included:

 

Extra Sonar Placement

With three sonars in place on our forward array of sonars, our bot was able to successfully move around the inside of a cube without crashing into any walls.  However, the limited amount of sonars we had did not allow us to measure the open space on either side of the bot.  In doing so, we would have been able to turn the bot to the side that had the most open space versus just turning left at every obstacle.  A fourth and fifth sonar would have been invaluable in this sense.  However, we had only one extra sonar and that sonar did seem to be faulty.  We have since procured two more sonar sensors and hope to incorporate them into the bot in the coming weeks.

 

Improved Navigation Algorithms

Even without the additional computation needed for extra sonars, we had hoped to tweak the algorithm of the cricket portion of our code to allow the bot to get closer to an object before deciding to turn.  With that distance currently set at roughly 20 centimeters, this distance limited the complexity of the area that the bot could be tested in.  At BotFest, we were only able to display the bot in a large open, uncluttered space. If other walls or corridors were installed, they would fall within the 20-centimeter range of the obstacle detection algorithm and the bot would start to turn - and would it would turn continuously.  The limited size of our display space and lack of time to alter the algorithm did not allow us to fully display the capabilities of the bot.  In the maze setup in Holly Yanco's lab, the bot performed quite well.  One of our first improvements to the bot will be to alter the algorithm and allow the bot to get closer to objects before turning.

 

Improved Drive Chain Mechanics

As our BotFest demonstration showed, our bot, built out of Legos, is not the most permanent of structures.  It constantly required tightening or the axles and knobs holding the treads together would spread apart and eventually come right off.  We also hope to add two more motors to the bot, for total of four, and give it more torque to travel over more varied terrain - albeit still flat - such as carpet and other non-tile flooring. The physical structure of the bot limited the placement of the extra motors, as did our ability to control them.  With the Cricket having only 2 motor ports and no way to connect the motors together to co-signal them, we did not bother installing them.  We have since acquired Lego-based wiring that will allow us to link to motor together and control both with one command.

 

Goals for Remainder of Semester

We are unsure if we will be able to accomplish all of the goals we set out to do initially back in mid-February, however, we feel that we can still get a bot that has some fairly good capabilities together by the end of the semester.  These goals include some of the items that we had hoped to finish for BotFest but also some more software-based improvements

Extra sonar placement (Planned completion date: BotFest +2 weeks)

Improved Navigation Algorithms for 4th and 5th sonars (Planned completion date: BotFest +2 weeks)

Improved Drive Chain Mechanics  (Planned completion date: BotFest +2 weeks)

Improve Navigation Algorithm:  Getting around a maze (Planned completion date: BotFest +3 weeks through +7 weeks)

Reach Goals

 

Maze Solving Algorithms

We believe that the real time intensive portion of the project will involve the coding of a navigational algorithm that, given input data from the sonar array, can adequately maneuver the bot around a maze and locate a target.  Given a solid, functioning basic bot that can “see” its environment, we plan to experiment with various freely published maze algorithms available online.  We hope to find one that is easy enough for us to translate into Logo, small enough to fit on the Cricket, and sufficient to carry out our end goal of target location.  We expect to probably spend roughly 1 week narrowing down our choice of algorithms, possibly taking portions of several and segments of our own creation and combining them in to a rough design of the code.

 

How Much to Map

Whether the bot must map the entire maze or just enough to find a target is still to be decided.  We will need to determine how much information we want to store and how to store it on the Cricket.  Once the bot has found its target, it should be able to reverse its direction and find it’s way out with minimal use of the sonar array.  We hope that it will not have to re-map a way out to the maze exit and instead leverage what it has learned about the maze (dead ends, short cuts, etc.).

 

Target Location

Target location is a sizeable task in itself.  After watching some of the BotBall competitions at BotFest, it was interesting to see how competitors designed ways to recognize targets.  We may need to overly simplify this section of code to accomplish anything meaningful, perhaps using a magnetic reed switch to indicate when the bot “luckily” rolls over a metal target. Otherwise, we would have to design a system to either recognize an object visually, via optics or IR, or using some sort of echo-location.  If we can accomplish the above, we feel that we will have a fairly solid project for the end of the semester.

 

Reach Goals

However, if we can accomplish the above prior to the end of the semester, reach goals would include:

 

Final Schedule

This is a rough schedule of what we hope to accomplish in the closing weeks of this semester.

 

Functionality to Add

Expected Completion Date

Extra sonar placement

Additional code for new sonars

Improve mechanics

April 12, 2003

Maze algorithm design

April 19, 2003

Initial coding of maze algorithm (phase 1)

April 26, 2003                                            

Mode maze algorithm code (phase 2)

May 3, 2003

Target acquisition/pick-up

May 10, 2003

Table 1: Schedule of remaining work

 

Project Code

This is the code used to implement what we demonstrated at BotFest on March 29, 2003.

 

Cricket Code

 

LogoChip Code