Seek_r is an autonomous rover designed for exploration. Fitted with a number of sensors, can navigate spaces & react to the things it finds.

Similar projects worth following
Seek_r is an autonomous rover designed for exploration. Fitted with a number of sensors, Seek_r can navigate spaces & react to the things it encounters, in order to keep itself safe. All of the rover’s peripherals coexist on an I²C bus and are coordinated
by an 8-bit microcontroller (PIC16f877).

Seek_r’s firmware was lovingly handcrafted in assembly language. In the configuration shown on this page, Seek_r will explore an environment, looking for candles & if
possible blow them out with the front mounted fan from a safe distance. Built to be a research platform, the frame allows for sensors & other components to be swapped in & out for different experiments.

Seek_r has also hosted investigations in obstacle detection & avoidance, solving mazes & transporting objects. Currently, the rover is a test bed for a carriage-less printer.

Started as a school project from years ago that I can't put away. Currently looking at using a different MCU to make it tick. 

  • 4 × 14V RC Battery Pack Power source
  • 1 × RD02 robot drive kit I2C motor controller, 2x gear motors with encoders, wheels, brackets
  • 1 × TPA81 Thermopile array I2C thermal sensor
  • 1 × Aluminium chassis Custom, folded, welded, with inserts
  • 1 × SRF02 sonar I2C ultra sonic range finder

