-
Design overview
05/05/2014 at 15:38 • 0 commentsLogical 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":http://www.pemnet.com/fastening_products/pem-self-clinching-fastener_new.html (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 but the other peripherals located there are not being used and GPIO can be done elsewhere on the device
- The MSSP and UART are connected to PORT C and so the I2C bus should be connected here. As the MSSP and UART use different pins, it will be possible to add other serial devices to the design at a later stage if required
- PORT C is also connected to the PIC’s CCP units which are responsible for PWM output. Connecting the fan motor here will allow for hardware based speed control of the extinguisher device.
Having a whole 8-bit port dedicated to status LEDs may seem excessive; they are useful for a number of things. In the first instance, they provide a quick visual clue as to what and how the rover is currently doing. The I2C peripherals provide a variety of additional information about themselves which can be useful to know at a glance – battery voltages and error states for example. Access to a contiguous 8-bit port also provides a great debugging tool – it is super easy to write values to a port and thus “see” a particular variable or number change inside the device without having to have the ISCP dongle attached.
-
Requirements and specification
04/23/2014 at 19:08 • 0 commentsDiscussion 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: http://www.robot-electronics.co.uk/htm/emg30.htm
2x 100mm diameter wheels on 5mm hubs
2x Wheel-motor mounting brackets
1x MD25 2 channel motor control board with serial interface: http://www.robot-electronics.co.uk/htm/md25tech.htm
Making use of the RD02 kit greatly simplifies the construction and management of the locomotive subsystem in the rover. Encoder feedback, DC motor control and software interface development of this sort constitute an entire project in their own right.
The MD25 has a simple serial communications interface (UART or I2C) and hosts all of the required hardware/firmware to drive two encoded motors concurrently. The Interface it presents hides the majority of motion control complexity from the main MCU requiring simple command to manipulate the drives.
Power
The MD25 has a simple serial communications interface (UART or I2C) and hosts all of the required hardware/firmware to drive two encoded motors concurrently. The Interface it presents hides the majority of motion control complexity from the main MCU requiring simple command to manipulate the drives. - DC power supply
PRO: Limitless supply
PRO: No issues delivering required current.
CON: Limited range of movement (there will be a cable attached to the rover)
CON: Bulky
- Lead acid battery
PRO: Cheap and readily available
PRO: Understood technology
PRO: Easy to recharge
PRO: Generally rated to 12V
CON: Bulky and heavy
CON: Relatively low energy density
- Alkaline cell battery
PRO: Super common
PRO: Reasonable energy density
PRO: Can be high drain
CON: Not rechargeable
CON: Not sustainable
CON: Expensive in the long run
- Lithium cell battery
PRO: Excellent energy density
PRO: Did I mention excellent energy density!
CON: Somewhat prone to exploding
- Nickel-Cadmium battery (NiCd)
PRO: Easy to obtain (for the time being)
PRO: Very stable
PRO: Deep cycle friendly
PRO: Very low self discharge rate
PRO: Good energy density
CON: High cost
CON: Being phased out due to environmental issues
CON: Terrible temperature coefficient
CON: Cells are slightly lower voltage (1.2V vs 1.5V)
- Nickel-metal hydride battery (NiMh)
PRO: Good availability
PRO: Discharge profile well suited to application (low internal resistance favourable to high current draw)
PRO: Lower environmental impact vs. NiCd
PRO: Easy to charge
PRO: Higher capacity than equivalent NiCd
CON: Relatively expensive
CON: Bulky
CON: Easy to damage during charge/discharge cycle
- Lithium-Ion battery
PRO: Mature technology, well understood
PRO: High voltage, high capacity
PRO: Excellent energy density
PRO: Low self discharge rate, no memory effect
PRO: Low profile
CON: Poor shelf life and life cycle
CON: Expensive
CON: Complex charging procedure
CON: High internal resistance not suited to high drain application
CON: Temperature sensitive
- Lithium-Ion polymer battery
PRO: Very high energy density
PRO: Better life cycle vs. LiOn
PRO: High drain
PRO: Ultra lightweight
CON: Very expensive
CON: Complex charging procedure
CON: Temperature sensitive – explosive hazard
CON: Weight saved vs. Cost insignificant compared to LiOn
- Hydrogen Fuel Cell
PRO: Badass!
PRO: Ultra efficient
PRO: Near limitless fuel supply
PRO: Excellent energy ratings
CON: Dubious energy density
CON: Experimental tech (read: dangerous)
CON: Prohibitively expensive
CON: Recharging and cell management requires actual science
Based on this evaluation, nickel-metal hydride (NiMh) based battery packs appear to be the most suitable for this project.
High capacity NiMh packs are produced en-masse for use in model, radio-control and hobby cars/boats/aircraft etc. Typically cells are configured in to 7.2V battery packs with capacities ranging from 2100-4500mAh.
Ebay landed me a set of 4 7.2V 3800mAh packs for around £30. Connecting two sets in series provides a 14.4V supply (which the motor control board will regulate for use). Two pairs in parallel afford a total capacity of 7600mAh.
Sensors, sensing and fire
Before any finalisations to the hardware and mechanical design can be completed, the other main peripherals in the system need to be specified. The sensors the unit will use to understand its surroundings form a major constituent of this set.
Collision avoidance
Effective and safe navigation requires, amongst other things, the consistent and reliably mitigation of objects and obstacles. This is especially true of some of the objects or obstacles are on fire.
In order to prevent the rover from running in to other objects in a space, it either needs to know how far away it is from other things (non-contact range sensors) or when it is about to run in to something (bump sensors).
Bump sensors can be constructed from any number of combinations of micro switches, levers, whiskers, rollers and armatures. Bump switches trigger (surprisingly) when they come in to contact with another object. The distance can be approximately judged by specifying the offset incurred by the length of the trigger arm. In the context of this project however they are not overly suitable as some of the objects in question may be unsuitable to touch (i.e. they are hot or on fire by which point, close proximity or bumping is too close).
Short range non contact range finders often make use of infra red light to measure distances which may not be suitable in a space filled with spurious IR heat sources. Effective in the 150-1000mm range, they can quickly provide accurate results and do not require tuning or calibration. They are however, sensitive to surface finish and reflection making them unsuitable for use in all but the most controlled spaces.
Longer range finders are almost exclusively sonar based within the confines of hobby robotics. This type of sensor is easy to implement using a small MCU and an ultra sonic transducer but pre-fab modules are available, presenting a number of interfaces.
The SRF02 I2C /UART range finder module "[Data Sheet]":http://robot-electronics.co.uk/htm/srf02tech.htm uses a single transducer to both pulse and listen when range finding. While this does limit the minimum sensing range to 150mm, the cost, size and minimal configuration benefits far outweigh the pros of a large, more accurate, more expensive unit. Given the application of object avoidance, a 150mm minimum range provides a good bubble to work in as a means of keeping the rover a safe distance away from other things.
Thermal sensors
In order to detect a heat source at range – any temperature sensor specified for this project will need:
Relatively high precision To operate in a non contact fashion Have an operating range circa 4ft Preferably have some sort of FOV (using a line of site sensor would be tedious).
Thermocouples/thermistors/RTDs have limited range and repeatability ruling them out straight away. Discreet devices such as the "LM34":http://www.ti.com/lit/ds/symlink/lm34.pdf, "TMP102":http://www.ti.com/lit/ds/symlink/tmp102.pdf and "DS1820":http://datasheets.maxim-ic.com/en/ds/DS18S20.pdf are out of the running too. While it would be possible to use a device like this to measure changes in the air temperature and then use transfer function predictive filtering in firmware to guess where heat sources might be, it does not seem like the most reliable method. Further, the firmware would encompass a sizeable chunk of mathematics not well suited to the 8-bit integer arithmetic cores in the MCUs in the fray.
In the case of a lit candle, a sensor which can pick up a remote heat source at a distance need only have to report the difference between the candle temperature and the ambient room temperature. We are uninterested in any absolute values, only really the presence of something which seems much hotter than its surroundings. A sensor capable of detecting electromagnetic radiation in the IR band gap (0.9-14µm for near infra red, though technically the IR spectrum covers 700nm – 300µm).
Devices which can “see” heat sources include pyrometers, thermopiles, “infra-red cameras” and other single wave band radiation thermometers – dedicated thermal imagers, optical flame detectors, fibre optic temperature sensors and ultra sonic thermometers (yes, they are a thing). Spoilt for choice!
At the most basic end of the scale for this kind of device is the PIR (passive infra red) sensor. Present in most home security monitors, they are usually configured to provide a logic signal when a threshold has been breached within the device’s field of view (FOV). IR cameras are obviously more complex, providing location and magnitude information for heat sources in a 2D plane. "[Jonny Lee’s work]":http://johnnylee.net/projects/wii/ with Wii-motes successfully demonstrates the interfacing of IR cameras and MCUs to this effect. Thermal imaging of this complexity and detail is somewhat overkill for what is trying to be achieved here.
The TPA81 "[Data Sheet]":http://www.robot-electronics.co.uk/htm/tpa81tech.htm is an 8x1 pixel thermopile array configured as an I2C slave which is sensitive to radiation in the 2-22µm wavelength range. It can (and I quote) "... detect a candle flame at a range 2 metres (6ft) and is unaffected by ambient light".
Each pixel has a 5.12°x6° viewing scope, resulting in a total FOV of around 41° for the entire array.
Extinguishing equipment
The number of options available for extinguishing fires in this context are as varied as they are numerous. Aerosols, "[acoustic waves]":http://www.youtube.com/watch?feature=player_detailpage&v=XVLXg9lcECQ#t=20s, robotic snuffers, "[science fiction]:http://www.youtube.com/watch?v=PQMHRqckNl4 and more came in to the fray at one point or another.
After (unsuccessfully) experimenting with a "[small pump]":http://www.cornwallmodelboats.co.uk/acatalog/water_pumps.html and the mister (atomiser) from a spray bottle the conclusion was reached that the simplest and safest way to douse the candle flames was to simply blow them out.
-
Introduction
04/23/2014 at 19:01 • 0 commentsSeek_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.