Cost-Optimized Magnetic-Guided AGV Using the Naviq MTS160 and EQSP32

Design Objective

This application note describes the architecture and implementation of a magnetic-guided automated guided vehicle built from a minimal set of components. The design target is industrially relevant performance: reliable track-following, autonomous fork selection, precision docking at a charging station, and remote supervisory control, without map-based localization, external infrastructure, or high-cost sensors.

Magnetic guidance is the correct technology choice when the vehicle operates on a fixed or semi-fixed path in an environment where floor markings are acceptable. It eliminates the computational overhead and integration complexity of laser SLAM or visual odometry, produces deterministic behavior, and scales predictably. The trade-off is path flexibility: changes require physical modification of the floor tape. For the large class of AGV applications where route changes are infrequent, this is not a practical limitation.

Guidance Principle

Track following is performed by a single Naviq MTS160 magnetic guide sensor, mounted 20-30 mm above the floor. The sensor measures three quantities on every cycle:

• Track presence: a boolean detect signal that acts as the motor enable condition. If the tape is not detected, all motor outputs are inhibited immediately. The vehicle stops rather than runs off track.
• Lateral offset: the signed displacement of the vehicle centerline from the tape center, in millimeters. This drives a proportional correction term that steers the vehicle back toward the tape.
• Angular misalignment: the angle between the vehicle heading and the tape direction. Combined with known vehicle geometry (wheel diameter, wheel spacing, sensor mounting offset), this is used in a predictive steering block to compute the turning radius needed to follow curves smoothly.

The outputs of the predictive steering and the lateral offset correction are summed and fed to a differential drive mixer, which converts the scalar steering demand into independent left and right wheel speed commands. This two-term structure gives the controller both path-following stiffness (from the lateral offset term) and smooth curve entry (from the predictive term), without requiring any ahead-of-time knowledge of the track geometry.

Marker-Based Routing

All routing decisions are encoded directly onto the floor using discrete magnetic markers. No map, no localization system, and no external coordination server are required. The marker vocabulary covers three functional types:

Navicode markers are sequences of left and right markers that encode an unsigned integer up to 16 bits. Value 1 is reserved as the docking approach trigger in this application. The scheme is field-reconfigurable: changing a route requires only repositioning or adding markers on the floor, with no firmware modification.

Point markers use a different magnetic profile (disk geometry rather than tape) that the MTS160 recognizes as a distinct signal type, providing longitudinal position resolution that the continuous tape cannot offer. This is what allows repeatable stops at the charger contact without relying on odometry accumulation.

The four marker types above are the complete vocabulary of this navigation system. The following two diagrams show what that vocabulary can produce when combined on a real track layout.

System Architecture

The three primary subsystems communicate over a 500 kbit/s CAN bus backbone:

• Naviq MTS160: continuously transmits track position, track angle, track-detect, and marker type as CAN frames. Output is available every sensor cycle; the EQSP32 processes each frame as it arrives.
• EQSP32: the central control unit. Runs the guidance algorithm, state machine, and safety logic. Computes left and right wheel speed setpoints and transmits them to the motor controller over CAN. Also receives odometry feedback from the motor controller on the same bus.
• Dual-channel motor controller (Roboteq SBLG2360): closes the inner speed loops using encoder feedback. Returns signed odometry in encoder counts per period. The inner loop runs on the motor controller; the EQSP32 operates as the outer guidance loop with no direct PWM or current control responsibility.

Wi-Fi connectivity on the EQSP32 carries MQTT telemetry and supervisory commands. Loss of Wi-Fi does not interrupt the guidance loop or safety functions. The CAN bus continues operating and the vehicle follows its track regardless of wireless state.

Power and Wiring

The power architecture uses two rails:

• 48 V lithium battery: connected directly to the motor controller traction input. Not regulated or converted for any control electronics.
• 24 V rail: derived from the 48 V battery via a DC-DC converter. Powers the EQSP32 and the MTS160 sensor.

All real-time data, including sensor output, motor commands, and encoder feedback, travels on the CAN bus. A second MTS160 can be connected on the same bus for rear-facing guidance or reverse operation without additional wiring infrastructure.

Additional I/O used by the EQSP32:

• Run/Stop input: a discrete digital input connected to a physical pushbutton on the vehicle body. This input enables or inhibits motion independently of any wireless command. It cannot be overridden remotely.
• Battery voltage monitoring: a resistor divider on the 48 V rail connected to an analog input. Voltage is reported in telemetry and used to trigger low-battery warning states.
• Ultrasound obstacle sensor: trigger driven by a digital output; echo pulse returned to a digital input. The EQSP32 measures pulse width with microsecond resolution to compute obstacle distance using time-of-flight. No external timer or capture hardware is required. A single forward-facing sensor is used in this design, providing obstacle detection along the direction of travel in a controlled environment.
• Addressable RGB LED strips (×2): driven by a dedicated 800 kbit/s data signal generated directly by the EQSP32, without an external LED driver IC.
• Speaker: driven by a digital output for audible state indication.
• External Wi-Fi antenna: connected to the EQSP32 antenna port, mountable on the vehicle exterior for reliable range in reflective industrial environments.

