Robot Building Lab: Multiple Behavior Control DEMO Light-state and ground-state sensing in parallel...

DEMO Light-state and ground-state sensing in

parallel Use states in algorithmic control of:

– Light following– Obstacle avoidance (via ground sensing)

Lab 4: Bump sensors, crash detection, IR sensors for obstacle proximity detection and tracking, multiple behavior control

Lab 4

Bumpers, IR Sensing, and Multiple Behavior Control

http://plan.mcs.drexel.edu/courses/robotlab/labs/lab04.pdf



Today

Touch sensors and bumpersInfra red proximity sensingObstacle avoidance and trackingReactive controlSubsumptionPriority-based control

MicroswitchesSenses mechanical movement – digital – either on or off

Switch Sensor

•In the relaxed, un-pressed state, the common terminal is connected to the normally closed contact;

• when pressed, the common terminal moves to the normally open contact.

(copyright Prentice Hall 2001)

Digital Sensor

• Nine digital sensor ports connect to circuitry on the HB that interprets each sensor’s Vsens voltage as a digital true/false

Vsens > 2.5 v, signal is logic one

Vsens < 2.5 v, signal is logic zero

• To connect switch to digital input circuit:

– Wire between the sensor signal line and ground

Digital Inputs


Use of Touch Sensor as Bumper

(Courtesy of Bennet)

Switch Sensors

Switch Sensor Applications

Left- and Right-Hand Switch Construction

Design for a Simple Touch Bumper


Switch Sensors

Switch Sensor Applications

HandyBug Bumper Design• rotational and sliding pivot points allow the bumper to react to pressure from any forward direction

Design for Bi-Directional Touch Bumper• can detect pressure from front or behind• movement in either direction pushes levered arm away from contact sensor• rubber bands pull arm back onto switch when pressure is released


Bumper Example

Today


Review: Reflective Optosensors

• Active Sensor, includes:

•Transmitter: only infrared light by filtering out visible light

•Light detector (photodiode or phototransistor)

•Light from emitter LED bounces off of an external object and is reflected into the detector

•Quantity of light is reported by the sensor

•Depending on the reflectivity of the surface, more or less of the transmitted light is reflected into the detector

•Analog sensor connects to HBs analog ports


IR Variations

IR emitter/receiver pair

Wiring IR

•emitter and detector, have logically separate circuits, though they are wired to the same connector plug

• The emitter LED (LED1), is wired to the Handy Board’s +5v power supply through R1, the current-limiting resistor

– R1’s value can vary 220-47, depending on how much brightness is desired from the emitter LED

• Detector Q1, shown as a phototransistor, is wired between ground and the sensor signal line—just like a photocell

Reflectance Sensor Interface Diagram


Proximity Sensing with Infrared


•Proximity sensing:

•reflect IR off nearby object

•detect returned light

•emitter and detector point in same direction

• Modulated light

•By rapidly turning on and off, the source of light can be easily picked up from varying background illumination

•With modulated light detector, object is either present or absent

•Modulated light is less susceptible to environment variables but non-modulated light magnitude sensing/thresholding works also

•Could try to determine object’s distance as well but, …

Re-Visiting IR Calibration

IR is very sensitive to ambient lighting, different color obstacles, varying distances, differing lighting conditions

Combining Light and IR to Infer Distance

IR = f(color, reflectance, ambient light, distance)

Don’t have a sensor that measures color Distance is what we want Can condition based on ambient light and

hope that all the obstacles are the same color/reflectance

Correcting for Ambient Light

• Need to differentiate between transmitted light and normal “ambient” light

• Can do so by using photosensor to read ambient light levels with transmitter off

•Can either use external photosensor

•Or use packaged photosensor if wired correctly

•Subtract ambient light from each IR reading

•Alternating ambient and IR readings

Wiring an LED to bit 2 of Port D (Serial Peripheral Interface) Pin

int active_read(int port){int dark, light; /* local variables */dark= analog(port); /* reading with light off */bit_set(0x1009, 0b00000100); /* turn light on */light= analog(port); /* reading with light on */bit_clear(0x1009, 0b00000100); /* turn light off */return dark - light;}


Today


Review: Closed-loop Control

Drive parallel to wall Feedback from

proximity sensors (e.g. bump, IR, sonar)

Feedback loop, continuous monitoring and correction of motors -- adjusting distance to wall to maintain goal distance


Review: Separate Sensor State Processing from

