My Home Brew Robotics Project, Embedded Controller Based Peripheral Devices

The wide range for the kinds of PDs I've worked on over the years is reflective of the fact that the original focus of this product was student science lab support. Here is a list of the PDs that, to date, I've at least started and which are now sitting on a shelf in my office in various stages of completion...

Dual Optical Interrupt Timer: 25mm Gap
Dual Optical Reflection Timer: 25mm Gap
Optical Interrupt Timer: 75mm Gap
Time of Flight Sensor

Quadrature Rotation Encoder
Pressure Sensor: (0-1.45) PSI-gauge
Pressure Sensor: (0-25) PSI-gauge
Pressure Sensor: (0-7) PSI-differential
Pressure Sensor: (0-100) PSI-differential
Load Cell

Temperature Sensor: Ambient
Temperature Sensor: RTD
Temperature Sensor: Type-K Thermocouple

LED Strobe Light
Audio Signal Generator
Precision Audio Signal Generator
Audio Signal Sensor
Audio Signal Sensor: with DSP
12kHz Pulse Generator
12kHz Pulse Detector

IrDA Link
Fiber Optic Link
TV Remote
Card Swipe Reader
Bar Code Reader
Laser Diode Driver
Hot Plate Controller
Mitutoyo Electronic Caliper Pickup

USB-HID Host Controller
USB Slave Controller

Real Time Calendar Clock
External LCD Display
External Keypad

Limit Switch
Dual H-Bridge, Stepper Motor Drive
Light Duty DC Motor Drive
Medium Duty DC Motor Drive

4-Port Hub
8-Port Hub
Wall-Wart Power Supply
De-Walt Battery Power Supply
Solar Cell Power Supply

PDs, The Original Design Effort. When I first began this project, I settled on the USB 1.10 serial bus as the preferred communications link between the CB and the PDs . And my choice for an embedded controller was an 8-bit USB-enabled PIC processor. The photo below shows two examples of these older design efforts.

Electronic Caliper Serial Port Adapter and Differential Pressure Sensor.

USB as a serial interface has much to recommend itself for applications like robotics, but for a number of reasons that I'll cover in a future post, I had to give up on using it, [1]. What I ended up doing was creating my own serial bus design by first throwing out a lot of the protocol overhead that burdens the USB standard, while optimizing those aspects of USB that lend themselves to the kinds of lab bench and robotics applications I envisioned for this home-school science lab product.

The down side of this change was that I couldn't use any of the industry standard USB micro-controllers to design around. But the up side was that, by designing my own micro-controller in a FPGA, I was able to incorporate into hardware a lot of features that would have been impossible to implement using any industry standard USB micro-controller.

PDs, The Current Design Effort. Once the decision was made to abandon USB as my choice for the system's serial interface, the design of the PDs fell immediately into place. I had already done several USB Host controllers and USB-SIEs in Verilog, so having to forgo using an off-the-shelf USB part and create my own FPGA based micro-controller was an easy transition.

Working in Verilog allowed me to implement in hardware a serial bus with the exact features my system design needs. It also let me incorporate into a PD’s design, features I could never have had using a standard micro-controller chip. Here are just a few examples.

CW from top: photo-gate timer,dual H-bridge motor driver, audio tone generator.

The optical photo-gate timer PD has a 1ms resolution for absolute timing measurements, but when used for velocity measurements of a passing object, can run in a 10µs resolution mode. The timer can be configured to trigger on either a rising or falling edge or set to record either an absolute time stamp or on/off duration times. Since each photo-gate timer is synced to the CB's clock, a sequence of timers, spaced even meters apart, can be used to measure a time-of-flight profile for ballistics experiments. This is something that no off-the-shelf physics-lab photo-gate timer can do.

The dual H-bridge motor controller PD can either micro-step drive one stepper motor or variable-speed drive two DC motors.

Since each PD can sync its own internal clock to the CB's to within a few micro-seconds, this allows not only the frequency of an audio tone generator PD to be controlled, but its phase as well. This opens up the possibility of using pairs of tone generators to do audio wave-interference experiments. One can also use a cluster of tone generators to create a steerable phased-array audio beam!

12.5 kHz pulse transmitter for echo-location experiments. LED strobe light.

The pulse transmitter PD above is used to drive a 12.5 kHz piezoelectric ceramic resonator element. The tone is high enough to "get the physics right" for demonstrating bat or dolphin echo-location. But it's low enough for students to hear and experience the phenomenon of echo-location directly. Again, since each PD can sync its own internal clock to the CB's to within a few micro-seconds, this pulse transmitter can be paired with a pulse waveform detector PD to capture the returning waveform with micro-second resolution.

The LED strobe light PD can be paired with an audio tone generator to do physics experiments involving driven mechanical systems. A tone generator PD can be used to drive a mechanical system, while a strobe light PD can be set to a frequency 1 to 2 Hertz off from the tone generator's. This allows students to see visually a system's response as the frequency of the tone generator is swept up/down.

A USB adapter PD. This allows USB HID devices to be plugged into the WIDJETS CB

For example, one of the big drawbacks of a robotics kit like LEGO Mindstorms is that there are no user manual control devices available for them. Having a USB adapter PD that can act as a USB Host Controller allows one to use USB-HID devices as input controls to the CB; devices such as an optical mouse, keyboard, joystick or game controller.

A second advantage of such a PD is that memory sticks can be used for program transfer to/from a CB or to act as extra memory space for programs too large to fit in the CB's internal memory space.

[1]. T.B.D.

My Home Brew Robotics Project

As a home schooling parent, one of the big challenges is a lab class such as AP physics. There are suppliers like Pasco http://www.pasco.com/ or Vernier http://www.vernier.com/ that supply most of the lab bench equipment that you find in high school and college classrooms. If you go to these sites you'll see that the prices are prohibitive for working families. My goal started out to be the creation of a low-cost measurement and data-logging system equivalent to the Pasco's 850-Universal Interface or the Vernier's LabQuest2.

The way to reduce the costs for such a system is to have an easily reprogrammable control box complemented with a wide range of sensors, actuators and motors, all sharing a common serial interface. Implementing this common interface required that each peripheral device (motor, load-cell, timer, temperature-sensor, and etc.) all had to have an embedded microcontroller. But as soon as I did that, I realized I created a system with distributed intelligence; and besides measurement and data logging, it was also going to be a great platform for homebrew robotics.

Having a robotic system based on smart motors, sensors and actuators that together comprise a system of distributed intelligence is not one that I recall ever seeing built? But from a hobbyist point of view, it is a very powerful but inexpensive way to go.

Several developments come together to make this design concept work. Having smart peripheral devices (PDs) means that a lot of the control box's computational burden can be off-loaded to the individual plug-in devices; the control box (CB) turning into more of a task manager, interacting with the PDs via a small set of high level commands. This simplifies the programming that the CB has to run and reduces the complexity of the required CB hardware.

The Control Box .  PCB is 4.5" wide by 7.0" long.

The hot-swap plug-n-play serial interface is loosely based on USB, rev: 1.10. It is still a star-tiered arrangement, with levels and hubs, but I dropped most of the USB-protocol stuff. Instead of the 5V USB standard power, I went with 12V. This allows for larger motors to run off of bus-power alone. I settled on a 1.0-MHz bus clock, but still have the 1-ms time stamp sent out every frame. Using this time stamp, each of the PDs can sync their clocks to within a few microseconds of the CB's and each other. USB rev: 1.10 only gives each device one unique address, but I've given each PD four addresses, one that is unique for control and three that can be party-line address so that the CB can broadcast simultaneously to functional clusters of PDs in one command.

The CB is a micro-core combined with the serial interface's host controller. The micro-core instruction set includes machine level ones that interact directly with the host controller. This simplifies communications programming tremendously. The host controller supports 8 ports. Each port can support an additional 8-port hub for a total of 64 ports maximum. The design goal was to have a CB with sufficient I/O and short enough response time to be able to implement a robotic hand+forearm system or a four-legged walker.

