Using Lego Mindstorms NXT in the Classroom Gabriel

Using Lego Mindstorms NXT in the Classroom Gabriel J. Ferrer Hendrix College ferrer@hendrix. edu http: //ozark. hendrix. edu/~ferrer/

Outline • • NXT capabilities Software development options Introductory programming projects Advanced programming projects

Purchasing NXT Kits • Two options (same price; $250/kit) – Standard commercial kit – Lego Education kit • http: //www. lego. com/eng/education/mindstorms/ • Advantages of education kit – Includes rechargeable battery ($50 value) – Plastic box superior to cardboard – Extra touch sensor (2 total) • Standard commercial kit – Includes NXT-G visual language

NXT Brick Features • • • 64 K RAM, 256 K Flash 32 -bit ARM 7 microcontroller 100 x 64 pixel LCD graphical display Sound channel with 8 -bit resolution Bluetooth radio Stores multiple programs – Programs selectable using buttons

Sensors and Motors • Four sensor ports – Sonar – Sound – Light – Touch • Three motor ports – Each motor includes rotation counter

Touch Sensors • Education kit includes two sensors • Much more robust than old RCX touch sensors

Light Sensor • Reports light intensity as percentage • Two modes – Active – Passive • Practical uses – Identify intensity on paper – Identify lit objects in dark room – Detect shadows

Sound Sensor • Analogous to light sensor – Reports intensity – Reputed to identify tones • I haven’t experimented with this • Practical uses – “Clap” to signal robot

Ultrasonic (Sonar) Sensor • Reports distances – Range: about 5 cm to 250 cm – In practice: • Longer distances result in more missed “pings” • Mostly reliable – Occasionally gets “stuck” – Moving to a new location helps in receiving a sonar “ping”

Motors • Configured in terms of percentage of available power • Built-in rotation sensors – 360 counts/rotation

Software development options • Onboard programs – Robot. C – le. JOS – NXC/NBC • Remote control – i. Command – NXT_Python

Robot. C • Commercially supported – http: //www. robotc. net/ • • • Not entirely free of bugs Poor static type checking Nice IDE Custom firmware Costly – $50 single license – $250/12 classroom computers

Example Robot. C Program void forward() { motor[motor. A] = 100; motor[motor. B] = 100; } void spin() { motor[motor. A] = 100; motor[motor. B] = -100; }

Example Robot. C Program task main() { Sensor. Type[S 4] = sensor. SONAR; forward(); while(true) { if (Sensor. Value[S 4] < 25) spin(); else forward(); } }

le. JOS • Implementation of JVM for NXT • Reasonably functional – Threads – Some data structures – Garbage collection added (January 2008) – Eclipse plug-in just released (March 2008) • Custom firmware • Freely available – http: //lejos. sourceforge. net/

Example le. JOS Program sonar = new Ultrasonic. Sensor(Sensor. Port. S 4); Motor. A. forward(); Motor. B. forward(); while (true) { if (sonar. get. Distance() < 25) { Motor. A. forward(); Motor. B. backward(); } else { Motor. A. forward(); Motor. B. forward(); } }

Event-driven Control in le. JOS • The Behavior interface – boolean take. Control() – void action() – void suppress() • Arbitrator class – Constructor gets an array of Behavior objects • take. Control() checked for highest index first – start() method begins event loop

Event-driven example class Go implements Behavior { private Ultrasonic sonar = new Ultrasonic(Sensor. Port. S 4); public boolean take. Control() { return sonar. get. Distance() > 25; }

Event-driven example public void action() { Motor. A. forward(); Motor. B. forward(); } public void suppress() { Motor. A. stop(); Motor. B. stop(); } }

Event-driven example class Spin implements Behavior { private Ultrasonic sonar = new Ultrasonic(Sensor. Port. S 4); public boolean take. Control() { return sonar. get. Distance() <= 25; }

Event-driven example public void action() { Motor. A. forward(); Motor. B. backward(); } public void suppress() { Motor. A. stop(); Motor. B. stop(); } }

Event-driven example public class Find. Freespace { public static void main(String[] a) { Behavior[] b = new Behavior[] {new Go(), new Stop()}; Arbitrator arb = new Arbitrator(b); arb. start(); } }

NXC/NBC • NBC (NXT Byte Codes) – Assembly-like language with libraries – http: //bricxcc. sourceforge. net/nbc/ • NXC (Not e. Xactly C) – Built upon NBC – Successor to NQC project for RCX • Compatible with standard firmware – http: //mindstorms. lego. com/Support/Updates/

i. Command • Java program runs on host computer • Controls NXT via Bluetooth • Same API as le. JOS – Originally developed as an interim project while le. JOS NXT was under development – http: //lejos. sourceforge. net/ • Big problems with latency – Each Bluetooth transmission: 30 ms – Sonar alone requires three transmissions – Decent program: 1 -2 Hz

NXT_Python • Remote control via Python – http: //home. comcast. net/~dplau/nxt_python/ • Similar pros/cons with i. Command

Developing a Remote Control API • Bluetooth library for Java – http: //code. google. com/p/bluecove/ • Opening a Bluetooth connection – Typical address: 00: 16: 53: 02: e 5: 75 • Bluetooth URL – btspp: //00165302 e 575: 1; authenticate=false; encrypt=false

Opening the Connection import javax. microedition. io. *; import java. io. *; Stream. Connection con = (Stream. Connection) Connector. open(“btspp: …”); Input. Stream is = con. open. Input. Stream(); Output. Stream os = con. open. Output. Stream();

NXT Protocol • Key files to read from i. Command: – NXTCommand. java – NXTProtocol. java

An Interesting Possibility • Programmable cell phones with cameras are available • Camera-equipped cell phone could provide computer vision for the NXT

Introductory programming projects • Developed for a zero-prerequisite course • Most students are not CS majors • 4 hours per week – 2 meeting times – 2 hours each • Not much work outside of class – Lab reports – Essays

First Project (1) • Introduce motors – Drive with both motors forward for a fixed time – Drive with one motor to turn – Drive with opposing motors to spin • Introduce subroutines – Low-level motor commands get tiresome • Simple tasks – Program a path (using time delays) to drive through the doorway

First Project (2) • Introduce the touch sensor – if statements • Must touch the sensor at exactly the right time – while loops • Sensor is constantly monitored • Interesting problem – Students try to put code in the loop body • e. g. set the motor power on each iteration – Causes confusion rather than harm

First Project (3) • Combine infinite loops with conditionals • Enables programming of alternating behaviors – Front touch sensor hit => go backward – Back touch sensor hit => go forward

Second Project (1) • Physics of rotational motion • Introduction of the rotation sensors – Built into the motors • Balance wheel power – If left counts < right counts • Increase left wheel power • Race through obstacle course

Second Project (2) if (/* Write a condition to put here */) { nxt. Display. Text. Line(2, "Drifting left"); } else if (/* Write a condition to put here */) { nxt. Display. Text. Line(2, "Drifting right"); } else { nxt. Display. Text. Line(2, "Not drifting"); }

Third Project • Pen-drawer – First project with an effector – Builds upon lessons from previous projects • Limitations of rotation sensors – Slippage problematic – Most helpful with a limit switch • Shapes (Square, Circle) • Word (“LEGO”) – Arguably excessive

Pen-Drawer Robot

Pen-Drawer Robot

Fourth Project (1) • Finding objects • Light sensor – Find a line • Sonar sensor – Find an object – Find freespace

Fourth Project (2) • Begin with following a line edge – Robot follows a circular track – Always turns right when track lost – Traversal is one-way • Alternative strategy – Robot scans both directions when track lost – Each pair of scans increases in size

Fourth Project (3) • Once scanning works, replace light sensor reading with sonar reading • Scan when distance is short – Finds freespace • Scan when distance is long – Follow a moving object

