Unmanned Ground Vehicle (UGV)

 

This project was inspired by a curiosity for a very popular technology: Simultaneous Localization and Mapping (SLAM).  From automated robotic home vacuum systems to show ride vehicles at world-class theme parks, this technology cleverly intersects mechanics, electronics, and software to automate a platform’s journey through space.  I’m drawn to this project because it challenges me to approach a design from the perspective of multiple engineering disciplines and work toward one technical goal: SLAM.

 

 

Tech Stack

 

 

Budget

 

 

Technical Drawings

 

Mobile Platform Base

·         The platform bases are designed like a pegboard to make the UGV more modular, and they’re manufactured from acrylic using a laser cutter

o   This design facilitates designing and fastening peripheral mounts/attachments and flexibly position them as needed

o   The platform bases are manufactured from acrylic for the material’s low conductivity and ability to withstand heat, thereby reducing unintended influence on electronic components

o   Laser cutting the design onto an acrylic sheet allowed for consistent and accurate cuts

·         Laser Cut at Maker FX Maker Space on Boss Laser LS-1630

 

Raspberry Pi 4 Model B Mounting Block

·         3D Printed at Orange County Library – Melrose Center Maker Space on Bambu Lab A1 printer

 

Breadboard Mounting Plate

·         Breadboard dimensions: 3.25” X 2.125”

·         Breadboard comes with adhesive sheet to adhere to mounting plate

·         Laser Cut at Maker FX Maker Space on Boss Laser LS-1630

 

6V Battery Mounting Block

·         Rev A:

o   Fastener head clearance too tight

o   It is difficult to remove battery box from mounting block without flipping upside down

§  Needs space to fully grip battery box for removal from mounting block

·         3D Printed at Orange County Library – Melrose Center Maker Space on Bambu Lab A1 printer

 

DC ‘TT’ Motor

·         DC ‘TT’ Motor assembly file from GrabCAD, as indicated in drawing notes

·         Technical drawing by me

 

DC ‘TT’ Motor Mounting Block

·         Only the right drive motor mount was modeled, so the model was mirrored in the Bambu Studio slicing software when 3D printed to produce the left drive motor mount

·         3D Printed at Orange County Library – Melrose Center Maker Space on Bambu Lab A1 printer

 

L298N Mounting Plate

·         Laser Cut at Maker FX Maker Space on Boss Laser LS-1630

 

SG90 Servo Motor Mounting Block

·         Rev A

o   The mounting block is designed to fasten to the servo motor via two M2.5x5+6mm standoffs, so the print will be 5mm too short for a motor to sit directly in the saddle without standoffs

o   3D Printed at Orange County Library – Melrose Center Maker Space on Bambu Lab A1 printer

·         Rev B

o   Added missing width dimension in drawing

o   Taller standoff supports clearing fastener heads and motor wires’ bend radius

o   Narrower standoff supports improving servo fit in mount saddle

o   Standoff support thread holes’ diameter increased from 2.1mm to 2.2mm

o   Use M2x5+3mm standoffs to fasten servo motor to mount

o   3D Printed at Orange County Library – Melrose Center Maker Space on Bambu Lab A1 printer

·         Rev C

o   Corrected over-toleranced dimensions from Rev B

o   New design allows SG90 servo motor to sit in the mount saddle slot

o   SG90 servo motor fastens to the mount with M2 screws and nuts

o   Replaced fastener holes with thru holes to allow M2 fasteners to clear the holes and fasten with the nut

o   Internal edges rounded to reduce stress points when bearing load

o   3D Printed on Bambu P1S printer

 

 

ESP32 UWB DW1000 Housing

·         Made of clear acrylic so that pin labels and LCD (if present) are visible

·         2 housing plates per module:

o   Top (side with LCD, if present)

§  M2.5 x 10mm standoffs

o   Bottom (side with pinout labels), OPTIONAL

§  M2.5 x 15mm standoffs

·         Laser Cut at Maker FX Maker Space on Boss Laser LS-1630

 

 

