Video from today’s lecture: Humans Need Not Apply

This is the sobering video we watched in today’s RoboSumo lecture:

Posted in Uncategorized | Leave a comment

Getting started with the TCRT5000 IR sensor and a switch input

MSP430 Switch Input

The information below explains how to connect a switch input to your MSP430, which you might use to let your robot detect when it has touched the wall in the Race to the Wall.

screenshot_2017-02-15_14-01-44

Download PDF of the switch input example shown above.

TCRT5000 Infrared Reflective Sensor

The TCRT5000 shown below is an infrared (IR) reflective colour sensor that was included in the kit you received at the beginning of the RoboSumo project (TCRT5000 datasheet). It contains an IR LED and phototransistor in a single package. There are all sorts of useful things you can do with this extremely inexpensive sensor, but right now you’re main priority is probably to use it to detect the black finish line in the Race to the Wall.

20170215_135439

The information below introduces the TCRT5000 IR sensor and explains how to connect it to a digital input pin on the MSP430.

screenshot_2017-02-15_14-01-24

Download PDF of the TCRT5000 example shown above.

Posted in Uncategorized | Leave a comment

Images from today’s lecture

20170208_135700

20170208_135725

20170208_135736

20170208_135751

20170208_135801

20170208_135807

20170208_135813

20170208_135822

20170208_135841

Posted in Uncategorized | Leave a comment

Welcome to RoboSumo – Semester 2, 2016-2017

Welcome to the RoboSumo project, which is undertaken by students of programme DT066 (Engineering common first year) and programme DT009 in the Dublin Institute of Technology. Over the course of this semester, you will work in teams of (usually) three to design and build a robot that will compete in a RoboSumo tournament. The tournament consists of a series of bouts in which two robots at a time compete to push each other off a table (the arena). The tournament rules (together with a small number of additional local rules) impose constraints on the cost, weight, physical dimensions and various other elements of the robot design. It is up to each team to improvise within the specified constraints to produce the most competitive robot they can.

Provisional Schedule

There are 13 teaching weeks in the semester (excluding Easter). The provisional schedule for the RoboSumo project is shown below. This schedule is subject to modification and is provided here as a general guide to help you plan your work.

  • Week 1 (this week): Form teams, create blogs, begin LED Flash Challenge.
  • Week 2 (next week): Complete LED Flash Challenge, begin robot design and build.
  • Weeks 3-5: Robot design and build.
  • Weeks 6-7: Race to the Wall competition.
  • Weeks 8-11: Robot design and build.
  • Weeks 12: Final robot review and testing with your tutor.
  • Week 13: RoboSumo tournament.

Some things to be aware of

  • We are here to help you to learn and to manage your project effectively as a team. We will do our best to facilitate your work, but…
  • We are not here to tell you what to do every step of the way. You are expected to carry out independent research to figure out what you need to do to complete this project. We want to help you but we need you to be independent.
  • There is a limit to what we can provide in terms of materials and tools. Depending on your design, you may need to source materials or access to tools independently.
  • You will need some of your own tools – e.g. snips, pliers.
  • You and your teammates will need to look after your own robot, materials and components (including the RoboSumo kit) throughout the project. This applies as of today!
  • You need to supply your own batteries.
  • Please do not take apart the yellow motors we give you.
  • Please do not remove the backing sheet from the mini breadboard we give you (unless you’re absolutely certain that you want to stick it to something permanently).

What to do today (Wednesday 25-1-2017)

In today’s lecture (2-3pm in room KE3-008, which is the large lecture theatre on the third floor of the main building in Kevin St), I will describe the project objectives, review the provisional schedule and explain how the assessment works.

In today’s lab (3-6pm in various labs on the ground floor of the main building in Kevin St), you have five jobs to do. The first four are very short; the fifth is more challenging.

  1. Meet your tutor – this is the lecturer who will supervise your lab group and assist you in completing the project.
  2. Form teams of 3 – your tutor will assign each team a number (see number range for each group below) and give you a RoboSumo kit. It is your responsibility to look after the kit throughout the project.
  3. Choose a team name. You can choose whatever name you want as long as it’s not offensive or impractical (e.g. too long). Please keep in mind that the team name will be publicly visible on the Internet.
  4. Set up your individual WordPress.com blog – you will use this to document your work on the project. NB One blog per student (not per team) and provide the link to your tutor.
  5. Complete (or at least make significant progress on) the LED Flash Challenge. See the previous post on this blog for details.

