robot building lab: lab 3 demo show us your working differential drive robot start it running a...

DEMO Show us your working differential drive robot Start it running a fixed pattern that includes

– Forward– Backward– Left– Right– Straight– Curved

Lab 3: Light sensors, light following, reactive control, feedback-based control, algorithmic control, more multi-tasking

Lab 3

Light Sensing, Serial Comms, and Algorithmic Control

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



Today

Light sensorsSerial communicationsOpen-loop vs. closed-loop controlMaintaining sensor statesDealing with errorsAlgorithmic control

SensorsGet information about worldInformation changes over timeSensors may provide of

measurement of the existence of certain features in the world

Examples: light, sound, pressureSensors convert features into

measurable quantities like resistance, current, etc.

Two basic types: analog, digital– Analog: continuously varying

value– Digital: on or off

Light Sensors

Analog sensor -- Change resistance in response to light stimuli

Handy Board’s Analog Inputs

• 0 to 5 volts are converted into 8–bit numbers 0 to 255 (decimal) (A/D conversion)

• Photocell provides a variable resistance, which is balanced against the fixed 47K pull-up resistor

– Two resistors form voltage divider circuit

• Vsens voltage at the center tap of the two resistors is proportional to the ratio of the two resistances.

Rphoto = 47K, Vsens = 2.5 v (exactly)

Rphoto << 47K, Vsens ~= gnd

Rphoto >> 47K, Vsens ~= +5 v

– When the photocell resistance is small

(brightly illuminated), the Vsens ~= 0v

– When the photocell resistance is large

(dark), Vsens ~= +5 v

(copyright Prentice Hall 2001)

Shielding Photocell

Photocell Sensors Mounted on LEGO Technic Beam

Photocell Sensors with Light Shields

• Read photocell values:while (1) { printf("%d\n", analog(0)); msleep(100L); }

• Mounting photocell through Lego beam makes it easier to attach to robot

• Build optical shield to limit the amount of ambient light that is able to fall on the sensor


Use of Light Sensors

Today


Serial Communication Modes

Collect sensor data on Handy Board Upload to PC host, either

1. Batch mode: program stores data on Handy Board and later writes to host using serial line

2. Real-time data collection: program on Handy Board writes data directly to serial line during data collection activities

3. On-line interaction: programs active on both Handy Board and Host communicate with each other over serial line


Serial Line Interaction IC takes over the serial line with low-level protocol Need to disable this interaction to use serial line for anything

else Then, write to the serial line using built-in 6811 serial port

registers– Serial Communications Data Register (SCDR) is located at

address 0x102f • If data is stored to this register, the 6811 transmits it

as serial output; when a serial character is received, it is retrieved by reading from the same register

– Serial Communications Status Register (SCSR) is located at address 0x102e

• Bits in this register indicate when the serial port is busy (e.g., whether it is in the middle of receiving or transmitting a character)

IC library file: serialio.c– Wrapper functions for interacting with serial port


Connecting to a Terminal Program We’ll use terminal emulator on host side for grabbing serial data

from the Handy Board -- Download from software directory Load serialio.c

– disable_pcode serial(): so that HB does not interpret any accidental characters that might be sent from the host computer

– Process: download program to HB using IC; shutdown IC; start terminal emulator; turn off/on HB to start program that communicates with terminal

– To restart HB in normal mode: hold down Start button while turning it on/* serxmit.c */

void main(){ int i; disable_pcode_serial(); while (1) { printf("Press Start button to begin\n"); start_press(); printf("Transmitting...\n"); for (i= 32; i< 128; i++) serial_putchar(i); }}


Sending Integers to Terminal Emulator

IC library file printdec.c (in software directory) provides printdec(), which takes an integer as input and prints its value as a decimal number over the serial line

