Johnny the Training Robot

Cymraeg

Johnny the Training Robot

This is the EV3 unit we shall use for training in the basics of programming.

An image of the 'Johnny' unit
The specifications of the Johnny build. It's right wheel is powered by a motor in port C whilst the right is also motorised but through port B. A colour sensor mounted on the front pointing at the floor is connected to Port 3. An InfraRed sensor is facing forward mounted at the back and top, connected to Port 4

You can choose to either attempt each mission before referring to the solution or, if you are confident enough in your understanding just use these as programming guides.

The solutions given are the simplest, therefore, they have plenty of room for improvement.

Mission One:

Using only the drive motors, produce a program to make Johnny move forward in a straight line.

Programming Details: You should make sure the motors are at 100% power and the program only runs for 5 seconds.

Steps Involved:

The first stage with any programming is to think about what steps will need to be taken.

In this case there is a single step to take - Turning both the motors forward at 100% power for 5 seconds

Using Official Lego Mindstorms Software

Using Microsoft MakeCode Software

The chosen block for this program is the 'move steering' with set to 'On for Seconds'. The values then read 0 for direction, 100 for speed and 5 for seconds.
The resulting program reads: on start, steer motors B+C turn ratio 0 speed 100% for 5 seconds

Video of solution code at work:

Consider this...

Where does human error come into play here?

Can you think of why this program may not produce a perfect straight line with this robot (excluding the human error mentioned above)?

Mission Two:

Using only the drive motors, produce a program to make Johnny move in a square and return to his starting position.

Programming details:

  • Each side should be 4 full wheel rotations in length
  • The power for the turns should be set to 75%
  • In Lego Mindstorms Software a right-angled corner is achieved by using a turning value of 80 for just one rotation
  • In Microsoft MakeCode the turning value is set to a different ratio, this means it needs two full rotations

Steps Involved:

Move forward 4 rotations

Turn 90°

Move forward 4 rotations

Turn 90°

Move forward 4 rotations

Turn 90°

Move forward 4 rotations

Turn 90°

This shows we are repeating the same two instructions 4 times meaning we could use a loop with just these two commands set to run four times.

Using Official Lego Mindstorms Software

Using Microsoft MakeCode Software

A loop block set to 4 repeats containing two 'move steering' commands. First 'move steering' set to 'On for Rotations' with direction 0, speed 100% and rotations 4. Second 'move steering' set to 'On for Rotations' with direction 80, speed 75% and rotations 1.
The resulting program reads: on start, repeat 4 times, steer motors B+C turn ratio 0 speed 100% for 4 rotations, steer motors B+C turn ratio 80 speed 75% for 2 rotations

Video of solution code at work:

Consider this...

Why do you think the turning values for Johnny may differ from those of other robot designs using the same kit and motors?

If we ran this program on an identically built robot, it would not be guaranteed to work. Why might this be?

Mission Three:

Let's add some sound effects to indicate the start and the end of the program produced in Mission Two.

Steps Involved:

Choose start sound effect

Insert into start of program

Choose end sound effect

Insert at the end of the program

Using Official Lego Mindstorms Software

Using Microsoft MakeCode Software

Same program as mission two with a sound block inserted before and after the loop. Both blocks are set to 100% and default play once.
Same program as mission two with 'play sound effect information start' inserted before the repeat loop, and 'play sound effect information stop' after the loop.

Consider this...

How could you use sound effects or other additions to help with determining if a program is working correctly? Have a look at the sort of sounds available for clues.

Mission Four:

Please note - This is not yet possible with the Microsoft MakeCode Software.

Get Johnny to detect an InfraRed beacon and move towards it.

Programming details: The beacon is set to channel 3 and we want Johnny to stop just before he hits the beacon

Steps Involved:

Detect beacon

Move towards

Stop before hitting it


To help with determining how to set the beacon detection and movement, we need to know more about how the InfraRed sensor measures the beacon's heading.

The values of the beacon heading are between -25 (left) and 25 (right).

The problem is that all the values between could refer to in front or behind of the sensor.

The range of values and their positions in relation to the beacon

Image from 'The Lego Mindstorms EV3 Discovery Book' by Laurens Valk

So, if the beacon heading value is negative the robot needs to turn left, if the value is positive it needs to turn right.

Using Official Lego Mindstorms Software

A loop block with the end instruction set to 'Beacon Proximity of channel 3 at less than 10 threshold value'. Inside this loop is a switch set to 'beacon heading on channel 3 is less than 0', the yes strand has a 'move steering' block set to 'On' with a direction of -50 at 50% speed, the no strand contains a 'move steering' set to 'On' with a direction of 50 at 50% speed.

Video of solution code at work:

Consider this...

Why have we not just set the switch to 'if 0 move forward, if not turn'?

What would have happened if we didn't instruct Johnny to stop when near the beacon?

Looking at how Johnny is built, why can we not use a threshold value between 0 and 5 for stopping?

Mission Five:

Produce a program that will have Johnny following a line using the colour sensor mounted at the front.

Programming details: The line he will be following is white. The start position will have the colour sensor directly over the start of the line.

Steps Involved:

Constantly scan for the colour detected and check if it's white.

If not white need to adjust course to find the line again.

Put in a forever loop to keep it running, as no end point set.

It may help to review how we moved the robot in mission four as a similar principle is used here, just with a differen sensor input.

Using Official Lego Mindstorms Software

Using Microsoft MakeCode Software

A forever loop containing a switch set to 'compare colour' for value 3 (white). When true section contains a 'move steering' block set to 'On' in direction -50 at 30% speed. When false section contains a 'move steering' block set to 'On' in direction 50 at 30% speed.
Program reads: forever { if is color sensor 3 detected white then {steer motors B+C turn ratio -100 speed 30% } else { steer motors B+C turn ratio 100 speed 30% } }

Video of solution code at work:

Consider this...

How could we use sounds to test line detection in the program?

Why would this program fail if the speed was increased too far?

Why would this program fail if the white line took a very tight turn to the left?

If a red taped line was put across the end of the white line how would you change the program to stop at this point?

Mission Six:

Program Johnny to navigate a maze using his InfraRed sensor.

Programming details:

  • 40 is a good threshold for stopping before starting to turn
  • The threshold of 60 can be used to check if a turn is clear or not
  • Turning 90° for this enclosed space involves the following figures:
    • Lego Mindstorms software: turn value of 85 at 50% speed for 1 rotation
    • Microsoft MakeCode: turn ratio of 200 at 25% speed for 0.8 rotations

Steps Involved:

Move forward until the IR sensor detects a wall

Turn on the spot 90°

Check for a wall

If no wall it should move forward and repeat

If it detected a wall it needs to turn 180° in the other direction before moving forward and repeating

Using Official Lego Mindstorms Software

Using Microsoft MakeCode Software

The program is all contained within a forever loop and follows this order: 'move steering - On, direction 0 and 25% speed','wait until infrared proximity < 40', 'move steering - On for Rotations, direction 85 at 50% speed for 1 rotation', 'Switch to measure infrared proximity < 60', if yes then 'move steering - On for Rotations, direction -85 at 50% speed for 2 rotations'.
Program is all in a forever loop and reads: forever, { steer motors B+C turn ratio 0 speed 25%, if infrared 4 proxiity < 45 then { steer motors B+C turn ratio -200 speed 25% for 0.8 rotations, if infrared 4 proximity < 60 then {steer motors B+C turn ratio 200 speed 25% for 1.6 rotations}}}

Video of solution code at work:

Consider this...

Why would this program not work if the maze involved dead-ends?

Why would it be better practice to write a program that wasn't just designed to navigate this maze of right-angled turns?