ControlFunctions might each make use of other sensors and

functions – need to decide how to implement each


Use Proximity Sensor to Select One of Three States

Sensor used to select one of three states


Obstacle Avoidance and Tracking Using IR

Have continuously running task update IR state:– Left, right, both, neither

If one obstacle detected use closed-loop control to keep it away from robot

If two obstacles detected– Either assume you can’t pass

and treat like bump– Or try to pass in-between with

closed-loop control – Depends on how you

mounted/shielded your sensors, how you set your thresholds, and any ability to differentiate distances

Today


Review: Algorithmic Control

Pre-program all mode changes to achieve a desired task– Program can include deliberative and

reactive components– But programmer explicitly manages

interactions as a series of linear program statements

– Open-loop timed actions can be used– Closed-loop actions with sensing can also be

used but, it doesn’t change order of control flow

Review: Groucho Algorithmic Control Program


Ball-harvesting Algorithm:1. Drive to position 12. Stop when wall struck3. Rotate4. Climb ramp5. Dump balls6. Drive along divider until wall struck7. Rotate8. Dump more balls9. Rotate10. Drive down ramp until wall struck11. Rotate, repeat

Algorithmic Control Issues

Most effective when the robot’s world and its interactions with it are well-structured– Manipulator arms in factories typically use algorithmic

control with great success Loses its appeal when the robot must deal with unexpected

situations When it is extended to deal with error situations, the

algorithmic method becomes a complicated tree of branching decisions that is hard to design and debug


Reactive Control

Individual robot behaviors react quickly to sensor state changes

Robot’s program is organized around a collection of separate mini-programs, all running at once and able to take control of the robot as they see fit, for example:– a touch sensor process, which monitored the robot’s

touch sensors and caused the robot to back up and turn when it hit something

– a periodic turn process, that caused the robot to take a turn every now and then

– and a wander process, that caused the robot simply to move

Reactive control excels in complex situations with many unpredictable interactions

It requires a new way of thinking to design a system that works properly only as the result of many small interactions rather than a master plan


Using Reactive Control: Reactive Groucho

•Would it be possible to devise an effective reactive control program for Groucho’s task?

•Main behaviors for getting work done:

– Search activates when Groucho is on its own side and isn’t carrying any balls, and drives the robot downhill—toward the ball trough, where balls should be waiting.

– Scoop is intended to run after Search, when Groucho reaches the far wall on its side. Then Scoop triggers and turns Groucho so that it can pick up some balls.

– Deliver should trigger next, causing Groucho to drive uphill.

– When the robot drives over to the opponent’s side Dump activates, releasing the balls.

– Then Return can become active, when Groucho notices it is on the opponent’s side and has no balls.



• Three supervisory processes help make sure Groucho doesn’t get stuck as it performs its task:

• Panic will drive the robot onto the opponent’s side (if it isn’t already there) when the contest round is about to expire, as a safety measure

• Touch makes sure that Groucho does not get wedged if it runs into a wall unexpectedly

• B-Brain monitors all of the other behaviors and executes an emergency “get unstuck” action if it notices that Groucho has been lodged in the same task for too long.




Today


Subsumption

The basic elements (behaviors) of reactive control are sound

But how to make them work together is not well-defined Need more organizational guidelines

Rodney Brooks’ (MIT) solution: subsumption architecture

Central idea:

– more sophisticated robot competencies should be built on top of simpler ones

– Example: a robot that must walk should first learn to stand. Later behaviors can “exploit” earlier ones

Also referred to as “behavior-based control”


Subsumption Design Principles

Complex behavior may not need a complex control system

In systems with many parts, the parts should be simple and the interfaces between parts simple – careful thought to system decomposition

Relative positioning more useful than exact positioning

Designing exact behavior in artificial environments of polyhedra will not lead to useful behavior in natural environments

Built-in self-calibration aids robustness

Problem Decomposition

1. Functional decomposition2. Behavior-based decomposition

Divide problem into pieces, solve subproblems for each piece, compose solution

Traditional Functional Decomposition

Conceptualize task in terms of internal workings of solution

Divide into multiple functional modules that are sequenced to achieve the desired functionality

Information flows across chain Robot cannot do anything unless entire chain is

implemented Structure somewhat resistant to easily changing

pieces within chain – effects of change propagated across chain

Behavior-Based Decomposition

Each level is carefully engineered to have the desired real-time control behavior for that competency – making use of lower levels as needed (as subset of competency)

