Building Mechatronic and Automated Systems

What Mechatronic Systems Are

🎯 (CT5-THI-01, CT5-EVL-01)

📌 Describe mechatronic systems

A mechatronic system joins three areas of engineering: mechanics, electronics and computer control. Mechanics means moving parts such as wheels, gears and arms. Electronics means circuits and power. Computer control means a program that makes decisions. The name mixes “mechanical” and “electronics”.

Most mechatronic systems do three jobs:

• Sense. A sensor detects some kind of input from the world around it, such as light, distance or sound.
• Decide. A microcontroller is a small computer built to handle specific tasks. It reads the sensor and decides what to do.
• Act. An actuator turns a signal into movement or action, such as a motor that turns.

Here is an example: a hands-free bin for the canteen. A hand near the bin makes the lid open. When the hand moves away, the lid closes.

Real-World Mechatronic Systems and Their Impact

🎯 (CT5-EVL-01, CT5-SAF-01)

📌 Investigate the development and impact of a mechatronic, robotic and/or automated system in a real-world application

To investigate a real-world system, look at how it works, how it developed and who it affects. A good example is the automatic sliding door found at many shops and public buildings.

How it works. A sensor detects a person walking towards the door. A microcontroller decides to open it. A motor slides the door open, and the door closes again after a short time.

How it developed. Early doors were opened by hand. Some older automatic designs used a push button or a pressure mat. Newer doors use sensors, so people do not need to touch anything. Each change met a need, such as easier access for people with prams, wheelchairs or heavy shopping.

Impact. Look at more than one view. Consider who gains and who may be at risk.

• Benefit: less effort for people with limited hand strength, or anyone whose hands are full.
• Risk: a door that closes too quickly could hit someone. A fault could leave an entrance stuck.
• Who is affected: shoppers, staff, people with disability, and the technicians who maintain the door.

Human-Controlled and Autonomous Systems

🎯 (CT5-THI-01, CT5-EVL-01)

📌 Identify mechatronic and automated systems that operate through human or autonomous control

Some systems wait for a person to decide each move. Others sense their surroundings and decide for themselves. Knowing the difference helps you judge who is in control, and who is responsible.

• Human-controlled systems move because a person tells them to, using a joystick, a remote or an app. A remote-controlled toy car is one example.
• Autonomous systems sense their surroundings and choose their own actions. Nobody picks each move. A robot vacuum cleaner that works out its own path around a room is one example.
• Automated systems follow a set routine. A timer that switches on the school lights at the same time each day is one example. Automated does not always mean autonomous.

Ask who decides the next move. If a person decides, it is human-controlled. If the system uses its own sensor data to decide, it is autonomous. If it follows a fixed routine, it is automated. Some systems mix these types, so give a reason for your choice.

Inputs, Storage, Processes and Outputs

🎯 (CT5-DAT-01, CT5-THI-01)

📌 Describe inputs, storage, transmission, processes and outputs in mechatronic and automated systems

Every mechatronic system takes in data, keeps some of it, works on it and produces a result. Think of a recipe. Ingredients go in, you cook them, and a meal comes out.

• Input is data that goes into the system, such as a reading from a sensor or a button press.
• Storage is where data is kept while the system works. The microcontroller keeps the latest reading and the trigger distance (the distance at which the lid opens) in its memory.
• Transmission is moving data from one part to another, along a wire or by radio signals.
• Process is what the program does with the data. For example, it compares the reading with the trigger distance.
• Output is what the system produces. For example, the motor turns and the lid rises.

Functional Requirements of a Mechatronic System

🎯 (CT5-DPM-01, CT5-THI-01)

📌 Specify the functional requirements of a mechatronic or automated system, including stating the purpose of a system, describing use cases and developing test cases of inputs and expected outputs

A functional requirement says what a system must do. Each one must be clear enough to test. Write each one as “The system must …”.

To specify functional requirements, do four things:

1. State the purpose. Say in one sentence why the system exists.
2. Describe a use case. A use case is one user doing one task, step by step.
3. List the requirements. Number each one.
4. Write test cases. Each test has an input (what you do) and an expected output (what should happen).

Write each expected output before you run the test, so the result cannot change your answer.

Non-Functional Requirements of a System

🎯 (CT5-DPM-01, CT5-SAF-01)

📌 Specify the non-functional requirements of a mechatronic or automated system