The micro-core plus host controller is written in Verilog and ported to a Lattice XP FPGA part. The core itself is a stack-based engine with a machine instruction set reminiscent of the RPN language Forth. Because the machine instructions are Forth words, this micro-core can run Forth programs very fast; while rendering the compiling of Forth code source files into machine instructions a straightforward task. There is no programming software, running on a PC, needed for its operation.

Since Forth is based on a dictionary of words, part of the handshaking that goes on between a PD and the CB after plug-in is that the CB uploads, to its dictionary, from the PD, the low-level command words it needs to talk to that PD. Then, with only a few lines of source code, a homeschooler and/or their parents can have their control box programmed and up and running. Another benifit from this is that the CB's programming doesn't have to know anything a-priori about any PD being plugged into it. Anyone can make their own custom PDs, and as long as they conform to the proper programming template, whatever they make will plug in and run on the CB.

Since the PDs all have internal ram, an option that I want to add in the future is for each PD to store pre-defined tasks that can be initiated on a given time stamp; a kind of muscle memory. Complex motions can be orchestrated by pre-loading a functional cluster of actuators and sensors with predefined instructions then initiating that motion by one broadcast command from the CB. Coordination is guaranteed because all of the PD's clocks are synced to the CB's clock. This also opens the door for the ability to learn. A motion can be tried out, then modified and reloaded into a functional cluster of PDs for another try until a complex action is perfected.

The micro-core kernel is still very much a work in progress. At this point it occupies about 30-kbytes of memory. Yes, that is kilo not mega. The system clock is only 4.0-MHz, but I still can maintain a 1-ms input/output response time. The individual PDs run a reduced instruction set version of the micro-core. They are also ported to a Lattice XP part.

I've had this entire system, as described, running on my lab bench for the last year and a half. But work and finances have not let me finish until now. The plan is to get back to work on it this summer and make some more progress with it.

This is a postscript for those familiar with the Forth programming language. One of the great things about creating your own micro-controller/processor in Verilog or VHDL is that you can give it special machine instructions that will optimize it for the control functions it will be performing. In this case, I've added several features to the micro-core to optimize the CB for coordinating the multiple concurrent tasks parceled out between the various PDs plugged into it.

I've introduced a programming object I call a task. It is a C-like structure that starts with an index pointer, followed by a list of code-pointers that can be accessed via the index pointer. Next, to deal with these structures, I've extended Forth by adding two extra features. First is to add two new Forth words: t@ and t!. These are memory access words that are offset from a base address. Then I've introduced a class of words I prefix with a (t.). These designated words expect a base address stored in a special register, with all t@ and t! commands contained in the definition of these words, offset from this base address. This allows t-dot words to be re-used by any task that calls it via one of its code-pointer entries.

The other feature I've added into the Verilog code is the addition of multiple data/return stack pairs. Forth users are all aware that task switching can happen very fast by simply switching the processor from one data/return stack pair to another. To implement this feature, I've added four data/return stack pairs to the micro-core; and have added a machine level instruction to bank-switch between them. With this addition, I can task switch in three machine instructions: (1), push return address to return stack; (2), bank-switch to next data/return stack pair; (3), execute a return instruction.

One of the great unappreciated features of Forth is that it lends itself to a verbal command style. All too many Forth practitioners focus on the minimalist nature of Forth programming and have thus done a lot to give it a reputation as a write only language. But once you get away from all of the DUP SWAP */ stuff, and build up, more and more complex word definitions, a Forth program can take on a very verbal and intuitively understandable form. By having the CB upload all of the low-level command words from the individual PDs, it frees the CB to be programmed at a much higher level and in more verbal style of Forth.

So the goal for this next summer is to see if I can build some kind of extension of Forth that includes these t-dot words.  If I can do this, then I should be able to program my robot control-box by just talking to it in t.Forth sentences.  For example, I could say to my robot t.GoToEndOfHall t.TurnRight and my robot would perform that sequence of commands just as if I had typed it in on a keyboard.

Thinking About Future Posts

Two areas that I'm going to be researching for future posts will be locomotion and robot muscle; specifically those types of each that will be adaptable to the needs of a robot harvester/tender.

Regarding modes of locomotion, I've already concluded that a walker will be the best all-around option for a harvester/tender [1],[2].  I've been looking at both hexapod walkers and robot lizard walkers and comparing their motion to that of actual lizards.  Three things stand out immediately.  First, real lizards have feet; hexapod walkers don't. Second, a real lizard's elbow moves horizontally, while the elbows on hexapod walkers move vertically.  And third, hexapod walkers have rigid torsos while a real lizard bends its spine from side to side as it moves.  What does all this mean?  I don't know.  Hopefully, with some research, thought, and time, I can arrive at some answers.

Once the mode of locomotion for a robot harvester/tender has been decided upon, the next step in design is to specify the type of actuator (robot muscle) that can be used to implement this motion.

Regarding possible candidates for robot muscle, to date there are no good candidates!  But the first step in narrowing down the set of most likely candidates is to start a list of the constraints that a viable candidate for a robot harvester/tender’s muscle must satisfy. 

Next, the question of our robot harvester/tender’s brain needs to be addressed.  Whatever computer system ends up being used to control a robot harvester/tender, it will still be held to the same constraints, in terms of size, weight, power consumption, cost, and etc., that the rest of the robot design will be held to.  But here lies the design challenge; there are no currently available computer systems that fit these constraints! 

Lastly, the question of fabrication methods: if/when robot harvester/tenders take their place in the farming industry, they will need to be produced by the 100K’s quantities.  They will need to be fabricated in a way that makes them cheap to make but still robust in use.  The modern auto industry has been addressing this exact issue for years, so a good place to start would be to look at how cars are designed and built.

[1] Agricultural Robots: Locomotion, Walker, Crawler or Wheels?
[2] Dancing Robots vs Robot Dancing

Piezoelectric Actuators

Electromagnetic driven actuators will be off the table for agricultural robotics because of their high current draw and low force/current ratios.  On the other hand, because of their high force/current and high force/size ratios, piezoelectric driven hydraulics has the potential to be a good candidate for "robot muscle" for portable and field deployed robotic systems.  The other nice thing about hydraulics is they are very abuse tolerant, work in the mud and dirt, and even under water. 

This is going to be an ongoing area of research for me.  As I find new information, I'll post it here and then bump this post to the head of the queue again.

This isn't hydraulics, but it is an interesting use of piezoelectrics to drive a linear actuator.  It uses a ‘walking” motion to generate 8-Nt of force with a 20-cm/sec velocity. http://www.linear-actuator.net/Ultrasonic-Motors_Linear_Actuators.php

Here is a piezoelectric driven hydraulic pump capable of 2500-psi output pressure and a flow rate of 40-cc/sec: http://www.kineticceramics.com/piez_fluid.html

Also see: http://aml.seas.ucla.edu/research/areas/piezoelectric/pump-non-mech-valves/2002-12_lee.pdf

Micro Gas Turbine Engines

While researching gas turbines, I came across a fascinating new area in high-tech R&D that bills itself as "micro turbines".  These are gas turbines on the order of 1 cm in size and turn at 500,000 to 1,000,000 RPM and higher.  Here are a few images from the links included below.

 

This combustion chamber only measures 20 mm in diameter and is 2.7 mm thick.
Supplied by a hydrogen-air mixture, it produces a power of up to 1200 W.



How about a 50-100 W gas turbine generator with

fuel tank the size of a pack of playing cards!

Here is a list of micro turbine links.  Some are news posts, but most are journal published, research papers.

Engine on a Chip

Micro-turbines, Maxi-difficulties

PowerMEMS Project - Microsystems for power generation

ULTRA MICRO GAS TURBINE GENERATOR

A SILICON-BASED MICRO GAS TURBINE ENGINE FOR POWER GENERATION (PDF)

 

DEVELOPMENT OF MICROMACHINE GAS TURBINES AT TOHOKU UNIVERSITY (PDF)

MILLIMETER-SCALE, MEMS GAS TURBINE ENGINES (PDF)

POWER MEMS AND MICROENGINES (PDF)

THE USE OF MICRO TURBINE GENERATORS IN HYBRID ELECTRIC VEHICLES (PDF)

DEVELOPMENT OF MICROMACHINE GAS TURBINE FOR PORTABLE POWER GENERATION (PDF)

ULTRA-HIGH-ENERGY-DENSITY CONVERTER FOR PORTABLE POWER (PDF)

POWER ELECTRONICS INTERFACE FOR A 100 W, 500000 RPM, GAS TURBINE PORTABLE POWER UNIT (PDF)

AN ULTRA-HIGH-SPEED, 500000 RPM 1 kW ELECTRIC DRIVE SYSTEM (PDF)

MICROFABRICATED SILICON CARBIDE MICROENGINE STRUCTURES (PDF)

HIGH POWER DENSITY SILICON COMBUSTION SYSTEMS FOR MICRO GAS TURBINE ENGINES (PDF)

Piston vs. Gas Turbine Engines, Efficiency, Final Thoughts

Pulling together all of the research and thinking I've done on the question of engine efficiency over the last couple of months, here is my conclusion...

If I were to write a design spec. for the power source for my "dream-team" agricultural robot harvester/tender it would specify a hybrid design consisting of a single-shaft gas-turbine generator combination driving a super-capacitor bank.

It would come in a drop-in package that could be changed in/out with a 1/2" socket set and 3/8" flare nut wrench.  The engine-generator set, the fuel tank and the super-capacitor bank would each be mounted as separate units.

But such a design is not realizable yet.  To date, there are no small 1-2 kW gas turbine engines commercially produced.  Though, the work being done on micro gas turbines makes one optimistic that someday they will be.

For now, if I had the machine shop to do it in, what I would do, would be to mount one of the Honda Gas Engines (showcased in a previous post) on a testbed and try to run it continuously for a few months and see how it holds up.  If it does, then it would make a good second option for an agricultural robot harvester/tender's power source.

If more information comes my way, I may yet change my mind on this subject.  But for now, I've gone as far on this subject as I can.  So it's time to put this aspect of robot design to bed for awhile and start on something new.

Piston vs. Gas Turbine Engines, Efficiency, Global View

The Global View  The issues of local and mid-range views of engine efficiency overlap the global view in the areas of maintenance and repair. 

Based on my experience, something that electronics and software engineers, working in the area of agricultural robotics, don't seem to appreciate is the high cost of machine maintenance.  Everyone is familiar with the high cost of auto repair these days, so why isn't the engineering community making the connection that robot repair is not going to be any less expensive?

Engine efficiency often comes at the expense of higher temperatures, higher pressures and greater mechanical complicity.  All of these are factors in decreased engine life, more stringent maintenance requirements and higher cost of repair.

Let's try some order-of-magnitude estimates, OME's, for the service costs of a robot harvester/tender and for the fuel budget savings for a 20% increase in engine thermal efficiency. 

First, an example repair situation...
   $100.00  2 hours labor
   $200.00  parts
   $100.00  tow-truck to pick-up/put-back our robot from/to the field
   $100.00  cost for a fill-in-for-the-day replacement robot
   $500.00  total cost to farmer for a typical repair  

Now look at the cost savings for a 20% increase in fuel efficiency.  Assume a fuel consumption of 2 gal/day.  At $4.00 a gallon, a 20% increase in fuel efficiency yields about 17% savings in fuel costs, which translates to about $1.35 a day.  At this rate it would take a year's worth of operation to balance out the cost of just one typical repair.   

From the point of view of the farmer's pocketbook, the bottom line is that reliability and low maintenance costs will always trump considerations of engine thermal efficiency .