View all 7 components

  • Design overview

    Dev Joshi05/05/2014 at 15:38 0 comments

    Logical overview

    Selecting I2C peripheral components greatly simplifies the hardware and software implementation of the device. Most modern MCUs have facilities for I2C built in to their hardware which removes a fairly sizeable firmware overhead.

    Chassis layout

    With the majority of components selected, it is possible to begin hashing out a layout for the chassis for the rover. 

    After sketching out major components and their possible configurations, models were acquired or built for the various parts and arranged in SolidWorks. The sheet metal chassis was then constrained, in context, against the other components.

    With the basic layout completed, additional holes were added to the chassis part for cable ties. Next sheet metal press fasteners (nuts, inserts and studs) were added to make for an easy assembly job. "Penn Engineering's PEM Fasteners": (FSH and so on) covered all the required bases and made for an easy fit with the 2mm aluminium sheet that the design targets.

    Electrical and electronic design

    With a large portion of the mechanical design completed it was possible to start pulling the electrical and electronic parts of the system.

    With the power source already defined (NiMh battery packs) and their physical location set in the chassis it was important to find a sensible way of actually attaching the power packs to the rover's drive and logic systems. With PCB mountable JST connectors to mate with the battery packs no where to be found, a simple screw down terminal block would have to suffice.

    The MD25 control board comes complete with a 5v 300mA regulator to drive its on board MCU and other logic as well as a number of power/data connectors which provide access to the logic drive 5v and the I2C bus. 300mA is more than enough to run the logic board, some LEDs and the I2C sensors. The bus cable feeds power "back" to the main logic board which in turn communicates with I2C peripherals via the MD25 board.

    MCU requirements for this project in the first instance were actually fairly straightforward.

    •  Hardware I2C support (2 I/O pins)
    • Simple programming/debugging interface
    • 8 GPIO lines for motors and LEDs and indicators and so forth

    Within the constraints of the project, there are (at time of writing) 66 MCUs in the 16F series which are readily available through standard channels. Eliminating devices with insufficient I/O ports and those lacking an internal MSSP peripheral (the device onboard the PIC which handles I2C communications in hardware) brings the countdown to 12 devices. Removing the 40 pin devices (which are just too big!) leaves six chips to choose from.

    From the remaining six devices the PIC 16F1936 has the largest size EEPROM, RAM and program memory (per unit cost) as well as an internal oscillator (negating the need for additional clock generating components) which would make it an obvious choice. However, careful review of the device specification reveals that the ISCP feature on this newer MCU only functions with newer programming and debugging equipment – which – I do not have access too.

    For these reasons, the PIC 16F876/873 MCU was chosen as the base for this project. A well understood and documented part supported by many debugging tools; it fulfils all the stated requirements. Past experience developing with 16F877 make writing code for these smaller units relatively straightforward. 

    Detailed hardware/software considerations

    While the ports on a PIC MCU are easy to map to different functions, the locations of certain internal peripherals are fixed (relative to their output pins) and so it makes some sense to logically separate the different functions the MCU must perform and arrange the connected hardware appropriately.

    •  No analogue functions are being used on the MCU so PORT A is available as a contiguous block. Status indication LEDs are connected to PORT A
    • PORT B is reserved for ISCP – not all of PORT B is involved in ISCP...
    Read more »

  • Requirements and specification

    Dev Joshi04/23/2014 at 19:08 0 comments

    Discussion of ‘hardware’ in this context refers to the electro mechanical components required to build Seek_r. It does not (directly) refer to the hardware requirements in terms of clock speeds, RAM space and other electronics. That comes later.

    The mechanical configuration of this project must either support or facilitate a number of functions – these include:

    * Some kind of frame, to which things can be mounted

    * A reliable method of steering and locomotion

    * Allow for easy access to electronics and connectors and so on for simple maintenance

    * A mechanism to extinguish small fires

    Steering & Locomotion

    Steering and locomotion can be accomplished through a single system by implementing some kind of differential drive. Contenders for the position are:

    • Caterpillar/tank tracks

    PRO: Look badass

    PRO: Zero turning circle

    PRO: Capable of crossing uneven terrain

    CON: Requires a precise implementation for reliability

    CON: Pre-fab implementations are inflexible and expensive

    CON: Prone to damage due to the number of parts involved

    • Skid steering with multiple wheels

    PRO: Very stable

    PRO: Relatively easy to implement

    CON: Steering not particularly accurate

    CON: Traction control issues

    • Direct differential drive (3 point wheel buggy)

    PRO: Very stable

    PRO: Relatively easy to implement

    CON: Steering not particularly accurate

    CON: Traction control issues

    A direct differential drive – in the format of two directly driven wheels (motor --> gearbox --> wheel) seems like the most straight forward way to build something like this. The specific implementation of the differential drive could be done in one of the following ways (though the considerations listed here mostly apply to all of the methods motioned above):

    • Stepper motors

    PRO: Afford precise positioning and indexing

    PRO: Inherently position aware (assumed only)

    PRO: Wide range of options and good availability

    PRO: Easy to lock output shaft position (braking)

    PRO: Good torque response

    CON: Expensive

    CON: Requires a relatively complex hardware and/or software interface

    CON: Positioning is implicit, not actually known

    CON: Non trivial drivers required

    •  DC Motors (geared)

    PRO: Cheap and readily available

    PRO: Easy to configure torque/speed/size with an appropriate gearbox

    PRO: Simple hardware interface

    CON: No position/velocity feedback without additional parts

    CON: Gearbox almost certainly required (at additional cost)

    CON: Potentially high peak current draw to deal with

    •  Hobby Servos

    PRO: Readily available in a number of sizes/configurations

    PRO: Simple, well documented interface

    PRO: Position+PID based control makes positioning parametric vs. Implied positioning from a velocity controlled system

    PRO: Low voltage, built in gear box

    CON: Relatively expensive

    CON: Continuous rotation requires hardware modification

    CON: PID implementation isn’t great in some instances

    CON: Cheaper units are not super reliable, can be prone to backlash

    For mechanical simplicity, drive wheels should be connected as directly as possible to motor/gear box output shafts. Belts and chains introduce all manner of issues into systems like this. With an inline motor-gearbox type assembly, having both driving units on the same axis ill likely result in a fairly wide chassis which should be relatively stable.

    Given the cost complexity trade off and the potentially sizeable payload the rover will need to move (at some speed) a DC motor solutions looks to be best fitting in this scenario.

    With this in mind, whilst looking for a suitable combination of drive wheels, motors, gearboxes and controllers I came across the RD02 from DevanTech.

    The RD02 kit comprises:

    2x EGM30 DC motors with pre fitted encoders:

    2x 100mm diameter wheels on 5mm hubs

    2x Wheel-motor mounting brackets

    1x MD25 2 channel motor control board with serial interface:

    Making use of the RD02 kit greatly simplifies the construction and management of the locomotive subsystem in the rover. Encoder feedback,...

    Read more »

  • Introduction

    Dev Joshi04/23/2014 at 19:01 0 comments

    Seek_r started out as an introductory project in Creative Embedded Systems while I was at university. Once that was over however, the project just sort of - carried on. Just as it started, Seek_r is really a self-indulgent platform which allows me to try stuff out and learn new things about embedded systems and so on. This page is a log of those things - hopefully it will be of some use to someone.

    The original brief: Create an object which reacts to changes in temperature. After my more sensible friends talked me out of actually setting things on fire I settled on the following outline specification. 

    There is a room full of candles and obstacles. Devise an object which can navigate the space and upon discovering a lit candle, extinguish it. 

View all 3 project logs

Enjoy this project?



Eric Evenchick wrote 04/30/2014 at 05:28 point
Reminds me of the firefighting robots I saw at Ottawa Mini Maker Faire. They were building them for this competition:

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates