Robot courier Lesson 6.2 All coursesFor teachersStudy in the app Student Arduino Uno + L298P motor shield
Topic 6 · Lesson 6.2

Robot courier: test runs

Final task, part 2: make the program reliable, conduct test runs and analyze the result.

2 × 45 min1–2 students per robotProject

Lesson result

Two qualifying attempts were made, each scored on a sheet. The team explains their program and tells what error they found and how they fixed it.

You will learn

  • Find the cause of an error by observation and change one thing at a time.
  • Check that the program works under slightly different start conditions.
  • Conduct an autonomous race according to the rules and evaluate it according to the criteria.
  • Explain the structure of your program and the next step of improvement.

Need to know

  • 6.1 Robot Courier: Plan and Program

Will need

Ultrasonic distance sensorServo gripperLine sensor (analog, Trema) × 2
Download PDF:InitialAverageAdvanced

Why this lesson

A program that has completed the route once is not a finished program yet. Today you will make it reliable, conduct two valid attempts and analyze the result like a real engineer.

Warm up · remember
  1. What part of your plan didn't work reliably last time?
  2. Why are continuation points not counted after helping with hands in a qualifying attempt?
1
Lesson 1 · 45 min
Debugging and reliability
1

Entire test drive

8 min

What should a robot do. The robot's task is to repeatably execute the delivery according to its plan. The team's job is to prove this with observations and explain why the program chooses each action. We use a ready-made robot, a field, a logbook and our proven program.

What we use and how it works. During the race, a chain works: the sensor gives a signal, the program checks the condition, the performer executes the command, a new measurement shows the change. An error can occur at any link. Debugging begins from the first place where the observation diverges from the prediction: for example, the sensor saw a stripe, but the condition did not recognize it.

How to link a dimension to an action. Record the expected action and actual result, change one possible cause at a time, and repeat the same section. One successful run does not establish repeatability. A successful build means the compiler accepts the program; delivery and stopping must be confirmed by observing the actual run.

  1. Place the loads in place and the robot in the starting area.
  2. Run the entire route and don't interfere.
  3. Write down in the journal at which part of the plan the robot first did the wrong thing.
It should work

You know which section is unreliable, or that the entire route has been completed.

  1. Place the loads in place and the robot in the starting area.
  2. Run the entire route and don't interfere.
  3. Mark each line in your plan from lesson 6.1: completed or not. The first unexecuted line is the section from which you will begin debugging.
It should work

The plan is marked out for a test run, the area for debugging is selected.

  1. Do two practice runs in a row without corrections in between.
  2. For each run, record the stage of the first failure (departure, line, intersection, approach, gripping, turn, placement, finish) and the run time in seconds.
  3. Failure in the same place in both races or in different ones? What does this say about the cause?
It should work

Two races in the log with the stage of failure and time, the conclusion is whether the error is random or permanent.

2

Find and fix the error

25 min

Debugging proceeds in a circle of four steps. Main rule: change one thing at a time, otherwise you won’t understand what helped.

StepWhat are you doingExample
WatchingDescribing what the robot didThe robot drove past cargo 2
ReasonI suggest one possible reasonMissed the intersection: drove through it without noticing
One changeI'm changing one thingSlowing down before an intersection
CheckI launch only this sectionThe robot stops at an intersection 3 times out of 3
  1. Fill out such a table in the log for your error.
  2. Check the correction in your section, and not along the entire route: it’s faster.
  3. When a section runs three times in a row, check the entire route and save the new working version.
Hint: I don't understand what the program does

Temporarily add output to the Serial Monitor: what route decision is being made and what the sensors are seeing. Before testing, you can leave this conclusion - it does not interfere.

It should work

The error was found and corrected, the path to the cause is recorded in the log.

Debugging goes in a circle: observing → reason → one change → check. Change one thing at a time, otherwise you won't know what helped.

WatchingReasonOne changeCheck
  1. Fill out the table in the log for your error. If the first reason is not confirmed, add a line with the following.
  2. Test the fix only in your area: place the robot in front of it.
  3. When a section runs three times in a row, check the entire route and save the new working version.
Hint: I don't know where the error is

