FPGA-powered Autonomous Search and Rescue Vehicles





Introduction: FPGA-powered Autonomous Search and Rescue Vehicles

UPDATE2: check http://www.digilentdesigncontest.com/2015-eu-contest-entries.html for the complete source-code and documentation.

UPDATE1: added a new module - a 3-axis magnetometer (digital compass). See step 2 for details.

This project represents an application for the 11-th (2015) edition of Digilent’s Design Contest, and consists of two mobile platforms. The theory behind its operation is that one of the platform performs the “search” function, whilst the other the “rescue”, as described in detail at step 2.

The first platform incorporates the following modules:

  • One Nexys4DDR FPGA board
  • One LCD screen
  • One infrared (contactless) thermometer
  • Three ultrasonic sensors
  • One RF transmitter
  • One Dual DC motors driver
  • Four logic level converters
  • Two DC motors
  • Two rotary encoders
  • One step-up switching mode power supply
  • One step-down switching mode power supply
  • One battery holder for eight 1.5V AA (R6) size batteries

The second platform consists of:

  • One electronic speed controller (ESC)
  • One RF receiver and PWM driver module
  • One Dual DC motors driver
  • Two servomotors (which power a makeshift stretcher)
  • Two DC motors
  • One step-down switching mode power supply
  • One battery holder for eight 1.5V AA (R6) size batteries

Step 1: Parts

1. Nexys4DDR board

The Nexys4 DDR board is development platform based on the Xilinx XC7A100T-1CSG324C Artix-7 Field Programmable Gate Array (FPGA).

Artix-7 100T features include:

  • 15,850 logic slices, each with four 6-input LUTs and 8 flip-flops
  • 4,860 Kbits of fast block RAM
  • Six clock management tiles, each phase-locked loop (PLL)
  • 240 DSP slices
  • Internal clock speeds exceeding 450 MHz
  • On-chip analog-to-digital converter (XADC)

The Nexys4 DDR offers the following ports and peripherals:

  • 16 user switches
  • 16 user LEDs
  • Two 4-digit 7-segment displays
  • USB-UART Bridge
  • Two tri-color LEDs
  • Micro SD card connector
  • 12-bit VGA output
  • PWM audio output
  • PDM microphone
  • 3-axis accelerometer
  • Temperature sensor
  • 10/100 Ethernet PHY
  • 128MiB DDR2
  • Serial Flash
  • Four Pmod ports (with 8 I/Os per port)
  • Pmod for XADC signals (with 4 differential inputs)
  • USB-JTAG port (for FPGA programming and communication)
  • USB HID Host for mice, keyboards (and memory sticks for configuration).

This board is used as the main controller in the project, centralizing the input data (from the ultrasound modules, infrared sensor, and rotary encoders) and controlling the output peripherals (LCD, motor driver, and the second platform via RF).

2. Mobile platform

Both platform were acquired as a kit, and includes the main plastic support board, two DC motors-driven wheels (with fixing brackets), a third passive wheel, and a power button (it also had a four AA-size batteries holder, but it was not used). The multi-layer structure was obtained using ordinary PCB cooper boards (due to their availability, price, and added use as a ground plane).

3. LCD screen

The HannStar Display HSD043I9W1-A is a color active matrix thin film transistor (TFT) liquid crystal display (LCD). This module is composed of a TFT LCD panel, a driving circuit and a back light system. This TFT LCD has a 4.3 (16:9) inch diagonally measured active display area with WQVGA (480 horizontal by 272 vertical pixel) resolution. RGB data is inputted via parallel 24-bit (8-bit per colour) and sync (control) signals can be either via Horizontal Sync/Vertical Sync (as used in the VGA interface), or using DataEnable/DataClock (where DataEnable is high when the horizontal and vertical display counters are in the active area, with the DataClock at 10MHz). It was salvaged from a defective GPS navigator (as noticed by its branded plastic frame), and because it had a fairly inaccessible 30-pin 0.5mm pitch flat flex cable, an adaptor board had to be built to allow the use of a more comfortable 2.54mm pitch header as a means of connection to the FPGA board.

4. Infrared thermometer

This module was also salvaged from a household-usage ear thermometer whose display cracked. The lack of any data interface documentation, combined with the chip-on-board with no markings, resulted in a need of manual protocol decoding. Thus, the following data may not be unique, nor the most efficient way to acquire temperature data, but it seems to be stable enough for this project. Through the on-board header (with the pins marked as “V D C G A”) the onboard microcontroller/ASIC seems to output a SPI-like data, with the following pinout:

  • V = 3V3 VCC,
  • D = serial data,
  • C = serial clock,
  • G = ground,
  • A = “Action”/Slave Select (tied to the thermometer’s “Measure” button).

