Robotics: A Complete Guide to Engineering Real Robots

The simplest way to approach robotics vs automation is to separate the machine from the process. Automation can exist without a robot: a temperature controller, scheduled data transfer or conveyor sequence can operate automatically. Robotics focuses on physical machines with sensing, computation and actuation, whether their actions are autonomous, supervised or remotely controlled. An industrial arm following a taught trajectory is a robot even when it makes few independent decisions. Conversely, a factory process controlled by programmable logic controllers may be highly automated without containing any robotic arm or mobile platform. Autonomy is therefore a capability, not a synonym for robotics.

In practice, automation engineering and robotics engineering meet at system boundaries. A robot may load a machine, but the surrounding installation must also coordinate doors, fixtures, conveyors, interlocks and production signals. Successful integration requires agreement about what each component can do and which conditions permit movement. For the mobile delivery example, the robot handles navigation, while a workstation controller might confirm that its receiving area is available. The overall process needs both capabilities. This distinction prevents a common design mistake: treating a capable robot as a complete solution when the surrounding workflow, exception handling and protective measures remain unfinished or undefined.

Sensors convert physical quantities into measurements that software can interpret. Wheel encoders report shaft rotation; inertial measurement units measure angular velocity and specific force; cameras capture images; and lidar measures distances using light. None supplies perfect knowledge. Measurements contain noise, calibration errors and sometimes delays or missing data. Engineers therefore choose sensors according to the task, expected environment and failure consequences. Our delivery robot uses wheel encoders for short-term motion estimates, an inertial sensor to support orientation estimation, lidar for surrounding geometry and a camera to recognise a workstation marker. Each sensor contributes different information rather than simply duplicating another.

Actuators turn commands into physical movement. Electric motors are common, while pneumatic and hydraulic systems suit other operating requirements. Selecting an actuator involves torque, speed, duty cycle, transmission losses and thermal limits, not just whether it can move an unloaded mechanism. For the delivery robot, geared wheel motors must accelerate the combined platform and payload without exceeding traction or electrical limits. Motor drivers regulate electrical power, while brakes may be necessary to manage stopping or holding safely. Mechanical design matters equally: wheel alignment, structural stiffness and cable routing can determine whether otherwise correct software produces repeatable motion under realistic operating conditions.

Robot kinematics describes motion through geometry, without initially considering the forces that cause it. Forward kinematics calculates a tool or body pose from joint positions. Inverse kinematics works backwards from a desired pose to possible joint configurations. A robot arm may have several valid configurations for the same tool position, or none if the target lies outside its reachable workspace. Some configurations approach singularities, where certain motions become difficult or require large joint velocities. Engineers must therefore check joint limits, collisions and numerical behaviour rather than assume that every position on a screen corresponds to a feasible physical movement in practice.

For a differential-drive delivery robot, kinematics links wheel speeds to forward velocity and turning rate. If the wheel radius is r, wheel separation is L, and wheel angular speeds are ωR and ωL, then forward speed is r(ωR + ωL)/2 and yaw rate is r(ωR − ωL)/L. With 0.10 m wheels, 0.50 m separation and wheel speeds of 4 and 2 radians per second, ideal forward speed is 0.30 m/s and yaw rate is 0.40 rad/s. These calculations assume rolling without lateral slip. Actual motion requires feedback because wheel deformation, floor conditions and imperfect dimensions can invalidate the ideal geometric model.

An open-loop command tells an actuator what to do without checking the result. A closed-loop controller compares a measured state with a target and adjusts its output to reduce the difference. Control systems often form layers: a motor drive regulates current, a wheel controller regulates speed, and a navigation controller regulates the robot’s path. Proportional–integral–derivative control is a common approach, although not every application needs all three terms. Tuning must account for sampling intervals, actuator limits and mechanical behaviour. Excessive gains can produce oscillation, while weak correction can leave a robot slow to respond or unable to reject disturbances effectively.

In the worked example, a wheel-speed target of 4 radians per second does not guarantee that speed when the payload increases. Encoder feedback reveals the difference, allowing the controller to request more drive effort within permitted limits. Integral action can remove persistent offset, but actuator saturation requires measures such as anti-windup to avoid excessive accumulated correction. At the navigation level, the robot continually updates steering commands as its estimated pose changes. Delays and irregular update timing can degrade performance, so controller execution should be predictable. High-level planning software should not be assumed suitable for time-critical motor control without appropriate architectural support.