Pictures of Manufactured and Assembled UGV

 

 

Mechanical

 

·         More technical information about motors can be found in my Motors Tech Notebook.

·         Code for driving motors with Python on the Raspberry Pi can be found in my github:

o   Raspberry Pi Motor Hat Driver

o   L298N Motor Driver Demo

o   SG90 Servo Motors

 

DC Gear Box Motor – DC ‘TT’ Motor

 

Technical Specifications

 

 

 

SG90 Micro Servo Motor

 

Technical Specifications

 

 

Electrical / Electronics

 

Raspberry Pi 4 Model B

 

 

L298N Motor Driver

·         The DC motors are rated for a voltage that exceeds what a microcontroller outputs

·         A motor driver provides the motors with an external power source that meets the motor’s specifications but receives logic signals from the connected microcontroller

·         The L298N microcontroller has H-bridge and Pulse Width Modulation (PWM) capability, controlling the motor’s output effort (i.e. rotation speed) and direction

 

 

·         The diagram below shows how the L298N motor driver is connected to the DC motors and the microcontroller logic pins

 

·         Code for driving motors on the L298N motor driver with Python on the Raspberry Pi can be found in my github:

o   L298N Motor Driver Demo

 

 

Ultra Wideband (UWB)

·         Ultra-Wideband (UWB) is a high-precision, short-range wireless radio technology used for accurate, low-power device localization at short distances

o   Devices send multiple short radio pulses over a wide frequency band and measure the time it takes for signals to travel between one another (Time of Flight, ToF) to determine their distance and position

o   Large bandwidth provides high data rates and stability to reduce interference while enabling precise positioning

§  Ideal for indoor positioning and navigation

 

 

·         These modules can communicate with the microcontroller using Universal Asynchronous Receiver/Transmitter (UART) protocol, an asynchronous serial communication for short-distance wired communication

o   See Communication Protocols: UART in Tech Notebook

 

ESP32 UWB Pro with DW1000

 

 

 

The ESP32 documentation defines the pinout for the chip that’s soldered on Makerfab’s board.  The board pins map to the ESP32 chip pins with the corresponding name, as defined in the documentation.

 

 

 

·         UWB DW100 Module Calibration: Distance readings between tag and anchor modules require proper calibration to achieve accurate measurements. 

 

o   Each module has an antenna delay value that accounts for signal propagation through the PCB trace and antenna

§  If the antenna delay is wrong, the distance measurements will consistently be off by a fixed amount

o   Antenna Delay is the value that must be tuned for distance measurement calibration

 

o   The procedure below details how I calibrated the UWB modules:

 

§  Place the tag and anchor modules exactly 1m from each other

§  Confirm the following:

·         Baud rate is the same for the anchor and tag

·         Antenna delay is the same for the anchor and tag

 

§  Record the antenna delay value for 4-6 iterations:

·         Collect distance readings for at least 50 cycles from the anchor module using the Arduino Open Serial Monitor

o   Confirm that the baud rate in the serial monitor matches the baud rate oof the anchor and tag

·         Calculate the average distance reading from the anchor module data

·         Knowing that the anchor and tag are placed 1m from each other, calculate the error in the distance measurement and the known distance between modules

 

·         Higher antenna delay means that more of the round-trip time was internal delay instead of free-space travel, so some time is subtracted from the ToF calculation

 

Antenna Delay Tuning Intuition

 

 

·         Each unit of antenna delay corresponds to approximately 1 DW1000 clock tick, which equals 4.7mm of distance

·         Divide the error by the distance per unit antenna delay to calculate the adjustment

 

·         Add the adjustment to the current antenna delay to calculate the new antenna delay value

 

·         Use this new antenna delay value in the next iteration

·         Update the antenna delay value in the anchor and tag code before starting the next iteration

 

 

o   Below is the data I collected from mathematically tuning the UWB modules, tabulated and plotted:

 

 

 

§  The data indicates a linear relationship between the antenna delay value and the measurement error