Additionally, a fifth pin had to be soldered (as explained below) to the “Menu” button. Both this button and the “Measure” one are active low (when pressed, they pull the signal to ground).

The way the thermometer appears to work is the following:

- The device is pulled out of sleep mode by pulling “Menu” down, entering the ear measuring mode (this mode implies a very strict temperature range, 34 to 42 degrees Celsius, and a 2-second warm-up time, thus not suitable for continuous operation),

- To transit to room temperature measurement mode, both “Menu” and “Measure” have to be pulled down for a second, then released,

- Now, each time the “Measure” signal is low, ambient temperature is measured (-20 to +80 degrees Celsius), and outputted via the “D” pin, in sync with the device’s internally generated clock available on the “C” pin,

- To obtain a continuous reading, the “Measure” signal is pulled low then high at a rate of 5Hz, 50% duty cycle (tests with higher frequency and/or lower duty cycle percent proved too fast for the device’s internal button debouncing subcomponent, reading the input as a continuous press, which results in a lack of data output). After the measurement is complete, the serial data outputted is read at the clock’s falling-edge.

Each measurement cycle outputs a 40-bit serial data string, composed of the following 8-bit words:

0x5B t1t2 t3t4 checksum 0x0D

Where the 4-bit words t1, t2, t3 and t4, when converted from hex to char results in t1=tens of degrees, t2=degrees, t3=1/10 degrees, t4=1/100 degrees Celsius. Checksum is the binary sum of the first 24 bits, and 0x5B and 0x0D represents the start and ending of the data stream.

5. Ultrasonic sensor

The HC-SR04 Ultrasonic ranging module provides 2cm - 400cm non-contact measurement function, with accuracy up to 3mm. The modules includes ultrasonic transmitter, receiver and control circuit. To measure distance, the following protocol had to be implemented: “Trigger” pin is pulled high for 10us (the module sends eight 40 kHz), and after the module receives the pulses signal back, it pulls the “Echo” pin high for a set time of 1uS per 58 centimeters in measured distance.

6. RF Transmitter module

These 2.4GHz RF modules were scavenged from a remote-controlled, and follow standard 50Hz (and high time of 1 to 2 ms) PWM signals implemented in hobby-grade analog controlled motors and servomotors.

The transmitter part was cut-out from the remote control board, and traced only to three pins (3V3 VCC, GND, and DATA). The DATA pin’s protocol has been decoded, and appears to accept the following serial stream: each 20ms, a pulse train containing four high-level pulse (where each pulse corresponds to each channel on the receiver, with its duration equal with the addition of 400us to the source pulse duration), each separated

7. Dual DC motors driver

This dual bidirectional motor driver is based on the L298 Dual H-Bridge Motor Driver Integrated Circuit. The circuit allows the state and direction control of two motors of 5V to 35V, up to 2A each (25W total max). Logic is supplied at a 5V level, and includes a Enable, and two signals for motor drive polarity control (as depicted in its internal schematic). A 10Ohm, 5W power resistor limits the current sourced by the driver to about 1A, reducing the risk of pre-mature battery depletion.

8. Logic level converter

The JY-MCU is a 4-way bi-directional MOS-FET-based level converter. The low-level reference voltage is supplied by an internal 3V3 voltage regulator, which in turn is powered from the high-level reference voltage (in this case 5V).

9. Rotary Encoder

This component is a standard 24-steps per revolution passive rotary encoder, used to provide the number of full or partial rotation of the wheels, allowing a measurement and control of distance travelled on the ground by each wheel.

10. Step-up Switching mode power supply

Powered by an XLSemi XL6009 400kHz 60V 4A Boost DC-DC converter, this module supplies the required 19V voltage rail for the LCD’s LED backlight, converting from the 12V rail.

11. Step Down Switching mode power supply

Powered by an TI LM2596 150kHz 40V 3A Buck DC-DC converter, this module supplies the required 5V voltage rail for the Nexys4 board, ultrasound modules, motor driver logic and RF transmitter, converting from the 12V rail. It incorporates a 7-segment display, on which it shows the input or output voltage, or the output current (mode selectable via the button), allowing the user to also use it in constant-current mode (besides the usual constant-voltage).

12. Battery holder

This is a standard battery holder able to carry eight AA (R6) 1.5V alkaline batteries, supplying the 12V voltage rail required by the two DC-DC converters and the motor driver.

13. ESC