Computer vision extracts useful information from images, such as object locations, surface features or recognised markers. For robotics, a detection usually needs more context before it can guide motion. A bounding box identifies an image region, not automatically a physical position in metres. Estimating geometry may require calibrated cameras, known object dimensions, stereo imaging or a depth sensor. Camera intrinsics describe projection and lens distortion, while extrinsic calibration relates the camera to the robot or another reference frame. Lighting, reflections, motion blur and occlusion all affect reliability. A perception pipeline should expose uncertainty or invalid results rather than silently present every detection as trustworthy.

Our robot approaches a workstation carrying a visual marker of known dimensions. A calibrated camera can estimate the marker’s pose, which software transforms into the robot’s coordinate frame using the camera mounting geometry. That estimate supports final alignment, but it should be checked for plausibility and stability across observations. If the marker is obscured or glare makes recognition unreliable, the robot should stop or follow a defined recovery procedure. Lidar and wheel measurements remain useful for surrounding geometry and movement estimation. Combining sensors can reduce dependence on one measurement source, but it cannot automatically eliminate shared calibration errors or environmental limitations.

ROS 2 provides software libraries, tools and communication mechanisms for building robot applications. Despite its name, it is not a replacement for the underlying operating system, nor does installing it create autonomy. Developers divide functionality into nodes, such as camera drivers, localisation, planning and control interfaces. Topics carry ongoing message streams; services support request-and-response interactions; and actions suit longer-running operations with feedback and cancellation. Quality-of-service settings help define communication behaviour, including reliability and retained message history. Those settings must match the application: processing stale sensor data can be less useful than receiving the most recent measurement promptly during navigation through a changing environment.

Coordinate frames and timestamps are especially important in ROS 2 integrations. The tf2 library manages relationships between frames, allowing observations from a camera or lidar to be interpreted relative to the robot and map. Localisation estimates the robot’s pose, while mapping builds an environmental representation; simultaneous localisation and mapping, or SLAM, combines these problems. A navigation framework such as Nav2 can integrate planning, local control and recovery behaviours for mobile robots. However, configuration, sensor integration and testing remain engineering responsibilities. ROS 2 does not itself guarantee real-time execution, functional safety or dependable behaviour when a network link, process or sensor fails.

Start with a bounded requirement: carry a secured payload from a loading point to a marked workstation on a known indoor floor. Define payload limits, operating areas, floor conditions and acceptable docking error before selecting hardware. For an initial development exercise, use a controlled test area rather than an occupied workspace. The robot first checks that required sensors and motor interfaces are available. It then estimates its pose within a map and plans a collision-free route that accounts for its footprint and suitable clearance. The route is a geometric proposal, not a guarantee: the controller must still produce feasible velocities throughout execution.

During travel, localisation combines available measurements to update the pose estimate, while obstacle observations inform local navigation. The controller converts desired body motion into wheel-speed targets, and encoder-based loops track them. Near the workstation, validated marker observations support the transition from general navigation to precise alignment. Arrival should depend on measured position and motion state, not merely elapsed time. A workstation acknowledgement can then confirm delivery readiness. If localisation becomes unreliable, the camera loses its target or an obstacle blocks the route, the system follows explicit stop, wait or recovery rules. Task completion requires verified conditions, not just a successfully issued command.

Testing should progress from individual components to integrated behaviours. Verify sensor units, signs, timestamps and calibration before tuning controllers. Check wheel-direction conventions and frame transforms before attempting autonomous navigation. Simulation helps expose logic errors and exercise scenarios, but simulated friction, contact and sensor noise rarely match reality exactly. Physical tests should begin at low energy under controlled conditions, with suitable protective measures. Assess stopping behaviour, lost communication, sensor dropout, blocked routes and restart handling as well as successful operation. Emergency stops and protective functions require application-specific risk assessment and appropriate implementation; ordinary navigation software is not a substitute for a safety-related control system.

Useful evaluation asks why failures occur, not simply whether a demonstration succeeds once. Record relevant sensor data, commands, estimated poses and fault events so results can be reproduced and compared. Examine tracking error, docking repeatability, recovery behaviour and performance across changing loads or lighting, using requirements defined for the application. Improve one subsystem at a time where possible. For structured study of these connected topics, explore Erudex’s [Robotics and Automation Engineering](/courses/robotics-and-automation) course and [practice tests](/practice). A course certificate can document learning achievement, but it should not be confused with evidence that a robot or installation satisfies applicable safety requirements in operation.