Higher levels have more complicated, specific behavior, and require more time-consuming computation

Build layers of control

Decompose problem into levels of competence with respect to external behavior of robot

Each level has access to sensors and actuators

Subsumption-Based Behavior Arbitration

Build layers of control to match levels of competency

Fully debug each layer before moving upwards

Subsumption as a form of arbitration across layers

Higher level layers subsume roles of lower level layers – suppress outputs of lower layers, and inhibit data paths in lower layers

Lower layers must always form a complete operational control system

Subsumption Benefits

Built-in concurrency (especially wrt multiple goals)

Sensor fusion when needed does not delay individual sensor-based control

Robust lower layers run while upper layers are debugged

Layers may use independent resources, permitting flexible growth

Today


Prioritizing Multiple Behaviors

While all processes can be active at once, checking their conditions to determine whether or not they should do something, only one process can have control of the robot’s outputs at at given time

Which process gets priority over the others?

Fixed priority system: each process is assigned a priority level; at any given time, the process with highest priority gets control of the robot

Arrows indicate a path of priority among three processes. Touch has the highest priority, followed by Turn and then Wander. Why does this ordering make sense?


Priority-based Control Subsumption is a conceptual design tool not

an implementation solution Need a way to implement subsumption and

similar parallel behavior-based approaches General idea: use OS principles of processes

and priorities to schedule concurrent tasks and arbitrate between competing control tasks

Assign each task a process number & priority level:– Process numbers identify task when issuing motor

commands; allows prioritization routine to identify motor commands of each different task

– Priority level allows tasks with higher priority to supersede tasks with lower priority


Priority-Based Control Program

/* touch sensor process */

void touch (int pid) {while (1) { if (left_touch()) { enable(pid); backward(pid); msleep(500L); right(pid); msleep(500L); disable(pid); } else if (right_touch()) { enable(pid); backward(pid); msleep(500L); left(pid); msleep(500L); disable(pid); } }}

•see priority.c

•pid = process ID (process identifier) argument is used in movement commands to indicate which process is requesting which motor commands

• Pair of commands used to enable and disable a process’s functioning

•Process must disable itself when done so that other processes that have lower priority get a chance to operate

•If not, then process would have control of the robot even if it were not issuing any movement commands (unless a process with higher priority were active)

• Separately (and in parallel), prioritization routine determines which process is enabled and has the highest priority, and then issues movement commands selected by that process to motors (see priority.c)


Setting Up Processes and Priorities

1. Process priority is assigned (zero priority is off; higher numbers are higher priority)

2. Process name is assigned: name is displayed by the prioritization program when the process is made active

3. Process itself is launched, and the process counter variable, pid, is incremented for the next process setup

Last: Launch prioritization program


void main () { int pid= 0; /* touch sensor */ process_priority[pid]= 3; process_name[pid]= "Touch"; start_process(touch(pid++)); /* periodic turn */ process_priority[pid]= 2; process_name[pid]= "Turn"; start_process(periodic_turn(pid++)); /* wander */ process_priority[pid]= 1; process_name[pid]= "Wander"; start_process(wander(pid++)); /* motor arbitration process */ num_processes= pid; start_process(prioritize());}

Prioritization Algorithm: Basic Concept

•Each process has:

•a priority level,

•a pair of output values representing its left and right motor commands,

•an enable/disabled state indicator and

•a process name character string

•The prioritize() process cycles through the list of enabled processes, finds the one with the highest priority, and copies its motor output commands to the actual motors.


Prioritization Algorithm: Data StructuresData Structures:process_name[] process_priority[] holds the fixed priority values as assigned to the processes process_enable[] holds dynamic enable values

– Touch is enabled, since its priority level has been copied into the process_enable[] array. Turn is disabled, and Wander is always enabled

Left_motor[] and right_motor[] hold values assigned by the behavior tasks

– Even though Turn is disabled, its entries are still present in the motor arrays from a previous time. No need to clear them out

Active_process assigned by prioritize(), is zero, indicating that the process with an index 0—the touch sensor process—is active.


Enable/Disable•Enable: copy

process’s priority level, which is stored in process_priority[], into “enabled” array

•Disable: zero stored in process’s position in process_enable[] array

/* set process_enable entry to process’s priority level */void enable (int pid) { process_enable[pid]= process_priority[pid];}/* set process_enable entry to 0 */void disable (int pid) { process_enable[pid]= 0;}