Each team must have a unique name and team number. Your tutor will assign your team a number from the range allocated to your group, as shown below:

  • DT066 groups A1 and A2: team numbers 1-12 (Ted & Jane in KEG-036)
  • DT066 group B1: team numbers 13-18 (Brian in KEG-004)
  • DT066 group B2: team numbers 19-24 (Richard in KEG-014)
  • DT066 group F1: team numbers 25-30 (Paul in KEG-012)
  • DT066 group F2: team numbers 31-36 (Shivananda in KEG-014)
  • DT009 group: team numbers 37-42 (John in KEG-036)

Note: Tutors, please make a list of teams in your group that includes team name, number and members!

Your RoboSumo kit should include the following items:

  1. 1 x mini breadboard
  2. 1 x MSP430 LaunchPad
  3. 1 x mini USB cable
  4. 1 x MSP430G2452 microcontroller (or MSP430G2553)
  5. 1 x 4AA battery holder with built-in switch
  6. 2 x yellow geared DC motor
  7. 1 x SN754410NE driver chip
  8. 1 x LM1117 3.3V voltage regulator
  9. 4 x TCRT5000 infrared reflective sensor
  10. 1 x microswitch
  11. 1 x 1000uF electrolytic capacitor
  12. 4 x green LED
  13. 4 x red LED
  14. 8 x 220 Ohm resistor
  15. 4 x 10 kOhm resistor
  16. 2 x 100 kOhm resistor

To set up your blog,

  • Go to wordpress.com.
  • Click on the “Start a blog” button.
  • Step 1 of 5: Select “A list of my latest posts”.
  • Step 2 of 5: Select “Twenty Sixteen”.
  • Step 3 of 5: Choose a domain for your blog ending in “.wordpress.com”. For example, “joebloggsroboslam.wordpress.com”. You will be creating a free account, so you can ignore the other options – they are not available without upgrading to a paid account. A free account provides all the features you require for this project.
  • Step 4 of 5: Click on “Select Free” to set up a free account.
  • Step 5 of 5: Enter your email address and choose a password. Leave the username the same as your chosen domain name. Carefully note your username and password so that you don’t forget them. WordPress.com is a private company, so if you lose your details it’s between you and them (rather than DIT) to find out what they are.
  • Finally, click “Create My Account”.
  • Give the domain name (i.e. the web address of your blog) to your tutor along with your name.

Once everyone on your team has set up their blog, it’s time to proceed to the LED Flash Challenge.

Posted in Uncategorized | Leave a comment

LED Flash Challenge – Semester 2, 2016/2017

We’re beginning the RoboSumo project with a little competitive puzzle called the LED Flash Challenge. We’re not attaching formal assessment weight to this challenge, but we’ll be keeping a close eye on which teams do well. In this challenge, doing well means two things: getting it working quickly and trying to understand what you’re doing.

It’s a race.

In today’s lab (and for some of you part of the next lab) you’ll be working with your team to complete two tasks:

  1. Build a simple breadboard circuit for the MSP430 microcontroller and program it to blink an LED on and off.
  2. Add a second LED to the circuit and reprogram the MSP430 to transmit a specific binary sequence as a series of flashes from the two LEDs.

The first task is very prescriptive, which means that we’ll basically tell you exactly what to do, but to complete the second task you’ll need to think for yourselves.

You’ll need a team number to complete this challenge. Your tutor will assign your team a unique number within the range shown below:

  • Teams 1-12: DT066 groups A1 and A2 with Ted Burke & Jane Charles in room KEG-036
  • Teams 13-18: DT066 group B1 with Brian Cogan in room KEG-004
  • Teams 19-24: DT066 group B2 with Shivananda Pukrem in room KEG-014
  • Teams 25-30: DT066 group F1 with Paul Leamy in room KEG-012
  • Teams 31-36: DT066 group F2 with Richard Hayes in room KEG-014
  • Teams 37-42: DT009 group with John McGrory in room KEG-036

Part 1: Blinking LED

This task is relatively straightforward and shouldn’t take you too long to get working. Follow the instructions at the link below and then come back to here once your LED is blinking.

Instructions for Blinking LED example

Once your LED is blinking, there are four things you need to understand before moving on:

  1. How one of the pins (P1.0) was turned into a digital output.
  2. How the LED is turned on.
  3. How the LED is turned off.
  4. How to delay the program for a specified number of microseconds, so that the rate of the LED blinking can be controlled.