Start the first half of the route. It worked - look in the second one. So in two or three launches you will find a site.

It should work

The error was found and fixed, there are debug circle lines in the log.

Debug by evidence, and not by guess.

  1. Add diagnostics to the program: the number of the route decision being made and the sensor readings at the time of the decision are displayed in the Serial Monitor. Connect the USB cable and start the robot with it, holding the cable; or light up the L LED on each solution.
  2. For your mistake, write down hypothesis and experience that can refute it, - before changing the code.
  3. Carry out the experiment. The hypothesis was not confirmed - write a new one. There must be at least two circles in the journal if the first one did not give an answer.
  4. The correction is counted when the section is completed five times out of five.
HypothesisExperienceWhat it showedConclusion
It should work

The diagnostics are working, the journal contains hypotheses, experiments and conclusions, the section is passed five times out of five.

3

Check reliability

12 min

At the competition, the conditions will be slightly different: the robot was not placed at the start ideally, the battery is slightly discharged. Check in advance.

  1. Place the robot at the start a little to the left, then a little to the right. Is the route going?
  2. If the robot starts to move slower than during the tests, ask the teacher to check the battery. After replacement or charging, re-select the timing of straight sections and turns.
  3. Run the entire route twice in a row without corrections between runs.

Two complete routes in a row from different starting positions.

All solutions at intersections are correct in two runs in a row.

Ask your partner to give you another card and go through it, changing only the route in the program. If this requires rewriting functions, the program is not yet ready for testing.

It should work

The program runs the route twice in a row. The working version has been saved for testing.

2
Lesson 2 · 45 min
Test and analysis
4

Valid attempt 1

10 min
  1. Place the loads in their original places according to the diagram of your field.
  2. Before you start, agree on which four decisions to watch for at intersections.
  3. One launch. Then the robot drives on its own: you cannot touch it, adjust loads, or send commands.
  4. If you need help, stop the robot. Safety is more important than points.
It should work

The attempt is recorded on the score sheet.

5

Correct if necessary

8 min

You can correct the program between attempts. Use the debugging circle: observation → reason → one change → check the area.

It should work

The correction was checked on site and saved - or you left the program unchanged.

6

Scoring attempt 2

10 min

Make a second attempt using the same rules. Each attempt is scored separately: the best parts of different attempts are not added together.

It should work

Both attempts are recorded on the score sheet.

7

Parsing the result

12 min
  1. First, evaluate your attempt on the evaluation sheet yourself, then check the rating with the teacher.
  2. Show in your program: forward movement, P-controller calculation, ultrasonic stopping, gripper control and the line that ends the trip.
  3. Tell us about one bug that you found and fixed. How did you understand what the reason was?
  4. Write in your journal: which skill does your robot work best, and which one you would improve further.
  5. Save the final sketch and evaluation sheet.
Test yourself
  1. First, evaluate your attempt on the evaluation sheet yourself, then check the rating with the teacher.
  2. Show in your program: forward movement, P-controller calculation, ultrasonic stopping, gripper control and the line that ends the trip.
  3. Tell us about one error that you found and fixed, along the lines of the debugging circle.
  4. Explain one of your decisions: why at some intersection or section you did exactly that. What would have happened with a different solution?
  5. Write in your journal: which skill does your robot work best, and which one you would improve further and how.
  6. Save the final sketch and evaluation sheet.
Test yourself
  1. First, evaluate your attempt on the evaluation sheet yourself, then check the rating with the teacher.
  2. Show in your program: forward movement, P-controller calculation, ultrasonic stopping, gripper control and the line that ends the trip.
  3. Write a short engineering report in the journal: - reliability according to your data: how many samples of each section were passed; - the main mistake, hypotheses and experiments with which you found it; - the biggest remaining risk and one change that would reduce it - and how you would check that it helped.
  4. Tell the report to the class in two minutes.
  5. Save the final sketch, evaluation sheet and report.
Test yourself

Evaluation Criteria

How the race is scored

