Functional Block Diagrams for Mechatronic Subsystems

Hello. In the previous lesson, you turned the arm-and-mobile-base idea into measurable requirements: usable reach, payload, repeatability, cycle time, base speed, and runtime. Those requirements state what success looks like. This lesson creates the architecture that will eventually make those outcomes possible.

A functional block diagram is not a wiring diagram or a final shopping list. It is a deliberately simplified map of the robot: what each subsystem is responsible for, what crosses each boundary, and how information, energy, and mechanical action form a closed system. You will create a first version for your mobile manipulator, then refine it as component choices become clearer.

---

From requirements to system architecture

A custom robot fails to behave as a single machine when its parts are designed as separate projects: a mechanical arm is designed first, then motors are attached, then electronics and software are treated as additions. Mechatronics works best when the relationships are considered from the outset.

The conceptual-design process in the reading below is useful here: begin with the overall task, split it into functions, then identify the exchanges of information and energy required between them.

For this project, the overall function is something like:

Under supervised indoor conditions, the robot travels to a work area, stops safely, picks up a specified object with its arm, transfers it to a drop location, and reports faults rather than continuing unsafely.

That sentence contains several distinct functions. A block diagram makes them visible before you decide whether an elbow joint uses a servo or stepper, which distance sensor to buy, or what the final chassis dimensions will be.

A useful first diagram separates five logical domains:

Domain	Core question it answers	Typical robot content
Mechanical	What moves, supports load, and physically interacts with the world?	Arm links, joints, gripper, chassis, wheels, bearings, transmission, payload
Electrical	How is electrical power generated, protected, distributed, and converted?	Battery, fuse, emergency disconnect, regulators, motor drivers, wiring harnesses
Sensing	What physical state is measured and made available as data?	Limit switches, encoders, distance sensors, current and battery-voltage sensing
Control	How are measurements compared with commands to produce safe actuator actions?	Microcontroller control loop, actuator command generation, watchdogs, interlocks
Software	How is the robot’s task planned, sequenced, configured, and monitored?	Raspberry Pi mission logic, user commands, logging, kinematics, state machines

These are functional roles, not necessarily five separate physical boxes. For example, a motor driver belongs primarily to the electrical domain because it delivers motor power, but it also accepts a low-power control signal. A servo contains a motor, gearbox, position sensor, and local controller in one enclosure, yet it still crosses several functional domains.

Assign each item a primary home in your diagram. Then show its interactions with the other domains. This prevents the common mistake of hiding a critical interface inside a vague block labeled “electronics.”

---

Information, power, and the mechanical plant

The core idea of a mechatronic system is a loop:

• The mechanical system creates motion and experiences loads.
• Sensors observe position, speed, contact, distance, current, or other physical state.
• The controller uses those measurements and the requested target to decide what actuators should do.
• The electrical system supplies protected power to actuators and computation.
• The software decides the higher-level task and provides targets, modes, and constraints.

The Control-system domain diagram shows a general closed-loop arrangement. Its “process” is the physical thing being controlled. In your project, that process is not one item: it includes the arm joints and gripper, plus the wheels and chassis of the mobile base.

A few features of the diagram are worth carrying into your own work:

• A setpoint is the intended state: a joint angle, wheel speed, gripper command, or robot mode.
• A sensor converts a physical condition into an electrical signal.
• An AD or analog-to-digital stage converts an analog measurement into a number the controller can use. In a practical microcontroller system, this may be an internal ADC.
• A DA or digital-to-analog/output stage represents the hardware that turns a controller’s command into an actuator-compatible signal. It might be PWM, direction and enable signals, or a dedicated motor-driver input.
• The feedback path gives the controller evidence of what actually occurred, rather than what it merely requested.
• The optional feedforward block anticipates an action based on the requested motion. You do not need to implement feedforward in the first build, but leave conceptual room for it. Later it might compensate for gravity in an arm joint or provide an initial motor command for a desired wheel speed.

The most important separation is this:

A command signal is not actuator power.
A microcontroller pin can command a driver or servo, but it must not be treated as the source of motor energy.

Likewise, sensor data is not the physical position itself. An encoder count is a measurement that may be delayed, noisy, mis-scaled, or absent after a wiring fault. Treat the measured state and actual physical state as related but distinct.