Once you understand these four things, you have finished this part of the task (the easy part) and it’s time to move on to the LED Flash Challenge.

Part 2: LED Flash Challenge

In this part, you’re going to modify your circuit to create a simple optical transmitter, which transmits a digital message (a sequence of 1s and 0s) as a series of LED flashes. I’ll demonstrate this to you in the lecture.

The message that you’ll transmit will be 2 bytes long (a byte is 8 bits, or 8 ones and zeros) and it will contain your team number (byte 1) followed by a second number calculated by subtracting your team number from 255 (byte 2).

For example, if your team number is 79…

  • byte1 = 79
  • byte2 = 255 – 79 = 176
  • byte1 + byte2 = 255
You and your teammates should take a few
minutes to read about binary numbers and
digital i/o on the MSP430 here.

Specifically, you need to do the following:

  1. Modify the code to create a second digital output pin.
  2. Extend the circuit by adding a second LED (with current limiting resistor) to that digital output pin.
  3. Convert your team number into 8-bit binary. This is byte 1 of your message.
  4. Calculate the required value of byte 2 (so that byte1+byte2 = 255).
  5. Each byte will be transmitted as a sequence of ones and zeros, preceded by a start bit (1) and followed by a stop bit (0). That means your complete transmission will be 20 bits long. You need to calculate this sequence on paper first.
  6. To transmit a 1, turn LED1 off and LED2 on for 500ms.
  7. To transmit a 0, turn LED2 off and LED1 on for 500ms.
  8. To ensure the sequence is read correctly, transmit a long sequence of zeros (for about 5 seconds) before you transmit your message.

Let’s consider that example team number 79 again. As explained above, byte 1 is 79 and byte 2 is 176.

  • Before transmitting the sequence, send a “0” for about 5 seconds.
  • The first bit of the sequence is the start bit for byte 1 which is “1”.
  • Written as a binary number, 79 (seventy-nine) is 0b01001111. The “0b” prefix indicates that it is a binary number and is not part of the number value. The byte is transmitted least significant bit first, i.e. in the following order: “1,1,1,1,0,0,1,0”.
  • The next bit is the stop bit for byte 1, which is “0”.
  • The next bit is the start bit for byte 2, which is “1”.
  • Written as a binary number, 176 is 0b10110000, so the next 8 bits are “0,0,0,0,1,1,0,1”.
  • The final bit is the stop bit for byte 2, which is “0”.

To summarise, the complete 20-bit sequence for team 79 would be as follows:

led_flash_challenge_example

The validator for checking your transmission is a web application which I have posted at the following location:

I will set up an official validation station in KEG-036 where you can record your result once your circuit is working. Other tutors may set up validation stations in the other rooms, but that will depend on available cameras and light levels.

You are welcome to try the validator on your own laptop / PC. In principle, it should work on any modern PC with a webcam and up-to-date browser. However, since video capture is relatively new in HTML, I recommend using the current release of Google Chrome which is what I tested it in.

Your tutor will be able to clarify anything you don’t understand about this.

Posted in Uncategorized | Leave a comment

RoboSumo Tournament semester 1 2016-2017 – 2pm Wed 7/12/2016

This semester’s RoboSumo
tournament takes place
at 2pm today, Wed 7th Dec 2016
in room KEG-036, DIT Kevin St

Click here for Live Tournament ranking

Please review the following information carefully from start to finish.

Tournament time and location

The tournament will commence at 2pm on Wednesday 7th December 2016 in room KEG-036, which is located in one of the smaller side corridors on the ground floor of the main building in DIT Kevin St. During the initial “sorting” phase of the tournament, two competition arenas (sumo tables) will operate in parallel in the same room.

The exact duration of the tournament will depend on how quickly things progress, but we aim to be completely finished by 5pm. To ensure that the tournament proceeds efficiently, teams must comply with the instructions of the referee(s) without dispute at all times.

Robot Weigh-in – 2:00pm in KEG-036

Before your robot can compete in any sumo bouts, it must weigh-in to ensure compliance with the competition rules.

  • The weight limit is 500 grams, as measured using the electronic scales in room KEG-036. This includes every part of the competing robot, including batteries.
  • The size limit is 10cm x 10cm when viewed from above (no part of the robot is allowed to be outside this boundary).