This is a standardized, hobby-level, microcontroller-powered, ESC (electronic speed controller) that convert two 50Hz PWM signals (correspondent to throttle and direction) into the six signals necessary for the motor driver. It allows us to interface the simple L298 H-bridge to the RF receiver.

14. RF Receiver

This receiver converts the signal received into four separate channels, implementing the 50Hz, 1 to 2ms high time PWM.

15. Servomotor

This PWM-commanded motor incorporates an analog feedback circuit in order to maintain its position even under load, and is 100% compatible and designed for the type of RF receiver/controller that is used in this project. It allow to modify the angle of the make-shift stretcher in order to pick-up the “victim”.

16. Step-down Switching mode power supply

Similar to the buck converter used on the other platform, it also uses the same LM2596 voltage regulator, but does not include a current/voltage display, nor current limiting capability.

NEW: 17. Magnetometer

In order to eliminate mechanical drift while the first platform moves forward or backward, and also enable precise measurement and control of angle of rotation while the platform turn left, right or 180 degrees, an HMC5883L 3-axis magnetometer (or digital compass) was integrated in the design. By measuring the magnetic field strength on the X and Y axis, and applying an arctan2() operation (also known as arctan(x/y)), a magnetic north heading can be calculated.

Step 2: Theory of Operation

The first platform (main platform) with all modules will autonomously traverse (the “search” phase) an area randomly riddled with obstacles in search of the target (“victim” – a hands warmer). Once the target has been found (using the IR thermometer), the most efficient/shortest/direct route back to the starting point will be calculated and then traversed by the second platform, without any sensory aid. Once it too will reach the target, it will pick-up the target, (the “rescue” phase).