---

Functional architecture versus physical architecture

A functional diagram answers: what must happen? A physical architecture answers: what hardware will perform it?

The distinction matters because a good design may change hardware without changing the robot’s essential functional structure. You might replace a Raspberry Pi 3B with the Pi 5, change the motor driver, or switch from an ultrasonic sensor to a time-of-flight distance sensor. The functions—supervise mission, measure obstacle distance, command wheels, stop on fault—remain.

MathWorks illustrates this distinction by showing both a logical architecture, containing functions such as trajectory generation and motor control, and a physical architecture, containing sensors, actuators, and an embedded processor.

For your diagram, combine both views at a practical beginner-project level:

• Name the functional job first: “wheel-speed control,” “arm homing,” “mission supervisor.”
• Under or beside it, write a provisional physical implementation: “microcontroller,” “Raspberry Pi,” “wheel encoder,” “limit switch.”
• Mark uncertain choices as TBD rather than pretending they are settled.

This lets the diagram remain useful while the build evolves.

---

A provisional architecture for your mobile manipulator

Start with the five domains and use the following blocks. These are deliberately generic; they are a design hypothesis, not a required parts list.

Mechanical subsystem

Draw one mechanical-region box containing two nested groups.

Arm and end effector

• Base mount and rotating base
• Shoulder, elbow, and wrist joints
• Links, bearings, shafts, couplings, or belt/gear reductions
• Gripper and its mounting adapter
• Object or payload

Mobile base

• Chassis, wheel mounts, and caster
• Left and right wheels
• Gearmotors and wheel couplings
• Battery and electronics mounting locations
• Floor contact and external environment

Mechanical interfaces are physical: an actuator output shaft rotates a joint; a motor gearbox drives a wheel; the arm mounting plate transfers force into the chassis; the gripper contacts the object.

Electrical subsystem

Draw the protected power path as a separate group. At this stage, include:

• Battery pack
• Main fuse
• Emergency disconnect or emergency-stop power function
• Power distribution point
• Logic-power regulator
• Arm-actuator power rail
• Drive-motor power rail
• Motor drivers or servo-power distribution
• Shared ground/reference strategy, marked as a design item to be finalized

Do not draw every wire. Represent each power rail as a labeled connection, such as “protected motor supply” or “regulated logic supply.” Later, the power-distribution module will determine voltage, current ratings, wire sizes, fuse ratings, and protection devices.

Sensing subsystem

Use blocks for measurements that matter to the project requirements and safe operation:

• Arm home or limit switches
• Joint-position feedback, whether from servo feedback, potentiometers, or encoders
• Left and right wheel encoders
• Forward obstacle or distance sensor
• Battery voltage measurement
• Motor-current measurement, if available
• Optional temperature or tilt sensing

Place the physical sensor in the sensing domain, not the electrical-power box. A sensor needs power, but its primary job is to provide a measurement.

Control subsystem

For this build, assign time-critical work to a microcontroller. Draw the control blocks as:

• Command validation and mode handling
• Fixed-rate actuator-control loop
• Arm joint command generation
• Left and right wheel control
• Homing and travel-limit logic
• Safety watchdog and safe-stop behavior

The controller receives desired targets and measurements. It outputs low-level actuator commands. It also reports measurements, status, and faults upward.

Software subsystem

Your Raspberry Pi is well suited to the high-level tasks that can tolerate non-real-time operating-system timing:

• User or operator command interface
• Mission state machine: drive, stop, pick, place, return, fault
• Target selection and basic arm kinematics later in the course
• High-level navigation or obstacle-aware behavior
• Configuration storage and calibration values
• Timestamped logging and diagnostic display

The Pi should request actions; the microcontroller should enforce immediate actuator safety. If serial communication fails, the microcontroller must eventually stop or de-energize motion rather than continuing an old command indefinitely.

That division will be implemented in detail later. For now, the important architectural decision is that high-level planning and time-critical motion control are visibly distinct.

---

Label the interfaces, not just the blocks

A diagram becomes useful when every connection has meaning. Use short labels close to each line. The table below provides the minimum set of interfaces your first architecture should show.