Teams should present their robots for the weigh-in at 2pm in room KEG-036. Jane Courtney is managing the weigh-in and will run through a checklist with each team. She will also provide Q6a feedback forms for you to complete and return with your robot after the tournament.

Sumo Bouts – 2:30pm in KEG-036

From 2:30pm onwards, teams must be continuously present in room KEG-036 and ready to compete immediately whenever summoned to one of the arenas. If a team is not ready when they are called to compete in a bout, their opponent will be granted a walkover in that bout. However, that team remains eligible to compete in subsequent bouts (until they are eliminated from the tournament).

Robot Collection – KEG-036

Once your team is eliminated from the competition (or has won!), you need to submit your final robot for assessment. This is critically important for your final grade. Jane Courtney will be managing the submission of robots and will run through the following checklist with each team:

  1. Is your robot clearly labelled with the team name, each of your names and your tutor’s name? Jane will provide an adhesive label.
  2. Have you returned your Launchpad?
  3. Have you returned your completed Q6a feedback forms?
  4. Have you provided your blog address for every team member?

Please do not leave without submitting your robot. Doing so may have a catastrophic effect on your grade.

DIT tournament rules

The RoboSumo tournament rules are those of the Robot Challenge “Mini” class, mostly as described in the Robot Challenge rules PDF document. However, those rules make provision for tournament organisers to introduce local rule changes as appropriate.

The following rule variations apply in the DIT RoboSumo tournament:

  1. No infrared starting devices are used. Instead, teams position and start their robots manually at the beginning of each bout, as instructed by the referee. Following manual starting, each robot should remain still for at least 2 seconds. (In most cases, this will simply require the inclusion of a 2-second delay in the robot’s microcontroller program.) Robots which do not observe the 2 second delay at the start may still be allowed to compete at the discretion of the referee, but may be penalised by being placed in a disadvantageous starting position.
  2. The duration of each bout is limited to 60 seconds. At the discretion of the referee(s), the bout duration may be reduced further to speed the progress of the tournament. (Note: In the past, we have sometimes reduced the bout duration to 30 seconds to speed things up.)
  3. If both robots remain in the arena when the time limit for the bout expires, the referee will decide the winner based on each robot’s distance from the centre of the table (the closer the better), robot activity/behaviour during the bout, attitude/behaviour of each team during the bout, and/or other criteria at his/her own discretion. The referee may explain the criteria upon which the winner of a bout was chosen, but is not required to do so.
  4. When a bout fails to produce a clear winner, the referee may, at his/her own discretion, order the bout to be replayed.
  5. During most phases of the competition, matches will consist of a single bout. However, in the latter (knockout) stages of the competition the number of bouts in each match may be increased (e.g. best of 3 or best of 5).
  6. The dimensions of each arena will be similar to those described in the Robot Challenge rules (77cm diameter with a 2.5cm white border), but may deviate slightly from them. However, the white border will not be less than 2.5cm in width.
  7. A robot which displays no responsiveness to its opponent or its surroundings for a significant period of time may, at the referee’s discretion, be disqualified from a bout. In particular, please note that robots which simply spin on the spot will be viewed very unfavourably by the referees unless they exhibit other behaviour which provides evidence that the spinning forms part of a meaningful control strategy.
  8. Each team’s robot spending limit is €70. This figure must include the cost of all components included in the final robot, as it is presented for the tournament validation process, with the following specific exceptions. The €70 budget does not include the cost of components or materials purchased but not used in the final robot. It does not include any cost incurred for postage and packing. Most recycled materials which are obtained free of charge do not need to be accounted for in the robot budget, but specialised components which would not be available to other teams through normal scavenging (e.g. remote control servos) may need to be represented by an indicative cost. The referees do not in general systematically verify the cost of every robot, but where a specific dispute arises or it is suspected that a robot may be in breach of this rule, a team may be asked to provide evidence of their total spending (e.g. by providing receipts or showing where each component used can be purchased for the claimed price). Where a team is suspected to be in breach of this rule and cannot prove otherwise, the referees may apply a penalty of some kind or even disqualify a robot from the tournament.

Important note: Every effort has been made to compose the rules of each bout and the structure of the tournament as a whole in a way that is fair and consistent, but since it is impossible to anticipate every eventuality, the referee(s) must have ultimate discretion to overrule any regulation or introduce a rule change at any time.

Tournament structure