See http://www.digilentdesigncontest.com/2015-eu-contest-entries.html for the complete source-code and documentation!



    • Clocks Contest

      Clocks Contest
    • Woodworking Contest

      Woodworking Contest
    • Casting Contest

      Casting Contest

    We have a be nice policy.
    Please be positive and constructive.




    Everything is fine, but what is the main application of the bot?

    Eğer yanlısı DC motor kontrol kodları ben mutlu olabilir misiniz mertdugan@gmail.com

    Eğer yanlısı DC motor kontrol kodları ben mutlu olabilir misiniz mertdugan@gmail.com

    Hi,nice robot where do you get all the parts?

    1 reply

    Hi, the parts I've used were bough each seperately or scanvenged/recovered from other devices/projects, and were not specifically designed for this project. For example, the LCD screen is from a GPS navigator, the RF transmitter/receiver from a R/C toy, and many other were bought as simple standalone modules (motor driver, ultrasound measurers, etc.).

    hi, nice work you have over here. I'm very impressed with your robot

    May I know how do you built the encoders for those Chinese dc motor in details?


    2 replies

    Hi, the encoders were removed from an car radio, and soldered on dual-side PCB which I made myself. The mechanical connection between it and the motor shaft was done using thermo-contractible tube. If you plan on using the same design, I'll recommend finding another method, as this yield poor results - the motors which already integrate sensors (be it infrared or hall-effect) have them on the DC motor shaft (which rotates thousands of times per minute), not on the output (wheel) shaft (which only rotates tens, hundreds of times per minute). Thus, my implementation had some issues with step skipping (the number of steps per revolution for the encoder were not the same as the gearbox's, so most of the times when the wheel was not rotating the encoder was not in a mechanically stable position - one output pin low, one high, but in-between two stable positions - both pins high or both low - which meant a step count was lost, because for a step to be counted, one of the signals needed to transit from low to high, while the other high to low). The other issue was step counting resolution - one encoder step (mine is 24 steps per revolution) required the mobile platform to move about 2cm, which was too much for my application. You're better of buying specially design motor kits, or finding a way to count the revolution directly at the DC motor shaft.

    Hi pcmihnea,

    Thanks for the detailed explanation. This was my first time to see a rotary encoder attached to a gear motor, so I was wondering the performance. So I guess it has low resolution and step count will be lost with the motor.

    I have used similar motor before and could hardly get a suitable quadrature encoder for it. I used encoder disc together with diy encoder using IR sensor, the output was not stable as it is hard to position the sensor. The duty cycle of the output signal was not stable and the sensitivity towards the black and white lines are not strong.

    I think the best solution was to avoid this kind of motor as it is hard to control. From my experience, it has also a dead zone where it won't moves at low PWM. Probably a better motor kit is the solution for this problem

    When I first started coding in hardware design language, I choose VHDL as it is considered industry standard, and thus it may prove an advantadge if I were to work in the future at a professional level. Anyways, as soon as the contest has finished, I'll post the link to the full sorce code, in hopes it will help.

    Fantastic idea and design. Good choice for your dev board and being willing to step our of your comfort zone and learn something new.

    I work at Digilent and we love to see what projects are being developed out there. Thanks for posting this. Good luck in the contest!

    1 reply

    That is a wonderful design. I really like the idea of having a search bot and a rescue bot. I am curious, why did you chose to use an fpga in place of a microcontroller?

    8 replies

    Hi, thanks for your interest. The reasoning behind my choice is to have a more challenging experience - for example, while in a microcontroller development environment (using high-level design language, like C), to integrate a "atan2" trigonometric operation in your program, it only requires a library inclusion, and that's it. But in the low-level design language that I used in this project (VHDL, although it is possible to code in C too, but it not as near as efficient - it's like comparing Asemmbly with C), there are no trigonometric function integrated that can be implemented on a FPGA chip, and not only software simulated (math-real.vhdl, for ex.). Thus, I had to research and find a way to implement it myself, resulting in a new (for me) computation concept - CORDIC. While in Mplab or Android IDE it olny required to write "atan2(x,y)" and the IDE took care of the rest, in VHDL I ended up learning new information and actually appreciating how accessible, easy (and free!) the hardware programming environment is today. The VHDL-coding experience itself is for me something new, as it has few-to-none similarities with what I used before - parallel computing compared to sequential as in AVR/PIC/ARM micro-controllers. So in short, I choose it for the new knowledge it brings.

    Oh alright, that makes a lot more sense. I was thinking you were shooting for a final product type design. I agree that there is much more to be learned from an FPGA. I am writing a simple processor in Verilog right now for one of my engineering courses.
    Thanks for your input! Cheers!

    Hi, No, this is not even by far a final product (or even an attempt at it :) ). As a 3rd year student at Automatics and Applied Informatics, I started working on this project for this year's Digilent Design Contest (digilentdesigncontest.com). The idea behind the contest that they supplied the development board (of which each participant could choose either FPGA or ARM) and develop an application of their choosing for that board (no limitations imposed). My idea rose as a way to give use to the scavenged devices I had at home - the LCD screen, RF transmitter/receiver and IR Thermometer - devices that would prove difficult - if not impossible to implement on low-level 8bit microcontrollers that are mose usual and accesible for hobbyists lile myself (the LCD itself requires 10MHz data clock - a almost unreachable frequency for cheaper microcontrollers). Besides that, the FPGA arhitecture has it's many advantadges, most notably (almost) parallel processing and the idea of each I/O pin to be literally GPIO (general purpose), and not constraint to any hardware limitations (hardware intrerrupts, hardware fixed-protocol controllers - I2C, Uart, SPI, etc.). I'm also currently working on a PIC18-based project that implies continouous multiple i2c peripherals communication, and I can observe with my naked eye how each additional instruction reduces the rate of i2c device polling (times per second), while with the FPGA, it doesn't even brake a sweat no mather what I throw at it (the 10MHz LCD data controller, PWM, I2C, 7seg display, debouncer, finite state machine, signal events, and others). As a sidenote, what are the reasonings behind the choice of teaching Verilog over VHDL? I am aware that each has its own (dis)avantadges, but which one would prove more usefull in the future (as in professional uses - like developing FPGA designs for a living)? Best regards, pcmihnea

    That makes perfect sense since FPGAs can be modified to fit the exact need. I really like the work you've done. I am not quite sure why my course chooses to teach Verilog over VHDL. I personally have no experience with VHDL. My course is an introduction to digital systems so perhaps Verilog is an easier language to teach?

    Verilog is more like C/C++ in structure, which is probably why MagicByCalvin is using it in an intro course. It's newer than VHDL, which has been an industry level standard for 20+ years. They both do the same thing (e.g. parallel execution vs. sequential), but Verilog can be easier to grasp when you are already familiar with C/C++. I believe that industry is still mostly VHDL, but they both have their place.

    I've now taken a look at samples of both and I can see how Verilog is easier for the beginner. I also asked my professor about it and he said that they are similar enough to the point that he only needs to teach one. Once I go into industry I should be able to use my Verilog knowledge and transfer it over to VHDL.

    I would encourage you to know both, even if only a cursory understanding of VHDL. It's not uncommon for industry interview questions to expect you to be able to code on the fly, and there's no guarantee what language they will expect. If their internal archive of material is in VHDL, I doubt they'll want to make the shift.

    Thank you for that insight. I will be sure to get at the very least some exposure to VHDL before I apply for a job that would require descriptive programming. The way I understood it from my professor is it would be easy for me to start coding in VHDL or Verilog if I knew the other. Knowing both can't hurt though!