• Battery disposal.
• Improved wellbeing as result of implementation.
• Ease of manufacturing the system.

A non-functional requirement describes how well a system must work, or what it must be like. It covers qualities such as cost, safety, size and ease of use. Write each one so that you can check it.

NESA gives three examples. Here is how each one could look for the bin.

Battery disposal

The bin runs on batteries, and batteries wear out. A possible requirement: the battery must be removable without special tools, so staff can recycle it. A possible test: a staff member removes the battery and follows the school’s recycling rules. Never put a battery in the general rubbish, and never cut open, heat or puncture one.

Improved wellbeing as a result of implementation

A tidier canteen may help students feel more comfortable. Some students may also prefer not to touch a shared lid. A possible requirement: the lid must open without anyone touching it. A possible test: survey a small group of students before and after two weeks of use, then compare their answers.

Ease of manufacturing the system

A class may need to build several bins. The design should use parts that a team can fit and wire in one lesson, with no cutting. A possible requirement: a team of three must build one lid in a single lesson, using only the kit parts. A possible test: time the team as they build one lid.

Safety. A moving lid can pinch fingers, so it must be slow enough for a hand to move clear. A possible requirement: the lid must take at least a made-up 2 seconds to close. A possible test: time each closing with a stopwatch.

Social, Ethical and Legal Responsibilities

🎯 (CT5-SAF-01, CT5-EVL-01)

📌 Consider the social impacts and ethical and legal responsibilities associated with mechatronic and automated systems

• Companion robots, job loss due to automation, the impact of surveillance.
• Asimov’s laws of robotics, military robots.
• Safety and liability, privacy acts.

When a system acts in the real world, its effects reach beyond the technology. To consider these effects, look at them from three angles: social, ethical and legal. For each one, ask who is affected and whether it is fair.

Social impacts

• Companion robots keep people company. They may comfort some people, but they could also replace time with other people.
• Job loss due to automation. Automation can remove some tasks, while new jobs may appear in building, checking and repairing machines.
• Surveillance. A sensor that records faces or movements can watch people who have not agreed to be watched.

Ethical responsibilities

Asimov’s laws are rules for robots, written by the science fiction writer Isaac Asimov. The first law says a robot must not harm a human, or allow a human to come to harm through doing nothing. They are fiction, not a safety standard, but they start useful discussions.

Military robots raise hard questions. Should a machine ever choose when to use force? People disagree, so give reasons on both sides.

Legal responsibilities

• Safety and liability. Liability means being legally responsible for harm. If a machine injures someone, who is responsible? The owner, maker and programmer may share responsibility. The answer depends on the law where you live.
• Privacy acts. In Australia, the Privacy Act 1988 (Cth) is a national law. Its Australian Privacy Principles set rules for many organisations about how they collect, use and store personal information.

Diverse Perspectives on Automation

🎯 (CT5-SAF-01, CT5-DES-01)

📌 Explore mechatronic and automated systems considering the perspectives of diverse groups, including Aboriginal and Torres Strait Islander Peoples, culturally and linguistically diverse people, people of different ages and gender, and people with disability

• Permissions and protocols for capturing images, voice or video of Aboriginal Peoples.
• Understanding of Native Title and access to land for automated vehicles.
• Supporting independence for some people with disability through autonomous transport or robotic prosthetics.

The same system can affect different people in different ways. A design that suits one group may fail another. To explore a system, ask who it was designed for, and who was left out of the design.

Images, voice and video of Aboriginal Peoples

A bin or robot with a camera or microphone may capture images, voices or video. For Aboriginal and Torres Strait Islander Peoples, this can involve cultural protocols and consent. Ask the local Aboriginal community what permission and protocols apply before you record. Do not assume one rule fits every community. Recordings of stories or cultural material can be Indigenous Cultural and Intellectual Property (ICIP), so the community may have rights over them.

Native Title and access to land

An automated mower or a delivery robot may need to travel over land. Native Title is a recognition in Australian law of some Aboriginal and Torres Strait Islander Peoples’ rights and interests in land, where those rights still exist. Before you test on any land, find out who has rights to it, and talk with the community or the people who manage it. Permission matters more than convenience.

Supporting independence for people with disability

An autonomous wheelchair or a robotic prosthetic (an artificial limb with motors) can help a person move or do tasks on their own. Design with people with disability, not just for them. Ask what they need, and test with them.

Age, gender, language and background

A voice-controlled bin might not understand every accent. Small buttons may be hard for young children or older people to press. Test with a varied group of users, so you find problems early.

People of different genders can have different needs and experiences with the same system. Do not assume what one group needs. Ask each tester what worked for them, and what did not.

How Mechatronic Systems Have Evolved

🎯 (CT5-EVL-01)

📌 Describe how mechatronic and automated systems have evolved in response to people's needs and opportunities

Early machines were mostly mechanical. They used gears, levers and simple switches to do their work. Over time, people added sensors, then computer control. Each change grew from a need or an opportunity.

• Mechanical stage. Machines used gears, levers and timers. A simple timer could run a washing machine through a set cycle.
• Electronic stage. Sensors and simple circuits let machines react to change. An automatic door could open when a sensor noticed a person.
• Computer-controlled stage. Small microcontrollers let a program decide how a machine behaves. The same parts can do different jobs when the program changes.

The three stages are a simplified model of how automatic doors developed, not a precise history. Real doors did not all change in these neat steps. Some older automatic doors used a push button or a pressure mat, as Part 1 described.

Parts also became smaller and cheaper. This made machines easier to place in new locations. The table shows some needs and the changes that met them.

Design Principles for Mechatronic Systems

🎯 (CT5-THI-01, CT5-DES-01)

📌 Explore design principles and issues relevant to mechatronic and automated systems

Design principles are guidelines that help you make good choices. They are not rules that must always be followed. Use each one as a question you ask about your design.

• Safety first. Can the system hurt someone? A moving lid can pinch fingers, so its speed and stopping points matter.
• Keep it simple. Fewer parts usually mean fewer faults. One sensor is easier to test than five.
• Build in modules. A module is a separate part, such as the sensor unit or the lid unit. Each one can be built and tested on its own.
• Design for testing. Include a way to check each part, such as a test button or a printed sensor reading.
• Plan for power. Batteries run out. A bigger battery often lasts longer, but it is heavier and costs more.
• Design for the user. Think about height, reach and how easy the bin is to use for different people.

Principles often pull against each other. This is a trade-off. A bigger battery helps the bin run all day, but it adds weight and cost, and it must be disposed of carefully later.

Comparing Alternative Designs

🎯 (CT5-DPM-01, CT5-THI-01)

📌 Generate alternative designs and evaluate them against the requirements to select a preferred design

A good designer does not stop at the first idea. They generate two or three alternative designs, check each one against the requirements, and pick the best.

1. List the requirements to check, such as FR1 (the lid opens when a hand is close).
2. Sketch two or three designs that might meet them.
3. Check each design against each requirement. Mark it Yes, Partly or No.
4. Choose the preferred design, and give a reason based on the requirements.

Choosing Control Systems and Microcontrollers

🎯 (CT5-THI-01, CT5-DPM-01)

📌 Select and justify control systems, components, microcontrollers and co-processors for a mechatronic or automated system

The control system reads the inputs and decides the outputs. In most school projects it is a microcontroller running a program. Choose it by matching what your system needs to do.

Check these criteria when you choose a control system or another component:

A co-processor is a separate chip that helps the main processor with one job. Many school systems do not need one. Add one only if the main processor cannot keep up.

Justify each choice in one sentence, such as: “I chose this board because it has enough free connections for the sensor and motor.”

Choosing Sensors for Input

🎯 (CT5-DAT-02, CT5-THI-01)

📌 Select and justify sensors for a mechatronic or automated system

A sensor detects an input. Choose one by asking what the system must detect, and how reliably. Sensors give readings in two main forms.

• A switch gives an on or off signal, such as a button that is pressed or not.
• A light sensor gives a value across a range, such as how bright a room is.

To justify a sensor, name it, say what it detects and give two reasons linked to the system. For the bin, these could include its range and how well it works in the canteen’s light. Bright light can affect some sensors, so test in the real room.

Choosing Actuators for Movement

🎯 (CT5-THI-01, CT5-DPM-01)

📌 Select and justify actuators for a mechatronic or automated system

An actuator turns a signal into movement or action. Choose one by asking what movement the system needs. Then check the strength, speed, precision and power it needs.

• DC motor. Spins continuously while it has power. Useful for wheels or a fan.
• Servo motor. Turns to a set angle and holds it there. Useful for lifting a lid to a fixed position.
• Stepper motor. Moves in small, counted steps. Useful when a position must be precise.
• Solenoid. A coil that pushes or pulls a rod when it is switched on. Useful for a short, sharp movement.

Lights and buzzers are output devices, and some systems treat them as actuators. Check how your class uses the word.

For the bin lid, a servo motor suits the job well. It can turn to an open position and hold it. A DC motor with gears could also work. Unless you add a way to check its position, the lid might not stop in the same place every time.

Choosing End Effectors and Manipulators

🎯 (CT5-THI-01, CT5-DPM-01)

📌 Select and justify end effectors/manipulators for a mechatronic or automated system

A manipulator is a robot arm made of links and joints. The end effector is the tool at the end of the arm that touches the object. Examples include a two-finger gripper, a suction cup and a magnet.

Choose the end effector by looking closely at the object. Ask:

• Is it flat, round or an odd shape?
• Is it heavy, light or easily damaged?
• Is it metal? A magnet only picks up magnetic metals.
• Must it be released quickly, or held for a long time?

Safety matters too. Classroom robots should not use sharp, hot or heavy tools as end effectors. Keep fingers clear of the gripper while it moves.

Motion Needed by Mechatronic Systems

🎯 (CT5-THI-01, CT5-DPM-01)

📌 Investigate motion required for mechatronic and automated systems

Motion is what the system must do with its parts. Before you choose an actuator, list every movement the system must make. Then describe each one.

• Linear motion is movement in a straight line, such as a door sliding along a track.
• Rotational motion is turning around a point or axis, such as a lid turning on a hinge.
• Oscillating motion is swinging back and forth through a set arc, such as a windscreen wiper.

For each movement, record:

• the type of motion and its direction
• how far it must go, such as to a set angle
• how fast it must move
• what could block it, such as a bag hanging in the lid’s path
• whether it must return to its start position

Many students forget the return movement. A lid that opens but never closes has failed, even if the opening worked well.

Collecting Data with Privacy and Security

🎯 (CT5-SAF-01, CT5-DAT-01)

📌 Investigate data collection and interpretation adhering to privacy and cybersecurity principles, including specify what data is collected, who owns it, and how it will be protected

• Data collected: recording smartphone GPS data.
• Ownership: users and vendors, suspending collection of data, cultural considerations such as Indigenous Cultural and Intellectual Property (ICIP).
• Who has access: onselling of data to a third party; law enforcement access to data.
• Protection: password protection, encryption or legal protection over how the data can be used.

A mechatronic system can collect data. Before it collects anything, answer four questions:

1. What data is collected? Be specific, not vague.
2. Who owns it? The user, the company that makes the device, or both?
3. Who can access it? Think about selling data to a third party, or sharing it with law enforcement.
4. How is it protected? Passwords, encryption and privacy law can each help.

Consider a running app that records GPS data. A GPS route can show where a person lives, plays sport and goes to school. Ownership, access and protection matter because that information is personal.

Encryption converts data into a form that only the intended person can read. A password controls who can log in. Encryption protects the data itself.

Some data is about communities. Aboriginal and Torres Strait Islander communities may have rights over data about them. The idea is called Indigenous Data Sovereignty, which means communities have a right to decide how data about them is collected, owned and used. Recordings of stories or cultural material can also be Indigenous Cultural and Intellectual Property (ICIP). Ask the community before you collect anything about them.

Data Types and Structured Code

🎯 (CT5-OPL-01, CT5-DAT-01)

📌 Represent data and code to facilitate computation, including selecting appropriate data types, understanding data type limitations and structuring code systematically

A data type tells the computer what kind of value a variable holds. A variable is a labelled box that stores a value. Choosing the right type prevents many errors.

# Example only: the names are made up and are not tied to one board.
lid_distance = 15.5        # float: a sensor reading can have decimals
trigger_distance = 30      # integer: a whole-number setting
bin_name = "Canteen bin"   # string: text
lid_open = False           # boolean: True or False only

Structured code is easier to read and check:

• Use names that say what a variable holds, such as trigger_distance.
• Group related steps into a function, a named block of code that can be reused.
• Indent the steps inside an IF or a loop, so the structure is clear.
• Add comments that explain why, not just what.

Planning Algorithms with Flowcharts and Pseudocode

🎯 (CT5-OPL-01, CT5-COM-01)

📌 Represent algorithms using flowcharts and pseudocode

A flowchart shows the steps of an algorithm as shapes and arrows. Pseudocode writes the same steps as short, plain-English lines. Both help you plan before you code.

• Terminator (rounded): START or BEGIN at the top, END at the bottom.
• Process (rectangle): an action, such as “open lid”.
• Decision (diamond): a yes or no question. Label both exits.
• Input or output (parallelogram): data coming in or going out.

Pseudocode for the bin. This is an example, not tied to any one board:

START
REPEAT forever
    SET distance TO read distance sensor
    IF distance is less than trigger distance THEN
        open lid
    ELSE
        close lid
    END IF
END REPEAT

Designing and Changing Algorithms

🎯 (CT5-OPL-01, CT5-THI-01)

📌 Design or modify existing algorithms for mechatronic or automated systems

To modify an algorithm, read the existing one first. Then decide the smallest change that meets the new need. Update the flowchart and the pseudocode together, so they still match.

1. Say what the existing algorithm does, in one sentence.
2. State the change, in one sentence.
3. Find the place where the new check belongs.
4. Update the pseudocode and the flowchart.
5. Desk check the new version (see the next section).

START
REPEAT forever
    SET distance TO read distance sensor
    SET full TO read bin-full sensor
    IF full is true THEN
        close lid
        turn on warning light
    ELSE IF distance is less than trigger distance THEN
        open lid
        turn off warning light
    ELSE
        close lid
        turn off warning light
    END IF
END REPEAT

Desk Checking Your Algorithms

🎯 (CT5-OPL-01, CT5-DPM-01)

📌 Validate algorithms with desk checking

A desk check tests an algorithm by hand, before any code runs. You follow the steps on paper with sample inputs, and write down the value of each variable as you go. This is called tracing. It costs only paper and a pencil.

Use a trace table. Each row is one run, and each column is a value you need to watch. These are made-up readings for a trigger distance of 30 cm.

Run 4 is an edge case. The reading equals the trigger distance, and FR1 says “closer than 30 cm”, so the lid must stay closed. Now suppose a student wrote “is distance at most 30?” instead. Run 4 would open the lid, and the trace would show a fault. The desk check finds the error before any hardware is built.

Identifying a Real-World Problem to Solve

🎯 (CT5-DPM-01, CT5-DES-01)

📌 Investigate a real-world problem or need that can be solved by mechatronic and/or automated systems, including breaking it down into manageable parts and interviewing stakeholders to identify their needs

Before you build anything, you need to know exactly what the problem is. To investigate a problem means to look closely at it, ask the people it affects, and write down what you find.

Students and staff touch the canteen bin lid all lunchtime. This makes the lid messy and can spread germs. A problem statement says what is wrong, who it affects and what a good answer would do.

A big problem is hard to solve in one go, so you decompose it. That means breaking it into smaller parts. Each part should be small enough to test on its own.

To learn what people need, you can interview them with a set of planned questions. Every person affected by the problem or the solution is a stakeholder, even if they never touch the machine.

Reviewing Existing Solutions

🎯 (CT5-DPM-01, CT5-EVL-01)

📌 Evaluate existing solutions to the problem or related problems

An existing solution is a product, device or method that already solves the problem, or part of it. Look at these first. They save time and show what has worked for other people.

To evaluate a solution, judge it against criteria. Criteria are the things you measure it by. For the bin lid, useful criteria are: does it work without hands, does it need power, is it safe, what does it cost, and can everyone use it?

Three existing solutions could help you:

• A foot-pedal bin. It needs no power. It does need a foot, which can be hard for some people to use.
• A sensor-lid bin. It opens when a sensor detects something close. It is hands-free, but it needs power, and a sensor can react to things other than hands, such as a swinging bag.
• A sign asking people to close the lid. It costs almost nothing, but it depends on people remembering.

Evaluating means making a judgement, not just listing points. Say which criterion matters most for this canteen, which solution fits it best, and why. For a canteen where hygiene matters most, a hands-free design is the strongest of these three.

Reading and Changing Existing Code

🎯 (CT5-OPL-01, CT5-THI-01)

📌 Interpret and modify existing programs (code) for mechatronic and/or automated systems

Most programmers spend a lot of their time changing code that already exists. To interpret code is to work out what each line does. To modify code is to change it so it does something new.

Here is a short program written by someone else. It is an example only. It uses a list of simulated distances, so no hardware is needed.

# Example only: a simulated bin lid. No hardware is used.
readings = [80, 60, 25, 20, 90]    # simulated distances in cm

for distance in readings:
    if distance < 30:              # a hand is close
        print(distance, "cm: open the lid")
    else:
        print(distance, "cm: keep the lid closed")

Read it line by line. The for line repeats the code once for each reading. The if line checks one rule. The two print lines show what the lid should do.

Your task: open the lid when a hand is closer than 70 cm, and count how many times it opens. Change one thing at a time, then run the program again.

# Example only: the same program, changed.
readings = [80, 60, 25, 20, 90]
opens = 0                          # NEW: count the times the lid opens
for distance in readings:
    if distance < 70:              # CHANGED: threshold from 30 to 70
        print(distance, "cm: open the lid")
        opens = opens + 1          # NEW
    else:
        print(distance, "cm: keep the lid closed")
print("Lid opened", opens, "times")   # NEW

Now the 60 cm reading opens the lid, and the last line says Lid opened 3 times. If the output does not change where you expected, check that you edited the line that actually runs.

Building Modular Programs with Functions

🎯 (CT5-OPL-01, CT5-THI-01)

📌 Design and implement modular programs (code) with functions for mechatronic and/or automated systems

A module is a part of a program that does one job. In Python, you usually build a module from one or more functions. A module can also be saved as its own file, so other programs can use it. A function is a named block of code. It takes an input, does its job and gives back a result.

Why split a program this way? You can test one function on its own. You can reuse it in another program. And when something breaks, you know where to look first.

Here is the lid rule written as two small functions. The first answers one question. The second turns that answer into a message. It uses simulated readings, so it is an example only.

# Example only: simulated readings, no hardware.
def lid_should_open(distance, threshold=30):
    """Return True if the lid should open."""
    return distance < threshold

def describe(distance):
    if lid_should_open(distance):
        return "open the lid"
    return "keep the lid closed"

for d in [80, 25, 20]:
    print(d, "cm:", describe(d))

Read it from the top. def starts a function, and its name tells you what the function is for. return sends an answer back to the line that called the function.

To design a modular program, follow three steps. First, list the jobs the program must do. Second, give each job one function. Third, write the main loop last, so it only calls the functions in order.

Managing an Iterative Project

🎯 (CT5-DPM-01, CT5-COL-01)

📌 Plan and manage a project using an iterative approach

An iterative approach builds a project in small cycles. Each cycle, called an iteration, makes a small working version, tests it and improves it. Each repeat gets you a little closer to the goal.

Project management is the process of planning, organising, controlling resources, monitoring timelines and activities, and completing a project to reach a goal that meets identified criteria. An iterative plan helps here, because every iteration has a clear goal you can check.

A plan for the hands-free bin lid could look like this:

Write the plan before you start, and record the date you finish each iteration. You will need these notes for the project record later in this part.

Building Your Mechatronic System

🎯 (CT5-OPL-01, CT5-DPM-01)

📌 Build a mechatronic system using the preferred design and code in a general-purpose programming language

To build a mechatronic system, you join three kinds of part. A sensor detects input from the world around it. A microcontroller is a small computer that reads the sensor and makes decisions. An actuator is a device that turns a control signal into movement or action, such as a motor.

The control code runs in a control loop. A loop repeats three steps: read the sensor, decide what to do, then act. The example below is a simulated control loop written in Python. It is not tied to one board. Boards that run MicroPython use similar code.

# Example only: a control loop for a bin lid.
# read_distance() and set_lid() are stand-ins for real hardware code.
simulated = iter([80, 25, 20, 90])   # made-up sensor readings
THRESHOLD = 30                       # made-up limit in cm

def read_distance():
    return next(simulated)           # stand-in for the sensor
def set_lid(is_open):
    print("lid", "OPEN" if is_open else "CLOSED")

for step in range(4):                # four checks
    if read_distance() < THRESHOLD:
        set_lid(True)                # hand close: open
    else:
        set_lid(False)               # nothing close: keep closed

Trace the program on paper first. Each row is one step.

Run the simulated version first. Connect real hardware only when your teacher says so.

Applying Algorithms and Data Structures