The tournament is divided into two main phases – a sorting phase and a knockout phase. Each team must also complete a validation process prior to competing in their first match.

Validation process

The validation process ensures that each robot complies with the restrictions on size and mass imposed by the Mini class rules. Teams who do not successfully complete the validation process are not eligible to compete in the RoboSumo tournament. Teams who are unable to field a compliant robot may still be asked to compete in one or more exhibition bouts for assessment purposes, but they cannot progress in the tournament.

  • The mass of the robot, including batteries and all parts which will be attached to the robot during a bout, must not exceed 500 grams.
  • The footprint of the robot must not exceed 10cm by 10cm. Specifically, the entire robot and all parts attached to it, must fit within a cuboid (with vertical sides) of 10cm width and 10cm depth. Height is not specifically restricted. Note that robots are permitted to expand beyond their 10cm by 10cm footprint after the start of a bout, as described in the Robot Challenge rules.
  • All ground contact points that bear the weight of the main body of the robot must fit within the 10cm x 10cm footprint throughout the entire bout. It is permissible for parts of the robot to touch the ground outside the 10cm x 10cm footprint once the bout is underway, but the weight of the main body of the robot must not rest on them.

Following validation (the “weigh-in”), if a team makes any change to their robot which increases its size or mass, they must repeat the validation process prior to competing in a match.

Sorting phase

The referees will divide the competing teams into two pools. The initial ranking in each group will be determined primarily by the results of the Race to the Wall challenge. The objective of the sorting phase is to select the top 8 teams from each group. A variation on the so-called bubble sort will be followed for the majority of the sorting phase. However, the referee in charge of each arena may deviate from this pattern at his/her own discretion to resolve any unforeseen ranking issues or anomalies.

In each group, the sorting phase will conclude until the referee is satisfied that he/she has identified which 8 teams should progress to the knockout phase of the tournament.

Knockout phase

The 8 top-ranked teams from each group (A1, A2, A3…A8 and B1, B2, B3…B8) will proceed to the knockout phase of the tournament. When a team loses a match in this phase, they are eliminated from the tournament. The referees will decide the number of bouts per match in each stage of the knockout phase.

The matches in this phase of the tournament are as follows:

  • 8 Last-16 Matches: A1 v B8, A2 v B7, A3 v B6, A4 v B5, A5 v B4, A6 v B3, A7 v B2, A8 v B1
  • 4 Quarter Finals: A1/B8 v A5/B4, A2/B7 v A6/B3, A3/B6 v A7/B2, A4/B5 v A8/B1
  • 2 Semi Finals: A1/B8/A5/B4 v A3/B6/A7/B2, A2/B7/A6/B3 v A4/B5/A8/B1
  • 1 Final: A1/B8/A5/B4/A3/B6/A7/B2 v A2/B7/A6/B3/A4/B5/A8/B1

Laboratory access on Wednesday

  • Laboratory access will be provided prior to the normal scheduled RoboSumo class time on Wednesday, subject to the limitations of the timetable for each ground floor laboratory. One or more of the RoboSumo tutors may also be available during the morning, but bear in mind that they are likely to be in high demand, so if you know in advance that you will have major difficulties getting your robot working it may be wise to contact your group’s tutor earlier rather than later.
  • There will be no RoboSumo lecture from 2-3pm on the day of the tournament. Instead, teams will proceed directly to KEG-036 at 2pm for the tournament weigh-in.
  • The normal lab facilities will remain open from 3pm onwards, to facilitate teams who wish to carry out repairs or adjustments to their robots. However, bear in mind that if the referee summons you to a match and you are not present, your opponent will be granted a walkover victory.

Competitor check list

Inevitably, many teams will face technical issues on the day of the tournament, and it’s impossible to foresee every problem. However, there are certain issues which we see every year:

  1. PLEASE PLEASE PLEASE ensure that your robot is compliant with the size and mass restrictions. Yes, 101mm is too much! And yes, 501 grams is too much! To avoid problems, please leave some margin for error. We need to be absolutely strict about these limits and butchering your carefully crafted robot at the last minute to reduce its size or weight can be a heartbreaking experience.
  2. If you haven’t already tested your robot actually driving around, please do so BEFORE the tournament. Bizarrely, every year we see teams who leave it until the very last minute to attach the wheels to their motors for the first time. Unfortunately, many of them discover at that point that their gearing is totally inappropriate and the robot cannot actually move.
  3. Focus on the basics. This means moving around and responding to the white border of the arena so that you don’t accidentally drive out of it. Even if you don’t get the rangefinder working properly, with luck you can win a few bouts just by staying mobile and staying on the table.
  4. Speaking of which… don’t be too reliant on your rangefinder / proximity sensor (if you’re using one). These sensors can sometimes completely fail to detect an opponent, depending on its shape and material. Design your code so that the robot will still do something intelligent if it doesn’t detect the opponent.
  5. Make sure your robot doesn’t simply spin around the spot for the entire bout. This behaviour will be viewed very unfavourably by the referee.
  6. Make sure you bring plenty of spare batteries.