Maximum 100Credit from 70
CriterionPointsMax.
Direct departure from the start
5 — I drove forward from the start zone myself.
10 — Reached the line and continued the task without pushing.
10
Movement along the line
10 - I lost the line, but returned to it myself and continued the route.
20 — Passed all sections of the line and arc using the sensors without losing the line.
20
Road selection at intersections
5 - For each of the four decisions at intersections that coincided with the plan.
20
Cargo 1: detection
5 — Stopped in front of the load by ultrasound.
5
Weight 1: Grab
5 - He grabbed the load and took it away, rather than pushing it out.
5
Cargo 1: delivery
5 - The cargo is standing and partially in the desired area.
10 - The load is completely in the desired area, the gripper is released.
10
Cargo 2: detection
5 — Stopped in front of the load by ultrasound.
5
Weight 2: Grab
5 - He grabbed the load and took it away, rather than pushing it out.
5
Cargo 2: delivery
5 - The cargo is standing and partially in the desired area.
10 - The load is completely in the desired area, the gripper is released.
10
Direct entry and stop
5 — After the line, I drove forward into the finish area.
10 - Stopped inside the zone and stands with the motors turned off for at least 3 seconds.
10

Required conditions for credit

  • The team explains their program: showing forward motion, P-control calculation, ultrasonic stopping, gripper control and the line that ends the trip.
  • Bends were made according to the readings of line sensors with a P-controller.
  • The approach to the cargo ends by ultrasound measurement, and not just by time.
  • After the robot starts, no one touches or sends commands to it.

Rules

  • Speed is not assessed: there is no bonus for a fast race.
  • There are no negative penalties. An action not completed simply receives no points.
  • Cargo in a foreign zone or delivered out of order - 0 for its delivery.
  • After manual assistance, the autonomous race is over. You can continue to practice, but no points are added.
  • Each attempt is scored separately. The best parts of different attempts don't add up.
  • There is no penalty for making an emergency stop for safety reasons.

Test yourself

Select answers to prepare. They are not stored or evaluated on the site. Take the knowledge test in the course syllabus or discuss the answers with your instructor.

● Basic

1.Both line sensors show "white". What does it mean?
2.The ultrasonic sensor did not receive an echo. How to enter the program?
3.The robot drove past the cargo. What do you do first?
4.During the scoring attempt, the robot went astray, and you put it back on the line. What's with the attempt?
5.After the finish, the robot started moving again. What is the probable reason?

★ Intermediate level

1.In the middle field, the robot chose the wrong decision at an intersection. Where to look for the reason first?
2.Why do a practice run before a qualifying attempt?
3.The robot passed cargo 2. Which entry in the debug circle is “cause” and not “observation”?
4.You don't know where the error is. How to find it in 2-3 launches?
5.Why do they only change one thing between attempts?

★★ Advanced level

1.On a steep S-arc, the robot only loses line with a freshly charged battery. What's most likely?
2.What to write in the log after an unsuccessful race? Choose all the correct answers.
3.Hypothesis: “The robot misses junction В because of its speed.” Which experiment could disprove it?
4.Diagnostics prints the solution number at each intersection. The robot turned in the wrong place, and the last one printed was “solution 4,” although according to the plan this is intersection 5. What does this mean?
5.In the report: “section 3 passed 4 times out of 10.” Which conclusion is correct?

Answer questions at your level. Correct answers needed: Beginner - 4 out of 5; Average - 4 out of 5; Advanced - 4 out of 5. Answers will be checked by the teacher or course program.

Summary

You went through the entire path of an engineer: you analyzed the problem, made a plan, assembled a program from proven parts, found and corrected errors and tested the result on the field. If you pass the test, try the next level or elective lessons - encoders and PID controller.

How to confirm the result

The result of the experiment relates the conditions, program version, observation and conclusion. Comparing attempts with one change helps verify the cause, including failed attempts. The mark refers to practice already completed; repetition for the sake of marking is not necessary. The discrepancy with the forecast sets the next hypothesis to be tested. A model, measurements of a real robot, and an explanation are different types of evidence.

Lesson vocabulary

debuggingFinding and correcting an error: observe, find the cause, change one thing and check again.
autonomous check-inA race in which the robot drives itself after the start: no one touches it or sends commands.
reliabilityThe program works not just once by chance, but every time - even if the robot is set to start a little differently.