🎯 (CT5-OPL-01, CT5-DAT-01)

📌 Apply selected algorithms and data structures for mechatronic or automated systems

A data structure is a way of storing many items so a program can use them. A list is one example. It holds several values in order, like a row of labelled boxes. An algorithm is a step-by-step procedure that solves a problem.

A single reading can be wrong. A bag swinging past the sensor can give one close reading for a moment. To avoid opening the lid for one odd reading, use a simple algorithm: open only after two close readings in a row. This is a similar idea to debouncing, which usually means ignoring the fast on-off bounce from a switch. Both wait to make sure a signal is real.

The program below uses a list of readings and a variable called previous_close, which remembers the last reading.

# Example only: open only after two close readings in a row.
readings = [80, 25, 90, 20, 22, 95]   # simulated distances in cm
THRESHOLD = 30
lid_open = False
previous_close = False                # was the last reading close?

for distance in readings:
    close_now = distance < THRESHOLD
    if close_now and previous_close:  # two close readings in a row
        lid_open = True
    elif not close_now:
        lid_open = False
    previous_close = close_now
    print(distance, "lid open" if lid_open else "lid closed")

Trace it with the table. Each row is one reading.

The reading of 25 cm is close, but the reading before it was not, so the lid stays closed. The reading of 22 cm is close, and so was the one before it (20 cm), so the lid opens.

Testing Programs and Debugging Errors

🎯 (CT5-OPL-01, CT5-DPM-01)

📌 Validate programs using test cases and debug a range of errors

To validate a program is to check that it does what it should, using test cases. A test case has an input (what the program receives), an expected output (what should happen) and a result (what actually happened). Write the expected output before you run the test.

Test the edges of a rule, not just the middle. A boundary test uses a value just below a limit, the limit itself and a value just above it.

Here are five test cases. The lid should open when the distance is less than 30 cm.

PT5 fails. A distance cannot be negative, so -5 means the sensor or its data has gone wrong. The program opens the lid anyway. It does not crash, but its answer is wrong. That is a logic error.

Debugging means finding and fixing errors. Three common kinds are:

• a syntax error, where the code breaks Python’s grammar, such as a missing colon;
• a logic error, where the code runs but the rule is wrong, such as a wrong comparison sign;
• a runtime error, where the program crashes while it runs, such as trying to change the text “abc” into a number.

The fix for PT5 is a check placed before the rule:

def lid_should_open(distance, threshold=30):
    if distance < 0:             # a distance cannot be negative
        print("Fault: negative distance")
        return False             # keep closed
    return distance < threshold

Run all five tests again. Every test should pass.

Try the bin lid

The tool below simulates the bin lid with no hardware. It uses the same rule and runs the same five test cases. Move the hand, change the trigger distance, then see which tests pass.

Using Specialist Terms Correctly

🎯 (CT5-COM-01)

📌 Select and use specialist terminology in context

Specialist terms are words with a precise meaning in computing and engineering. Use them correctly, so your teacher and your team know exactly what you mean. A word used in a sentence is easier to remember than a word on a list.

The table gives terms from this part. Where the NESA glossary gives a meaning, this table uses it in shorter words. Your own sentence shows how to use each term.

A common slip is using a vague word such as “the thing” or “the code” when you mean a particular sensor, loop or line. Say “the sensor reads the distance” and “the loop stops after four checks”. Precise words show that you understand the system.

Keeping a Project Development Record

🎯 (CT5-COL-01, CT5-DPM-01)

📌 Create a record of project development demonstrating iterative design and evaluation

A project record is a log of what you did, when you did it, what happened and what you changed. It shows your iterative design: each iteration built on the one before, and you evaluated each one before you went on.

Keep the record as you go. Do not write it all at the end, because you will forget what went wrong. Use the same headings for every iteration, so the record is easy to follow.

Here is a made-up entry for iteration 2 of the hands-free bin lid.

Add the date to every entry.

Evaluating Projects Against Requirements

🎯 (CT5-DPM-01, CT5-COL-01)

📌 Evaluate their own project and that of their peers using predetermined functional and non-functional requirements

To evaluate a project, check it against the requirements you set at the start. A functional requirement says what the system must do. A non-functional requirement says how well it must do it, such as being safe, quick to use or easy to keep clean.

Make a table. For each requirement, write the evidence: a test result, a timing, a photo or a comment from a user. Then say whether it was met, partly met, or not yet shown. Do not write “met” unless you have evidence to back it up.