Finally, remember to get plenty of photos and videos of your robot (and team) in the run up to and during the tournament. Of all the evidence you will provide on your blog, photos and videos are some of the easiest to create, and they can really help to tell the story of your project.

Finally, best of luck to all of you!

Posted in Uncategorized | Leave a comment

Code examples from today’s class

Example 1: Spin Search

//
// Spin search sumo example MSP430G2553
// Written by Ted Burke - Last modified 30-11-2016
//
// P1.0 is proximity detector
// P1.1 is colour sensor
// P2.0 is green LED
// P2.1 and P2.2 are left motor
// P2.3 and P2.4 are right motor
// 

#include <msp430.h>

void main( void )
{
    WDTCTL = WDTPW + WDTHOLD; // Disable watchdog timer
    
    // Digital i/o
    P1DIR = 0b00000000; // Sensors: P1.0 is proximity, P1.1 is colour
    P2DIR = 0b00011111; // Motors and LED
    
    while(1)
    {
        if (P1IN & BIT0) // Proximity sensor
        {
            P2OUT = 0b00010101; // Forward with LED on
        }
        else
        {
            P2OUT = 0b00001100; // LM forward, RM reverse, LED off
        }       
    }
}

Example 2: Bounce Around Table

//
// Bounce around sumo robot example MSP430G2553
// Written by Ted Burke - Last modified 30-11-2016
//
// P1.0 is proximity detector
// P1.1 is colour sensor
// P2.0 is green LED
// P2.1 and P2.2 are left motor
// P2.3 and P2.4 are right motor
// 

#include <msp430.h>

void main( void )
{
    WDTCTL = WDTPW + WDTHOLD; // Disable watchdog timer
    
    // Digital i/o
    P1DIR = 0b00000000; // Sensors: P1.0 is proximity, P1.1 is colour
    P2DIR = 0b00011111; // Motors and LED
    
    while(1)
    {
        P2OUT = 0b00010100; // Forward with LED off
        
        if (P1IN & BIT1) // Colour sensor white?
        {
            P2OUT = 0b00001101;     // LM forward, RM reverse, LED on
            __delay_cycles(750000); // 0.75 seconds
        }
    }
}

Example 3: Spin Search and Move

//
// Sumo robot example MSP430G2553
// Written by Ted Burke - Last modified 30-11-2016
//
// P1.0 is proximity detector
// P1.1 is colour sensor
// P2.0 is green LED
// P2.1 and P2.2 are left motor
// P2.3 and P2.4 are right motor
// 

#include <msp430.h>

void main( void )
{
    WDTCTL = WDTPW + WDTHOLD; // Disable watchdog timer
    
    // Digital i/o
    P1DIR = 0b00000000; // Sensors: P1.0 is proximity, P1.1 is colour
    P2DIR = 0b00011111; // Motors and LED
    
    int counter;
    
    while(1)
    {
        // Search for opponent
        counter = 0;
        while(counter < 2000)
        {
            P2OUT = 0b00001100;     // LM forward, RM reverse, LED off
            
            if (P1IN & BIT0) break; // Proximity sensor detects object?
            
            counter = counter + 1;  // increment counter
            __delay_cycles(1000);   // 1 ms delay
        }
        
        // Driving to white line
        while ((P1IN & BIT1) == 0) // While colour sensor stays black
        {
            P2OUT = 0b00010101;     // LM forward, RM reverse, LED on
        }
        
        // Turn and drive back into the centre of table
        P2OUT = 0b00010010;     // turn
        __delay_cycles(500000); // 500 ms delay
        P2OUT = 0b00010100;     // forward
        __delay_cycles(1000000);
    }
}
Posted in Uncategorized | Leave a comment