Firmware Execution Model

The firmware is organized around a fixed-period main loop executing every 5 milliseconds, complemented by asynchronous CAN message processing.

// 5 ms periodic task
void controlLoop() {
    readAnalogInputs();          // battery voltage, etc.
    readDigitalInputs();         // run/stop button
    stateMachine();              // transitions on cmd / sensor / marker events
    guidanceAlgorithm();         // lateral + predictive steering -> wheel speeds
    applySpeedRamps();           // acceleration / deceleration limiting
    sendMotorCommands();         // CAN frame to motor controller
    updateLEDs();                // state-encoded visual indication
}

// CAN ISR -- runs on frame arrival, not on 5 ms boundary
void onCANReceive(CANFrame frame) {
    if (frame.id == MTS160_GUIDANCE_ID) updateGuidanceData(frame);
    if (frame.id == MOTOR_ODOMETRY_ID)  updateOdometry(frame);
}

// MQTT runs at a slower fixed interval, independent of control loop
void telemetryTask() { publishState(); processCommands(); }

CAN frames are processed immediately on arrival via interrupt. Guidance data is updated as soon as the sensor transmits, rather than waiting for the next 5 ms boundary. This reduces sensor-to-actuator latency to the CAN frame propagation time plus the interrupt service latency, both bounded and deterministic.

MQTT telemetry publication and command ingestion run at a separate, slower fixed interval and execute in a lower-priority task. They do not share execution time with the control loop and cannot introduce jitter into the 5 ms period.

State Machine

Vehicle behavior is governed by a finite state machine. Transitions are triggered by operator commands received over MQTT or the physical Run/Stop input, by sensor conditions (track loss, obstacle detected, battery low), or by marker detection events (Navicode, point marker).

Supervisory Software

The EQSP32 publishes telemetry over MQTT at a fixed interval, including:

• Vehicle state (Idle, Run, Approach, Docking, Charging, Fault)
• Tape lateral offset and track-detect status
• Traveled distance (derived from encoder odometry)
• Battery voltage
• Obstacle distance (from ultrasound sensor)

A Python-based supervisory application running on a PC consumes this telemetry to provide real-time position visualization. The track geometry is defined as a 1:1 scale DXF file representing the physical tape layout. A preprocessing script (nodefinder.py) parses the DXF, identifies path nodes (line endpoints, arc transitions, junctions), and produces a CSV of node coordinates. A separate file (travel_path.xlsx) defines the ordered node sequence for the specific route, allowing multiple routes to be defined against the same DXF without modifying the firmware.

The supervisor application loads both files, renders the track, and uses the traveled distance from MQTT telemetry to interpolate the vehicle position along the node sequence. The moving position indicator updates in real time. The supervisor also provides a basic control interface for issuing Run/Stop commands over MQTT.

Encoder odometry accumulates drift over time, particularly through wheel slip or tight curves. The marker system provides a natural mechanism for periodic resynchronisation: when the EQSP32 detects a Navicode or a point marker, its position along the route is known precisely. The controller can reset the odometry reference at each such event, bounding the drift to the distance between consecutive markers rather than allowing it to accumulate over the full route length. This keeps the supervisor's position estimate accurate without requiring any additional localisation hardware.

Importantly, the supervisor does not participate in real-time control. All guidance, safety, and motion decisions remain on the embedded controller. The PC application can be closed, disconnected, or restarted without affecting vehicle operation.

Vehicle in Operation

The following video shows the AGV running on a test track with fork selection and automatic docking at the charging station.

Watch the AGV in operation

Why the EQSP32 as the AGV Controller

The architecture described here can in principle be implemented on a range of platforms, including Linux single-board computers, industrial PCs, or conventional PLCs. In practice, the EQSP32 was selected because it resolves several constraints that are problematic on those alternatives:

Conclusion

A magnetic-guided AGV with fork selection, precision docking, obstacle detection, and MQTT supervisory interface can be implemented with three primary components: the Naviq MTS160 sensor, the EQSP32 controller, and a dual-channel motor controller on a CAN bus backbone. The design produces deterministic guidance and safety behavior without map-based localization, external infrastructure, or complex software frameworks.

The marker encoding scheme keeps routing logic on the floor rather than in firmware or a server, making route changes a physical operation rather than a software deployment. All safety-critical functions (track-loss inhibit, obstacle stop, low-battery state) are handled by the embedded controller and cannot be degraded by Wi-Fi outage or supervisory software failure.