§  I used the data from the experiment above to perform a linear regression and define the equation of a trendline.  Once defined, I calculated the antenna delay that should yield 0 error and repeated the error and adjustment calculations.

§  Using the tuning intuition defined above, I manually nudged the antenna delay value until the measurement error was sufficiently minimized.

 

o   Below is the data I collected from manually tuning the UWB modules, tabulated and plotted:

 

 

 

 

·         UWB DW1000 Module Data Acquisition via UART:

o   I wrote some code that collected data from the UWB tag over UART but noticed that the data acquisition rate would lag over time

o   I confirmed that data was not being stored in a data structure that was growing indefinitely

o   The problem persisted, so I investigated further and noticed that data from prior transactions had accumulated in the buffer

o   Buffer: A temporary storage area in memory that holds data while it’s being transferred between two entities operating at different speeds and/or schedules

o   Since UART uses a FIFO buffer to store incoming bytes, the most recent data is queued behind data from previous cycles

§  UART buffers hold incoming bytes from the peripheral until software is ready to read them.

·         Peripheral sends the data on its own clock

·         Acquisition device reads data when it’s ready

·         Buffer bridges the gap between the peripheral and data acquisition device

o   The buffer had to be cleared before each acquisition cycle so that the most recent data wouldn’t lag behind residual data from previous cycles

§  This ensures that the acquisition captures a current peripheral output

 

·         UWB DW1000 Module Data Filtering:

o   It’s common for data from a peripheral to be noisy

o   There are various reasons why a signal would be noisy, including but limited to:

§  Electromagnetic Interference (EMI): Nearby motors, power lines, switching circuits induces voltages onto signal lines

§  Cable Length: Longer cables can pick up interference, causing signal degradation

§  Voltage Ripples: Unclean power supply introduces fluctuations that ride on top of the signal

§  Clock Jitter: Variations in the clock signal cause sampling to occur at misaligned moments

§  Cross-Talk: Adjacent signal lines on PCB couple into each other

§  Vibrations: Intermittent contact between connectors or stress on cables

o   Since the peripheral data can be noisy for various reasons, but accurate localization requires reliable distance measurements between tags and anchors, I implemented a low-pass filter that reduces high-frequency signals above a threshold called the cutoff frequency.

 

Raw Data Acquisition vs. Data Filter Implementation

 

Algorithms

 

·         All algorithms implemented in this UGV are documented in my Portfolio!

o   Localization Algorithm Write-Up: Trilateration

§  This UGV uses a trilateration algorithm to locate itself in a known environment

§  Ultra-Wide Band (UWB) modules are mounted in the system to measure the distances needed for the trilateration algorithm

·         3 anchor modules are stationary in the local frame (i.e. the environment) that the UGV is navigating (denoted by the ★ below)

·         1 tag module is mounted on the UGV that navigates the environment

§  Anchor modules’ known location coordinates in the local frame are centers of the range circles

§  The measured Euclidean distance between the UGV tag module and each fixed anchor module are the range circles’ radii

§  The intersection point of all 3 range circles is the UGV’s location coordinate in the local frame

 

 

o   Path Planning Algorithm Write-Up: A* Path Planning

§  This UGV uses information about its environment’s layout to plan its path trajectory using the A* path planning algorithm

§  The A* path planning algorithm mathematically determines the most efficient trajectory between two points, avoiding known obstacles like walls and stationary objects

 

 

 

Software

 

·         All code implemented in this UGV is publicly available on my github!

o   Localization: Trilateration Algorithm

o   Path Planning: A* Path Planning Algorithm

o   Raspberry Pi Motor Hat Driver

o   L298N Motor Driver Demo

o   SG90 Servo Motors

o   ESP32 UWB Pro Demo

Helpful Links

·         Ultra Wideband Sensors

·         Makerfabs ESP32 UWB with DW1000

·         ESP32-WROVER Documentation

·         Makerfavs ESP32 UWB & Display source code - github

·         Getting Started with ESP32 UWB Board - techiesms