Prioritize

void prioritize () {int max, i;while (1) {/* find process with maximum priority */ max= 0; for (i=0; i< num_processes; i++) if (process_enable[i] > max) max= process_enable[i];/* if no processes enabled, turn off motors */ if (max == 0) { motor(LEFT_MOTOR_PORT, 0); motor(RIGHT_MOTOR_PORT, 0); printf("No tasks enabled\n"); } else {/* get pid of active process *//* if more than one at highest level, get the first one */ for (i=0; i< num_processes; i++) if (process_enable[i] == max) break; active_process= i;/* set the motors based on the commands of this process */ motor(LEFT_MOTOR_PORT, left_motor[active_process]); motor(RIGHT_MOTOR_PORT, right_motor[active_process]);/* display name of active process */ printf("Running %s\n", process_name[active_process]); } } }


Dynamic Priorities

• No reason that a task’s priority level could not be a dynamic quantity which varied depending upon various internal and external factors.

• Consider Groucho:

– Suppose that Groucho had several different strategies for searching for balls, some more conservative and others more aggressive and risky.

– At the start of the round, it would make sense to try the conservative approaches first, but if these failed, to switch to the more aggressive search modes.

– A supervisory task could monitor the Groucho’s performance, and elapsed time, and adjust other tasks’ priority levels as it saw fit.


Lab 4

Bumpers, IR Sensing, and Multiple Behavior Control




Lab 4: Bumpers, IR Sensing, and Multiple Behavior Control

In-class lab overview:– Build front bumper system using at least 2 touch switches – Write function to determine bump on left or right (or both)

and launch as parallel process (make good use of defer)– Write program that backs away from a collision using

open-loop timing movements and then resets motion in direction away from collision using more open-loop timing – show to TA

– Attach IR sensors to robot– Design shields to admit IR in a 90 degree cone to right and

left of front of robot– Write function to determine IR state for obstacle on left or

right or both or neither and launch as a parallel process (don’t forget calibration and thresholding as with the photosensors) – show states on LCD to TA

Next Week Take-home part of Lab

– Replicate from bumper system in rear of robot and extend bumper state program to include new sensors

– Write a program that detects obstacle using IR and tries to move around the obstacle using closed-loop feedback with IR states (similar to ground-tape avoiding program)

– Add extra photo sensor for ambient light filtering to ground sensing if shielding was not sufficient

– Use behavior/priority based control to combine:1. ground sensing, 2. light following, 3. bumper reaction, and 4. IR obstacle avoidance and tracking

– For midterm competition Read on-line documents; answer questions for Week 4 on Plan Help Session Monday Lab 5: Midterm competition, Wheel encoders, and odometry Bring in your full kit – we will be re-organizing teams after the

midterm competition

Lab 4 ProgramsGlobal variables for:

calibration variableslight-state, ground-state, bumper state, IR state

Function to calibrate ground sensor using buttons (done)Function to determine light-state (done)Function to determine ground state (done)Function to move toward light (done)Function to move away from ground obstacle (done)

Function to detect bumper state (in-class/home)Function to react to bumper collision (in-class)Function to calibrate IR sensors (in-class)Function to determine IR state (in-class)Function to avoid and track IR-detected obstacles (at home)

void main(void) {calibratestart processes to keep track of: light, ground, bumper, IR states(with good use of defer)behavior/priority based control program to switch between:

light following, collision reaction, ground reaction, obstacle avoidance – according to priority scheme(at home)

}

References


http://plan.mcs.drexel.edu/courses/robotlab/readings/hbmanual.pdf

http://plan.mcs.drexel.edu/courses/readings







Teams

Team 1: Ed Burger, Christopher J Flynn, Andrea J. Glenbockie

Team 2: Matthew A Curran, Michael R. DeLaurentis, Andrew R. Mroczkowski

Team 3: Max D Peysakhov,Timothy S. Souder, Kang Chen, Chris Cera

Team 4: Daryl L Falco, Omar Hasan, Eric D. Pancoast

Team 5: Donovan Artz, Umesh Kumar, Gregory P Ingelmo

Team 6: Lisa P. Anthony, Brian J. Summers, Edward Whatley

Date post:	05-Jan-2016
Category:	Documents
Upload:	clement-bradley
View:	215 times
Download:	1 times

Robot Building Lab: Multiple Behavior Control DEMO Light-state and ground-state sensing in parallel...

Documents