Source	Destination	Interface content	Why it exists
Operator or user interface	Raspberry Pi software	Start, stop, mode selection, task request	Defines the intended task
Raspberry Pi software	Microcontroller control	Target pose, wheel-speed request, operating mode	Converts mission decisions into low-level requests
Microcontroller control	Raspberry Pi software	Telemetry, state, calibration status, faults	Allows logging, diagnosis, and supervised operation
Sensors	Microcontroller control	Position, speed, limit, distance, voltage, current measurements	Closes feedback loops and enables safety checks
Microcontroller control	Actuator interface	PWM, direction, enable, or servo command signals	Commands physical motion
Electrical power system	Controllers, sensors, and actuators	Protected power rails and reference ground	Supplies energy at suitable voltage and current
Actuators	Mechanical system	Joint torque, gripper force, wheel rotation	Produces the useful physical action
Mechanical system and environment	Sensors	Motion, contact, distance, load-related physical state	Provides conditions that sensors measure
Arm base and payload	Mobile chassis	Structural loads and moments	Captures the fact that arm motion affects vehicle stability

Notice that one actuator has at least three kinds of connections:

1. A control command.
2. Electrical power.
3. A mechanical output.

For example, the left drive motor receives a command from the microcontroller, high-current power from the motor rail through its driver, and applies torque to the left wheel. Its encoder provides a measured wheel state back to the controller. If one of these connections is absent from the diagram, the model is incomplete.

---

Create version 0.1 of your block diagram

Create this in your engineering build log on paper, in a notes app, or with any diagram tool you already use. Keep it to one readable page.

Layout

1. Put the mechanical subsystem in the center or right side of the page, since it is the physical plant.
2. Place the sensing subsystem around the mechanical system, with sensor blocks near the phenomena they measure.
3. Place the control subsystem between measurements and actuator commands.
4. Put the software subsystem above the controller, representing supervisory decisions and logging.
5. Place the electrical subsystem below the other blocks, supplying every powered subsystem.
6. Add the external world: operator, floor, object, and obstacles. The robot has no purpose without an environment.

Use visually distinct line styles or colors if that helps, but use labels as well:

• Power: battery and regulated rails
• Command/data: serial messages, PWM, encoder data, sensor readings
• Mechanical: torque, rotation, load path, contact
• Human/task interaction: start/stop command, status, placed object

Avoid trying to make the diagram aesthetically perfect. Its purpose is to reveal missing assumptions.

What to leave out

Do not include these yet:

• GPIO pin numbers
• Connector part numbers
• Exact wire gauges
• Final battery voltage or fuse rating
• Detailed control gains
• Detailed CAD dimensions
• Exact serial-message syntax

Those are important, but they belong in later design artifacts. The next lesson will refine the physical concept; later lessons will create the interface table, power design, CAD models, and control software.

Review checklist

Before marking the diagram complete, check that it answers all of the following:

• The arm, gripper, chassis, wheels, and external load are shown in the mechanical domain.
• The battery and power distribution are separate from the microcontroller’s command signals.
• Every actuator has a power connection, a control connection, and a mechanical effect.
• Sensors provide measurements back to the control system.
• The Pi’s supervisory role is separated from the microcontroller’s time-critical role.
• A safety or fault path exists: emergency stop, limit violation, low battery, communication timeout, or detected stall must be able to inhibit motion.
• The arm’s structural connection to the base is shown, since the extended arm can affect base stability.
• Unresolved design choices are visibly marked as assumptions or TBD items.

At the bottom of the page, add a small revision record:

Revision	Date	Change	Reason
0.1	Today	Initial functional architecture	Created from initial project requirements

This gives you a baseline for later changes. For example, adding wheel encoders, changing actuators, or splitting power rails should update the diagram rather than becoming undocumented modifications.

---

Wrap-up

You now have the conceptual structure of the robot:

• The mechanical domain performs the physical task.
• The electrical domain supplies and safely distributes energy.
• The sensing domain observes physical state.
• The control domain turns targets and measurements into safe real-time actuator commands.
• The software domain supervises the mission, configuration, and diagnostics.
• A complete functional block diagram shows power, information, and mechanical interfaces without becoming a detailed wiring schematic.

Next, you will use the requirements and this architecture to sketch a provisional arm joint arrangement, end effector, and differential-drive base concept.