Robots and automation

Why this matters

UAT 314 and UAT 202 gave an overview of automation, PLCs, a two-joint arm and a two-wheeled robot. This is a practical course that builds robot systems working with drones. The case used throughout is a solar farm with an unmanned ground vehicle (UGV) that drives along panel rows, finds hotspots on panels with a thermal camera, and carries a drone to launch for high-angle surveys. The drone knowledge base’s unit on Robotics & Autonomous Systems covers robot operating systems and coordinating several systems, and its unit on industrial automation and PLCs explains actuators and control logic. The first module starts with what every robot must get right before anything else: knowing what is where, in which frame.

Parts of a mobile robot

The textbook by Siegwart et al. divides a mobile robot’s work into perception (sensors), localisation, planning and motion control (actuators). The solar-farm UGV has wheel encoders, an IMU, GNSS, a thermal camera and a LiDAR, and is driven by two DC motors. Its controller is an on-board computer running ROS 2 that talks to the control centre over a wireless network. Each sensor’s data is in its own frame, so it must be transformed into a common frame before being combined.

Homogeneous transforms and the frame tree

The position and orientation of one frame relative to another is written as a 3×3 matrix in 2D (4×4 in 3D) that combines rotation and translation. Frames are chained by multiplying matrices in order from the larger frame to the smaller one. REP 103 specifies SI units and body axes with x forward, y left and z up. The ROS tf library (Foote, 2013) stores frame relationships as a tree and computes the transforms automatically.

import numpy as np

def se2(x, y, deg):
    t = np.radians(deg)
    return np.array([[np.cos(t), -np.sin(t), x],
                     [np.sin(t),  np.cos(t), y],
                     [0, 0, 1]])

T_map_base = se2(12.0, 5.0, 30)       # robot on the map, heading 30°
T_base_cam = se2(0.20, -0.25, -90)    # camera on the right side, facing right
p_cam = np.array([4.0, 0.5, 1])       # hotspot seen by the camera

p_map = T_map_base @ T_base_cam @ p_cam
print(f"hotspot on map: ({p_map[0]:.2f}, {p_map[1]:.2f}) m")

wrong = T_base_cam @ T_map_base @ p_cam
print(f"wrong multiplication order: ({wrong[0]:.2f}, {wrong[1]:.2f}) m")

goal = np.linalg.inv(T_map_base) @ np.array([20.0, 9.0, 1])
print(f"goal in robot frame: x = {goal[0]:.2f} m, y = {goal[1]:.2f} m")

hotspot on map: (14.73, 1.67) m
wrong multiplication order: (7.63, -15.46) m
goal in robot frame: x = 8.93 m, y = -0.54 m

map, odom and base_link

REP 105 defines three main frames for mobile robots. base_link is attached to the robot. odom is a frame in which the position changes continuously without jumps but drifts with distance, which suits short-term control. map is a frame in which the position does not drift over the long term but may jump when localisation corrects it, for example when GNSS arrives or the robot matches the map. Separating frames this way keeps the wheel controller from jerking when the map position is corrected.

Odometry and systematic error

Odometry estimates position from wheel revolutions. A differential-drive robot turns when its two wheels travel different distances, $\Delta \theta =(d_R-d_L)/b$. If the wheel radius used by the software differs from the real one, the error accumulates in the same direction every time. Borenstein and Feng (1996) identify two main causes, unequal wheel diameters and uncertainty in the wheel separation, and propose the UMBmark test, in which the robot drives a square path both clockwise and counter-clockwise to separate these two causes.

import numpy as np

b = 0.50            # wheel separation m
r_nom = 0.100       # wheel radius used by software m
r_right = 0.1001    # actual right wheel 0.1% larger
dist = 50.0         # distance software believes is straight m

rev = dist / (2 * np.pi * r_nom)          # same revolutions on both wheels
d_left = rev * 2 * np.pi * r_nom
d_right = rev * 2 * np.pi * r_right
dtheta = (d_right - d_left) / b
R = b * (d_right + d_left) / (2 * (d_right - d_left))
lateral = R * (1 - np.cos(dtheta))
print(f"actual heading change {np.degrees(dtheta):.2f} deg")
print(f"actual turn radius {R:.0f} m")
print(f"sideways offset at the end {lateral:.2f} m")

actual heading change 5.73 deg
actual turn radius 500 m
sideways offset at the end 2.50 m

Module lab

Common mistakes

Summary

• A mobile robot combines perception, localisation, planning and control
• Homogeneous transforms combine rotation and translation, and frames chain by multiplying in order
• REP 105 separates map, odom and base_link by continuity and drift
• Odometry accumulates systematic error and needs calibration and other sources to correct it

Check your understanding

1. Following REP 103, which way does a robot’s y axis point?
2. Which frame is continuous but drifts, and which does not drift but may jump?
3. The right wheel travels 10.02 m and the left 10.00 m, with a wheel separation of 0.5 m. How many radians does the robot turn?
4. If a goal in the robot frame has negative y, on which side of the robot is it?
5. Why does the UMBmark test drive both clockwise and counter-clockwise?