When you evaluate a classmate’s project, judge the work against the requirements, not the person. Say what works, what is missing and one next step. Be kind, and be specific.

Setting Test Criteria for Components

🎯 (CT5-DPM-01, CT5-THI-01)

📌 Develop and apply test criteria for components of a mechatronic and/or automated system

Test criteria are rules that say what a part of the system must do, and how you will check it. Set them before you test. A component is one part of a system, such as a sensor. Test each component first, then test the whole system.

To write one test criterion, follow four steps:

1. Name the part, such as the distance sensor.
2. Name the property you are checking, such as accuracy.
3. Say how you will measure it.
4. Write the pass rule before you test.

Here are three criteria for a distance sensor, tested with a flat card and a ruler. The pass limits are made-up class limits for this example.

A part that fails its own test cannot be trusted inside a bigger system. That is why component tests come before the whole-system test.

Tracing Algorithms and Running Test Cases

🎯 (CT5-OPL-01, CT5-DPM-01)

📌 Validate algorithms and programs through tracing and test cases

Tracing and test cases check different things. Tracing follows an algorithm step by step, on paper, to check its logic. Test cases run the real program on chosen inputs, to check its output. Use both. A trace can catch a logic error before you run the code.

Here is the counting program from Part 3, with the threshold set to 70 cm. Its readings are 80, 60, 25, 20 and 90. Trace it step by step. Each row is one step, and the last column shows the count after that step.

Your trace ends with 3 opens. The program prints the same result: its last line says Lid opened 3 times. When the trace and the program agree, your reasoning is probably right. When they disagree, one of them is wrong, so find out which.

Now run test cases. Write each expected output before you run the test.

Tracing and testing work best together. The trace shows why the answer is right. The test cases show that it is right for the inputs you chose. No set of tests proves a program right for every input, so keep adding cases when you find a new one.

Proposing Improvements to Systems

🎯 (CT5-DPM-01, CT5-EVL-01)

📌 Propose software and hardware modifications to increase the effectiveness of a mechatronic and/or automated system

To propose a modification is to suggest a change to the software (the code) or the hardware (the physical parts) that would make the system work better. A good proposal names the problem, shows the evidence, describes the change and says what it costs.

Every change has a trade-off: something you gain and something you give up. A faster lid may be less safe. A more sensitive sensor may react to more things. Name the trade-off in every proposal.

Here are two proposals for the bin lid. The evidence is made-up test data.

Judge each proposal against your criteria, not by how clever it sounds. Ask three questions: Which one fixes the most important problem? Which one is safe? Which one can we build in the time we have?

Evaluating Ethics and Cybersecurity

🎯 (CT5-SAF-01)

📌 Evaluate social, ethical and cybersecurity considerations of mechatronic and automated systems

Every system affects people, even a small one. To evaluate its social, ethical and cybersecurity considerations, ask four questions: Who is affected? What data does it collect? Could it hurt someone? Who can change or access it?

Use this table to organise your thinking about the hands-free bin lid.

After the table, write one paragraph that answers three questions: Is the system fair to everyone who uses it? Is it safe enough to use? Could its data hurt anyone? Name the first change you would make.

Careers in Mechatronic and Automated Systems

🎯 (CT5-EVL-01)

📌 Explore careers in mechatronic and automated systems design, production, installation or maintenance

Mechatronic and automated systems need people to design them, make them, install them and keep them working. Some jobs focus on the hardware, some on the code, and many need both.

These are some roles you may hear about. Job titles and duties vary between employers, so treat this list as a starting point.

• Design: a design or robotics engineer plans new systems, builds prototypes and tests them.
• Production: a production technician sets up and checks machines on a factory floor.
• Installation: an installer or automation technician fits systems into buildings or factories, then checks the wiring and programs.
• Maintenance: a maintenance technician finds and fixes faults so machines keep running.
• Control software: a programmer writes the code that tells a machine what to do.

Each of these roles uses skills you practise in this part: breaking a problem into parts, writing and running test cases, reading code and keeping a clear record. Good habits here are useful in any of them.

Many of these roles need further study after school, such as a trade qualification, a diploma or a university degree. Entry paths differ, so check the requirements for each role in official careers information. Your school careers adviser can help you compare these roles and the study paths into them.