Light Sensor/Sonar Robot

Other Projects • “Theseus” – Store path (from line following) in an array – Backtrack when array fills • Robotic forklift – Finds, retrieves, delivers an object • Perimeter security robot – Implemented using RCX – 2 light sensors, 2 touch sensors • Wall-following robot – Build a rotating mount for the sonar

Robot Forklift

Gearing the motors

Advanced programming projects • From a 300 -level AI course • Fuzzy logic • Reinforcement learning

Fuzzy Logic • Implement a fuzzy expert system for the robot to perform a task • Students given code for using fuzzy logic to balance wheel encoder counts • Students write fuzzy experts that: – Avoid an obstacle while wandering – Maintain a fixed distance from an object

Fuzzy Rules for Balancing Rotation Counts • Inference rules: – bias. Right => left. Slow – bias. Left => right. Slow – bias. None => left. Fast – bias. None => right. Fast • Inference is trivial for this case – Fuzzy membership/defuzzification is more interesting

Fuzzy Membership Functions • Disparity = left. Count - right. Count • bias. Left is – 1. 0 up to -100 – Decreases linearly down to 0. 0 at 0 • bias. Right is the reverse • bias. None is – 0. 0 up to -50 – 1. 0 at 0 – falls to 0. 0 at 50

Defuzzification • Use representative values: – Slow = 0 – Fast = 100 • Left wheel: – (left. Slow * rep. Slow + left. Fast * rep. Fast) / (left. Slow + left. Fast) • Right wheel is symmetric • Defuzzified values are motor power levels

Q-Learning • Discrete sets of states and actions – States form an N-dimensional array • Unfolded into one dimension in practice – Individual actions selected on each time step • Q-values – 2 D array (indexed by state and action) – Expected rewards for performing actions

Q-Learning Main Loop • Select action • Change motor speeds • Inspect sensor values – Calculate updated state – Calculate reward • Update Q values • Set “old state” to be the updated state

Calculating the State (Motors) • For each motor: – 100% power – 93. 75% power – 87. 5% power • Six motor states

Calculating the State (Sensors) • No disparity: STRAIGHT • Left/Right disparity – 1 -5: LEFT_1, RIGHT_1 – 6 -12: LEFT_2, RIGHT_2 – 13+: LEFT_3, RIGHT_3 • Seven total sensor states • 63 states overall

Action Set for Balancing Rotation Counts • MAINTAIN – Both motors unchanged • UP_LEFT, UP_RIGHT – Accelerate motor by one motor state • DOWN_LEFT, DOWN_RIGHT – Decelerate motor by one motor state • Five total actions

Action Selection • Determine whether action is random – Determined with probability epsilon • If random: – Select uniformly from action set • If not: – Visit each array entry for the current state – Select action with maximum Q-value from current state

Q-Learning Main Loop • Select action • Change motor speeds • Inspect sensor values – Calculate updated state – Calculate reward • Update Q values • Set “old state” to be the updated state

Calculating Reward • No disparity => highest value • Reward decreases with increasing disparity

Updating Q-values Q[old. State][action] = Q[old. State][action] + learning. Rate * (reward + discount * max. Q(current. State) Q[old. State][action])

Student Exercises • Assess performance of wheel-balancer • Experiment with different constants – Learning rate – Discount – Epsilon • Alternative reward function – Based on change in disparity

Learning to Avoid Obstacles • Robot equipped with sonar and touch sensor • Hitting the touch sensor is penalized • Most successful formulation: – Reward increases with speed – Big penalty for touch sensor

Other classroom possibilities • Operating systems – Inspect, document, and modify firmware • Programming languages – Develop interpreters/compilers – NBC an excellent target language • Supplementary labs for CS 1/CS 2

Thanks for attending! • Slides available on-line: – http: //ozark. hendrix. edu/~ferrer/presentations/ • Currently writing lab textbook – Introductory and advanced exercises • ferrer@hendrix. edu