Example: sensor data is continuously displayed on the host computer screen/* analogpr.c requires printdec.c, serialio.c */void main(){ disable_pcode_serial(); while (1) { printdec(analog(0)); serial_putchar(10); /* line feed */ serial_putchar(13); /* carriage return */ /* wait 0.1 sec between each print */ msleep(100L); }}


Batch Data Capture

• Faster capture rate – not limited by slow serial comms

/* datacoll.c requires printdec.c, serialio.c */int SAMPLES=1000;char data[1000];void main(){ disable_pcode_serial(); printf("press Start to collect data\n"); start_press(); collect_data(); beep(); printf("press Start to dump data\n"); start_press(); dump_data(); beep(); printf("done.\n");}


Collect Data into Array and Dump to Serial Line

void collect_data(){ int i; for (i= 0; i< SAMPLES; i++) { data[i]= analog(0); /* to slow down capture rate, add msleep here */ }}

void dump_data(){ int i; for (i= 0; i< SAMPLES; i++) { printdec(data[i]); serial_putchar(10); /* line feed */ serial_putchar(13); /* carriage return */ }}


Today


Control Paradigms

Open-loop control – execute actions without feedback –

imprecise actuation (friction, gear slippage, battery discharge) and dynamic environments cause problems

Closed-loop control – use sensor feedback to monitor and modify

actions

Open-loop Control

Goal: Drive parallel to wall

No feedback Start exactly parallel

to wall and try to drive straight

Noisy movement = crash into wall, or stray from wall

(Courtesy of Bennet)

Open Loop Turning (90 degrees)

Timed turn:– Robot_backward();

sleep(.5); robot_turn(); sleep(1.5);

Requires very predictable movement to work right– Battery strength– Traction– Gear slippage

Feed-forward – determine some parameters of open-loop control in advance (eg turn time based on battery strength)

Best use of open loop control: when time is critical


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


Today


Review: Simple Processing Using Single Threshold

•Robot ground sensor can be in one of two states:

•State A: Over line

•State B: Over floor

•Compare sensor reading with setpoint value

•If less than this threshold set variable to indicate robot is in State A

•Otherwise, set variable to indicate State B

• What to use as setpoint threshold?

• midpoint between floor value and line value

•E.g. 10 when aimed at the floor, and 50 when aimed at the line choose 30 as setpoint threshold


Review: Two Thresholds for Hysteresis

•Problem with single threshold – variances in sensor readings

• Bump on floor may spike the readings

• Shiny spots on line may reflect as well as the floor, dropping the sensor readings up into the range of the floor

• Solution: two setpoints can be used

– Imposes hysteresis on the interpretation of sensor values, i.e., prior state of system (on/off line) affects system’s movement into a new state

Line Following performance run :Setpoint =20

int LINE_SETPOINT= 35;int FLOOR_SETPOINT= 10;void waituntil_on_the_line() { while (line_sensor() < LINE_SETPOINT);}void waituntil_off_the_line() { while (line_sensor() > FLOOR_SETPOINT);}


Light Sensor States

Using two sensors to keep track of one of four states:– Light-on-Left– Light-on-Right– Light-in-Center– No light

Options:1. Use hysteresis on each sensor individually and

combine values into single state2. Combine sensor readings first and then apply

hysteresis on resulting value Observe values using serial comms Try to maintain “light-in-center” state – make

closed-loop motor changes when in other states

Simple Feedback Control – Wall Following

HandyBug with bend sensor or reflective IR sensor

HandyBug turns towards wall if distance sensor indicates too far away; turns away from wall if too close

Single threshold for “too far” and “too close” = goal variable


Simple Feedback Control – Wall Following

void main() { calibrate(); ix= 0; while (1) { int wall= analog(LEFT_WALL); printf("goal is %d; wall is %d\n", goal, wall); if (wall < goal) left(); /* too far from wall -- turn in */ else right(); /* turn away from wall */ data[ix++]= wall; /* take data sample */ msleep(100L); /* 10 iterations per second */ }}


Hard Turns Control

Results with bend sensor:

• HandyBug oscillates around setpoint goal value

• Never goes straight


void left() {motor(RIGHT_MOTOR, 100);motor(LEFT_MOTOR, 0);}

void right() {motor(LEFT_MOTOR, 100);motor(RIGHT_MOTOR, 0);}

Hard turns

Soft Turns Control

• Gentle Turning Algorithm:

• Swings less abrupt

• HandyBug completes run in 16 sec (vs. 19 sec in hard turn version) for same length course

• In light following we want to include a go-straight function and a random-movement-to-find-light function as well

void left() {motor(RIGHT_MOTOR, 100);motor(LEFT_MOTOR, 50);}

void right() {motor(LEFT_MOTOR, 100);motor(RIGHT_MOTOR, 50);}


Separate Sensor State Processing from Control

Functions might each make use of other sensors and functions – need to decide how to implement each


Control Paradigms

Open-loop control – execute actions without feedback – imprecise

actuation (friction, gear slippage, battery discharge) and dynamic environments cause problems

Closed-loop control – use sensor feedback to monitor and modify actions

Previous example: main loop determined control action based on feedback and executed control action for fixed time determined by sleep duration– Overall control was closed-loop due to feedback –

closeness to wall– With open-loop actions due to sleep during left or

right turns

Does Wall-Following Program Do The Right Thing?

Depends how frequently the states can be updated

And how much movement adjustment is made when states change

And speed of robotAnd potential sensor errorsAnd the calibration of the thresholdsWarning: if program relies too much on

parameter tuning it won’t be very useful

Today


Improving Wall Following Program

Using additional sensors to test for Error conditions in addition to normal states

Use timeouts to test for failure

Testing for Error Conditions

Use touch sensor to test if robot is stuck


Use Timeout to Test For Failures

Test for maximum time to perform task


Today


States, Modes, and Algorithmic Control

In this case we are talking about “control” at the level of higher-level behaviors like wall-following or light-following

Use combinations of sensor values to figure out the “state” of the robot– Or detect important events– Or error states

Each state or sequence of states triggers a “mode” of operation for the robot– Short term responses to events (e.g. collision)– Long-term change of behavior/goal (e.g. light

following/avoiding) In Algorithmic Control, modes switches are explicitly

determined by programmer– All possible “states” and events must be considered– Current mode determines robot output/motor commands

Four Basic Approaches to Robot Control

1. Deliberative Control: Think hard, then act.

2. Reactive Control: Don’t think, (re)act.

3. Hybrid Control: Think and act independently, in parallel.

4. Behavior-Based Control: Think the way you act.


Distinguishing Characteristics

1. Deliberative systems look into the future (plan) before deciding how to act.

2. Reactive systems respond to the immediate requirements of the environment, and do not look into the past or the future.

3. Hybrid systems respond to some of the urgent requirements, while taking time to think about some others. This requires waiting for the thinking to finish, or interrupting the reaction based on new information.

4. Behavior-based systems also think and act at the same time, but spread out the thinking over multiple distributed computation modules (behaviors). Thus they think the way they act, as quickly as possible.


Trade-offs

Thinking is slow Reaction must be fast Thinking allows looking ahead (planning) to avoid bad

actions Thinking too long can be dangerous (e.g., falling off a

cliff, being run over) To think, the robot needs (a lot of) accurate information The world keeps changing as the robot is thinking, so the

slower it thinks, the more inaccurate its solutions Task and environment considerations:

– move and react very quickly -- usually no time for thinking, such as in automated fast-moving cars, or in soccer playing robots

– does not change much -- plan far ahead to find the best action, such as in playing chess, monitoring a warehouse at night, or assembling a complicated object


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

Example Algorithmic Control Program: Groucho


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

Groucho’s Algorithmic Control Program

void groucho() {while (1) { /* loop indefinitely *//* for simplicity, assume robot starts at position 1 */ forward(); waituntil_hit_wall(); rotate_left_ninety(); /* now at position 2 */ forward(); waituntil_see_black(); /* position 3 */ rotate_left_ninety(); /* position 4 */ forward(); waituntil_hit_wall(); /* position 5 */ rotate_left_ninety(); /* position 6 */ rotate_onehundred_eighty(); /* position 7 */ forward(); waituntil_hit_wall(); /* position 8 */ rotate_left_ninety(); /* position 9 */}}


Use of Feedback within Algorithmic Control Program

Turn from position 1 to position 2 made little movements and bump sensing to get around corner

Turn from position 3 to position 4 used open-loop timing

Moving along center platform used ground sensing to keep one side of robot on dark floor and one side on light floor – compensating for noise in gear train

Touch sensors to trigger reaching wall and switching modes


Strengths and Weaknesses of Algorithmic Control

Strengths: simplicity, directness, and predictability when things go according to plan

Weaknesses: inability to detect or correct for problems or unexpected circumstances, and the chained-dependencies required for proper functioning– If any one step fails, the whole solution typically fails. Each link-step of

an algorithmic solution has a chance of failing, and this chance multiplies throughout the set of steps, e.g., suppose each step has a 90% chance of functioning properly on any given trial, and there are six such steps in the solution. Then the likelihood of overall program working is the likelihood that each steps functions properly: ~53% chance

– Closed-loop feedback in certain modes helped alleviate problems within modes

• By embedding feedback controls within the algorithmic framework, the reliability of the algorithmic approach is greatly improved.


Dealing with Problem Situations

What happens if touch sensor to trigger next phase never occurs?– Groucho would just sit there

What happens if opponent triggers touch sensor before wall is reached?– Groucho would think that wall was reached

Think about: techniques for error detection and recovery within an algorithmic framework.– One simple method from earlier: timeout or

premature exit– With return code to allow master routine to do

something different in those cases


Lab 3

Light Sensing, Serial Comms, and Algorithmic Control




Lab 3: Light Sensing, Serial Comms, and Algorithmic

Control In-class lab overview:

– Attach a light sensor to robot– Design a shield to admit light in a 90 degree cone – demo

shield showing light values– Download serial communications libraries to IC libs– Download terminal program to X:\ and install– Mount two light sensors on front of robot so that their

fields of view overlap slightly– Write program to read data from both sensors, put in

array, and dump array to serial port– Run program with terminal program listening on serial port

and grab data for graphing using Excel – mail graphs from 3 experiments to TA after class

– Write program to use light sensors to determine one of 4 states: light-to-left, light-in-center, light-to-right, no light; use data from prior experiment to determine best way to do this – demo program to instructor

Lab 3 ProgramsGlobal variables for:

ground calibration light-stateground-state

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

void main(void) {calibrate ground sensorstart process to keep track of ground statestart process to keep track of light state

sequence of commands to move between light following and obstacle avoiding based on two state variables (at home)

}

Next Week Take-home part of Lab

– Implement in-class light-state program as a task– Add task for sensing ground state– Write program that runs light-state and ground-state

sensing in parallel and uses results in an algorithmic-control program that heads towards light but avoids any taped obstacles it encounters along the way

– Think about better ways to write this program but don’t worry about reactivity or parallelism in the control part of the program

Read on-line documents and answer questions specified at http://plan.mcs.drexel.edu/robotlab/questions/week3_final.htm

Help Session Monday Lab 4: Bump sensors, IR sensors, behavior-based control

http://plan.mcs.drexel.edu/robotlab/questions/week3_final.htm

http://plan.mcs.drexel.edu/robotlab/questions/week3_final.htm

References


http://plan.mcs.drexel.edu/projects/legorobots/handyboard.html

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

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







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

robot building lab: lab 3 demo show us your working differential drive robot start it running a...

Documents