The inspiration for the direction I’m heading in design-wise is the GA144 processor; an asynchronous array of 144 separate processors arranged in an 8 x 18 matrix, all fabricated together on a single die. So to understand where my design ideas are headed, it might be best to start with a description of the GA144, both its strengths and deficiencies.
For those not familiar with the GA144 from GreenArrays, here is the best short exposition of how the GA144 chip works and how it’s programmed that I’ve seen. "FD 2014 Daniel Kalny".
More information can be found at the GreenArrays web site,
www.greenarraychips.com/
The GA144 is without a doubt one of the most frustratingly disappointing pieces of silicone ever made. So much so, that I’ve personally taken to calling it the Stephen Hawking of computer chips, a brilliant mind stuck in a useless body.
There is no end of projects that can be built around the GA144. The above YouTube video from Daniel Kalny is a great example of this. But the sad truth is that from a commercial point of view, the same functionality can be fit into any number of standard processor parts from companies like Microchip, Silicon Labs, TI and etc. that are both cheaper cost-wise and easier to program using already industry standard compiler tools. So, despite its potential, the GA144 has remained a silicon oddity without attaining any commercial success.
An integrated chip this intriguing in potential begs to be used for something. But the big question is, what? This is where the problems start for the GA144. Every commercial application you might think of ends up requiring more I/O pins then the designers of this part gave it. In other words, the GA144 seems to be an ASIC part designed with no specific application in mind.
The only way to get signals/data into or out of this part is through a handful of cells along the edges of the array. Which means trying to get signals to any of the internal cells of the array requires your data stream to pass through all the cells in between the edge and the one you’re targeting for data transfer. So a lot of the cells in the array end up functioning simply as connections between adjacent cells. This would be okay if each of the cells had sufficient program memory to be able to store more functionality than just acting as one member of a bucket brigade transferring data across the array.
Another frustrating aspect of the GA144 is that it was not laid out in a symmetric fashion. That is, you can’t tile single GA144s together to form a much larger array because the top/bottom and right/left edges of the chip don’t match up pin to pin. This means if you did try and use the GA144 as a tile element in a much larger array, neighboring GA144s would be forced to talk to each other through a single SERDES link between one chip and the other. This again might not be a stopping point either, except for the fact the GA144 only has two SERDES links, and both are located on the same side of the part. As I ran into design details like this last observation, it just made me want to pull my hair and scream, “What were you idiots thinking when you made this part?!”
On the other hand, there are some amazing things about the GA144. First is the asynchronous operation of the individual cells. Each cell has its own ring oscillator for its internal clock. This ring oscillator only turns on when the cell is accessed by one of its neighbors, and it only stays on until the cell completes its current program call. The cell then goes to sleep and waits until it is accessed again. The result is you have an array whose current draw can be as little one-percent or less than that of a comparable FPGA part.
This by itself might not seem like a big deal, but from a hardware design point of view, this is huge. It’s not uncommon for processors and FPGA parts to draw currents on the order of amps. For a single processor on a board, such current draws are not an issue. But if you want to start creating large arrays of processors, you’re very quickly looking at thousands of amps of current to power your processor array. This becomes a huge wall to designing large processor arrays. The low current draw for the asynchronous array concept means that such chips can be tiled by the thousands and still be run on a few tens of amps power supply.
Another positive about the asynchronous array concept is that most of the new parts get their speed into the gigahertz range by making use of pipelining in their internal structures. The asynchronous array is naturally pipelined just by its construction. Each cell in the array does its little thing and then passes the result on to the next neighboring cells. In this way, a process passes like a wave through the asynchronous array, starting from one edge and flowing through till the result comes out the opposite edge. One can take advantage of this by having multiple waves of processing going on simultaneously. Another trick for matrix operations is to have the matrix element come in one side of the array while constants for the matrix operation are flowing in from a different edge of the array, with the result flowing out yet another edge of the array.
But for the GA144, trying to use this trick for matrix multiplications just doesn’t work. Again, it comes back to the fact that there are not enough I/O pins around the edges of the array to get data in and out of the processor at a pace that can keep up with how fast the GA144 can go.
And yet one more aspect of the GA144 that ends up just teasing you with its potential is that each of the cells is a stack-based processor element. For those not familiar with programming for a stack-based engine, the best example might be the old HP calculators that ran what is called a Reverse Polish Notation programming structure. Rather than store data to be processed in registers, everything is pushed onto or popped off of a stack; with the ALU element just working on the top of the stack.
For example, for a register-based processor, you would write {4 + 5 =}, but for a stack-based engine you would just write {4 5 +}. Programs written for stack-based engines can be very compact and run very fast. But they can also be frustratingly impossible for most programmers to work with because they force them to pay absolute attention to the order that operations are done in. In other words, when programming for a stack-based processor, you can’t just give variables names and then let your compiler tools worry about the exact machine level code that your program generates.
The linked YouTube video above contains a number of examples of program coding for a stack-based processor. The reason such code examples look so cryptic to those not familiar with programming in such languages is that the visual clues most programmers look for when reading a piece of source code aren’t there; those visual clues are hidden, so to speak, in the order that the operations are performed.
This latter observation is why stack-based programming languages like Forth never made it commercially. Writing in assembly for a register-based engine is already beyond the ability and patience of most programmers. Then, adding the extra frustration of also having to keep track of the order you do things in becomes “a bridge too far”.
On the other hand, when you’re working at the level of a tiny processor core that’s trying to make maximum use of the silicon resources available, stack-based engines come into their own and are probably the most efficient processing structure to use at this cellular level.
My goal for the next few months is to see if I can re-create the GA144 asynchronous array structure using discrete FPGA parts; in other words, recreate on a printed-circuit-board size scale, the structure that’s found in the GA144 part at the silicone level. By going this design route, I can then give myself access to all the input/output pathways that the pin-out of the GA144 part doesn’t give you. I will thus be able to explore the full range of functional possibilities that such an asynchronous array structure can bring to the table. The other advantage is that, by using discrete FPGA’s for the cells, I can give myself many more options in terms of programming at the cellular level of the array. (More on this last point in future posts.)
Saturday, February 7, 2015
New Directions
After letting this blog sit idle for several years, it’s time to revive it and send it off in a new direction. Between work and my kids, I haven’t had any time for personal projects for quite some time now. But since turning 63, I have been able to sign up for Social Security. That’s taken some of the financial pressure off my work schedule, so I now have a window of time again in my life to pursue some personal interests.
In the decade and a half since I started working on robotics, the field has matured significantly. Some of the ideas that I was playing with, like distributed processing, which was still unimplemented in any commercially available products 10-15 years ago, are now appearing as off-the-shelf products in the industrial robotics market. So I don’t feel I have anything more to offer in that direction.
As far as homeschool robotics and physics lab support, companies like LEGO, Pasco, VEX and Pitsco/TETRIX have fully taken over and now completely dominate the educational market in the public school, private school and homeschool arenas. So again, I don’t think I have anything as an engineer/designer to offer.
And while it is still something I’m strongly interested in, advancement in agricultural robotics has to wait on machine vision getting a couple of orders magnitude better than it is right now.
Even though I haven’t posted anything new here over the last few years, I’ve still been watching each of those areas in industry listed in my header. And in my wanderings in the fields of robotics and AI, there is still one area that remains open and undeveloped, and that’s where I’m going to focus my energies next and see what I might be able to produce.
This unexplored area falls under the heading of neural networks. This gap in development that I sense can be best expressed by noting that neural networks have, for all practical purposes, become a software/programming field. There is essentially no one working to develop the underlying hardware necessary to implement a practical neural network. The reason I feel I have an advantage is that I’m essentially a hardware designer first and foremost. And when I look at the software side, I see things that could be implemented in hardware much more effectively. But as I search through the literature on Google, I don’t see anyone developing these kinds of ideas at the hardware level.
In all of the hardware examples of neural networks I come across, the individual cells are hardwired together, right from the start. No one seems to have developed an underlying hardware platform that can spawn new connections between individual cells, grow them, and/or prune them when they prove no longer necessary. It would seem that if one could come up with a hardware system that could evolve new neural connections the same way the brain can, this would be the ideal platform for neural networks. I have some ideas on implementing precisely this kind of structure in hardware. So for the next few months, that is the direction I’m going to head in. And I will use this blog as a sort of journal to post my progress (If there is any, that is).
I may not have any luck in this endeavor, but it will be fun nonetheless.
In the decade and a half since I started working on robotics, the field has matured significantly. Some of the ideas that I was playing with, like distributed processing, which was still unimplemented in any commercially available products 10-15 years ago, are now appearing as off-the-shelf products in the industrial robotics market. So I don’t feel I have anything more to offer in that direction.
As far as homeschool robotics and physics lab support, companies like LEGO, Pasco, VEX and Pitsco/TETRIX have fully taken over and now completely dominate the educational market in the public school, private school and homeschool arenas. So again, I don’t think I have anything as an engineer/designer to offer.
And while it is still something I’m strongly interested in, advancement in agricultural robotics has to wait on machine vision getting a couple of orders magnitude better than it is right now.
Even though I haven’t posted anything new here over the last few years, I’ve still been watching each of those areas in industry listed in my header. And in my wanderings in the fields of robotics and AI, there is still one area that remains open and undeveloped, and that’s where I’m going to focus my energies next and see what I might be able to produce.
This unexplored area falls under the heading of neural networks. This gap in development that I sense can be best expressed by noting that neural networks have, for all practical purposes, become a software/programming field. There is essentially no one working to develop the underlying hardware necessary to implement a practical neural network. The reason I feel I have an advantage is that I’m essentially a hardware designer first and foremost. And when I look at the software side, I see things that could be implemented in hardware much more effectively. But as I search through the literature on Google, I don’t see anyone developing these kinds of ideas at the hardware level.
In all of the hardware examples of neural networks I come across, the individual cells are hardwired together, right from the start. No one seems to have developed an underlying hardware platform that can spawn new connections between individual cells, grow them, and/or prune them when they prove no longer necessary. It would seem that if one could come up with a hardware system that could evolve new neural connections the same way the brain can, this would be the ideal platform for neural networks. I have some ideas on implementing precisely this kind of structure in hardware. So for the next few months, that is the direction I’m going to head in. And I will use this blog as a sort of journal to post my progress (If there is any, that is).
I may not have any luck in this endeavor, but it will be fun nonetheless.
Tuesday, September 2, 2014
WIDJETS, a Postmortem.
This was a
response to a poster Steve Grimm at the LinkedIn discussion group Robotics
and Machine Intelligence, HomeBrew Robotics; originally posted on June 4, 2012.
The title of the original
topical post was “Does the robot community, hobby or professional, need
another "ready out of the box" platform or base with which to build
their experiments on?”
While the discussion
topic that this quote is from was intended as a reflection on the challenges of
marketing a new robotics product, it turned out to be a good postmortem review
of WIDJETS.
“…If you build
it, they will come.” Steve, literally all of your comments above sound just
like ours from a few years ago. But these days, if for some reason the subject
comes up, my wife and I just smile, slap our foreheads and say, “What were we
thinking?”
I can only speak
to the educational robotics area, but what has happened is the confluence of
two factors. First is the fact that the overwhelming majority of our K-12
teachers are not equipped, either in background or expertise, to teach a
robotics course. As a result, teachers always look for resources that come as
pre-packaged kits complete with lesson plans and teacher’s manuals. Also
important in any school’s purchasing decision is the availability of
vendor-sponsored workshops, training seminars, and corporate-sponsored robot
competitions like FIRST Robotics.
The other factor
is the incredible amount of money available in the form of budget set-asides
and private and public grants for STEM education initiatives; amounts so large
they defy any logic! The perverse aspect of this STEM grant-driven market
environment, is that as a business catering to educational robotics, ones
customers become effectively neither the students nor the teachers, but the
granting agencies.
Companies like
LEGO, VEX Robotics and Pitsco /TETRIX, have all adapted to this STEM
grant-driven market environment, tailoring their robotics products to both the
teachers’ and granting agency’s expectations. The amount of resources, in terms
of time and money, which it takes to play the game at this level, puts the
educational segment of the robotics market out of reach for any individual or
small company operation.
Unfortunately, if
you look at some of the product advertisements in magazines like Servo or
Robot, you’ll see that this STEM grant disease is beginning to infect other
segments of the robotics market, too.
My wife and I
naively thought that the homeschool market would be free from these influences;
but sadly, no. There turns out to be no end of free or low cost robotics
workshops available to homeschoolers, supported through agencies like the City
Parks and Recreation, and which are subsidized, either in part or in whole,
through STEM grants of one sort or another.
Just as an
example from the homeschool world, what small web-based effort is going to
compete with the likes of a Khan Academy (http://www.khanacademy.org) when the
Khan Academy benefits from grants from both Google and The Bill & Melinda
Gates Foundation?
“Build a better
mouse trap and people will beat a path to your door” was once valid wisdom, but
not anymore. What the flood of STEM grant money into the educational robotics
market has managed to do has been to destroy all of the normal market
indicators and feedback loops one would historically look at when starting a
new business venture.
So my humble
advice regarding any robotics business venture you might start. Just be
cautious.
Tuesday, July 16, 2013
What is the difference between a Robot and a CNC machine?
The following is a comment I recently posted at the LinkedIn discussion group, Robotics and Machine Intelligence, in response to the question in the title block above.
I have recently collaborated with a mechanical designer on a proposal to turn an older model robot arm into a plasma cutting system. This experience has left me pondering exactly this same question. Would this plasma cutting system be robotic because it's based on a six-axis robot arm, or CNC because it accepts a fixed tool path written in G-code?
Advances in the various CNC machine tool technologies are allowing the newer CNC systems to perform tasks that have traditionally been thought of as robotic. So as the traditional boundary between CNC and robotics disappears, and these two words become a distinction without a difference, we can either learn to live with that ambiguity, or attempt to bring the boundary between robotics and CNC back into focus by redefining what we mean by robotic
What that redefinition might be, I’m not ready to propose. But for my own personal usage, I’m finding that my notion of CNC is broadening to include any system that works via computer/ numerical control and then to reserve the term robotic for those systems that require an additional layer of independent decision making beyond that of simply running a hard-coded tool path.
For example, a CNC welding system would expect the work piece to be clamped in a known fixed position. While a robotic welding system would be one that, based on work piece and welding-head position information, could adjust its operation to a range of varying working situations.
Here is an example from YouTube of what I would call a robotic welding system,
In other words, I’m beginning to see CNC and robotic systems, not as two separate things, but rather I see robots as a subgroup within the category of CNC, i.e. robot = (CNC + AI).
I have recently collaborated with a mechanical designer on a proposal to turn an older model robot arm into a plasma cutting system. This experience has left me pondering exactly this same question. Would this plasma cutting system be robotic because it's based on a six-axis robot arm, or CNC because it accepts a fixed tool path written in G-code?
Advances in the various CNC machine tool technologies are allowing the newer CNC systems to perform tasks that have traditionally been thought of as robotic. So as the traditional boundary between CNC and robotics disappears, and these two words become a distinction without a difference, we can either learn to live with that ambiguity, or attempt to bring the boundary between robotics and CNC back into focus by redefining what we mean by robotic
What that redefinition might be, I’m not ready to propose. But for my own personal usage, I’m finding that my notion of CNC is broadening to include any system that works via computer/ numerical control and then to reserve the term robotic for those systems that require an additional layer of independent decision making beyond that of simply running a hard-coded tool path.
For example, a CNC welding system would expect the work piece to be clamped in a known fixed position. While a robotic welding system would be one that, based on work piece and welding-head position information, could adjust its operation to a range of varying working situations.
Here is an example from YouTube of what I would call a robotic welding system,
In other words, I’m beginning to see CNC and robotic systems, not as two separate things, but rather I see robots as a subgroup within the category of CNC, i.e. robot = (CNC + AI).
Monday, July 2, 2012
WIDJETS and LEGO-LOGO
WIDJETS
is short for Wild Iris Discovery Junior Engineer Training Sets. When this
project first started, we didn't have a name for it. In a moment of whimsy the term
WIDJETS just came out. It's an easy name to remember and has a fun connotation to it;
something that you want for a product targeted toward young people. Since then the
name has stuck. So until something better presents itself, WIDJETS is what we call it.
LEGO-LOGO was the first robotics product produced by Lego. It came on the market in the early 1990's and was the predecessor of LEGO-MINDSTORMS that came out in 1998.
Here is a video clip showing LEGO-LOGO in action. If you go forward to 3:20 you'll start to see glimpses of the control box. The control box was connected via a RS-232 serial link to either a MAC or IBM-PC running DOS. The PC programming was an IDE from which one could set up, program and run a project. The LEGO-LOGO software allowed one to create a GUI "front panel" to run their project from that included the kinds of user controls that you would find in a LabVIEW program. The actual programming for one's project was in the language LOGO. At 3:40 one can see a MINDSTORMS RCX Brick incorporated into one of the projects. You could do this because the RCX Brick still used all of the same motors, sensors and actuators from the earlier LEGO-LOGO product.
My first encounter with LEGO-LOGO came when my wife, Paula, was part of a summer STEM enrichment program for middle school girls that used LEGO-LOGO. As an engineer, I took one look at it and concluded I could do a lot better. I was already familiar with the new USB serial protocol from my work as a manufacturing engineer. At that time USB seemed to be the natural choice for a control box interface, such as the LEGO-LOGO one.
There were no USB Host Controller chips available at that time. This motivated me to create my own using some CPLD parts from Lattice Semiconductor. My first USB Host Controller was written in CUPL, a now defunct HDL language. I companioned this Host Controller with a Dallas Semiconductor DS80C310, 8051-type embedded controller to make my first WIDJETS control box. The work was published in a two-part article in Circuit Cellar Magazine: issues 108,109. This point marks the end of my first design effort.
About this time my son was born, so work on this project had to be put on hold. It
stayed on the shelf until the early 2000's when Cypress Semiconductor came out with an
8-bit USB Host Controller chip for embedded applications. I redid my old prototype
board, taking out the CPLD parts and replacing them with the new SL811HST part. At this
time I also upgraded the DS80C310 to an Atmel AT89S8252, 8051-type micro-controller
part. Once my revised prototype was running, I started next on writing a Forth compiler
for it.
It bothered me that it was taking 15 to 30, or more, 8051-machine instructions to
execute just one Forth instruction. To speed up the processor's ability to run Forth,
I tried the idea of adding a Forth "coprocessor" to the design. But within a week, it
became obvious that if I just replaced the CPLD part I was using for the coprocessor,
with a FPGA, I wouldn't need either the AT89S8252 or the SL811HST in the circuit. This
marked the end of the second chapter of my design effort.
The next prototype design was based on a single FPGA incorporating both a stack-based microcontroller and the USB Host Controller in one package. This design also included a small LCD graphics display and a 6-button keypad. Since the machine code instructions for my stack-based microcontroller were Forth words, it could run Forth programs with no time penalty.
I started working on the design of the individual plug-in motors, sensors, and actuators
that would be needed to complete the WIDJETS product concept. Then the problems started
to happen. To describe USB as a temperamental serial bus would be an understatement.
The system would run fine for minutes at a time, but then glitch and crash. After much
hair pulling, I finally traced the problem down to timing glitches that are inherent to
the USB interface itself. I originally chose USB 1.10 as my serial interface, since as
an industry standard it gave me access to a host of low cost parts to design around. But
by this time, USB 2.0 was already in play, USB 3.0 was getting ready to be released, and
USB 1.10 parts were disappearing from the market.
With the original reasons for selecting the USB serial interface no longer applying, there wasn't any reason left to stick with it. So I made the leap of faith to create my own serial bus; one optimized for the needs of the WIDJETS concept. This marked the end of the third chapter of my design effort.
Building on all of the painful lessons over the previous 10 or so years, the current design emerged. The project as described in a previous post was completed in 2010. Since then, life and finances have kept me from making any further progress. Hopefully, this year, I can get back to it and make some more progress.
LEGO-LOGO was the first robotics product produced by Lego. It came on the market in the early 1990's and was the predecessor of LEGO-MINDSTORMS that came out in 1998.
Here is a video clip showing LEGO-LOGO in action. If you go forward to 3:20 you'll start to see glimpses of the control box. The control box was connected via a RS-232 serial link to either a MAC or IBM-PC running DOS. The PC programming was an IDE from which one could set up, program and run a project. The LEGO-LOGO software allowed one to create a GUI "front panel" to run their project from that included the kinds of user controls that you would find in a LabVIEW program. The actual programming for one's project was in the language LOGO. At 3:40 one can see a MINDSTORMS RCX Brick incorporated into one of the projects. You could do this because the RCX Brick still used all of the same motors, sensors and actuators from the earlier LEGO-LOGO product.
My first encounter with LEGO-LOGO came when my wife, Paula, was part of a summer STEM enrichment program for middle school girls that used LEGO-LOGO. As an engineer, I took one look at it and concluded I could do a lot better. I was already familiar with the new USB serial protocol from my work as a manufacturing engineer. At that time USB seemed to be the natural choice for a control box interface, such as the LEGO-LOGO one.
There were no USB Host Controller chips available at that time. This motivated me to create my own using some CPLD parts from Lattice Semiconductor. My first USB Host Controller was written in CUPL, a now defunct HDL language. I companioned this Host Controller with a Dallas Semiconductor DS80C310, 8051-type embedded controller to make my first WIDJETS control box. The work was published in a two-part article in Circuit Cellar Magazine: issues 108,109. This point marks the end of my first design effort.
 |
| WIDJETS Control Box, Rev: A, the original bread board |
 |
| WIDJETS Control Board, Rev: B. |
The next prototype design was based on a single FPGA incorporating both a stack-based microcontroller and the USB Host Controller in one package. This design also included a small LCD graphics display and a 6-button keypad. Since the machine code instructions for my stack-based microcontroller were Forth words, it could run Forth programs with no time penalty.
 |
| WIDJETS Control Box, Rev: C |
With the original reasons for selecting the USB serial interface no longer applying, there wasn't any reason left to stick with it. So I made the leap of faith to create my own serial bus; one optimized for the needs of the WIDJETS concept. This marked the end of the third chapter of my design effort.
Building on all of the painful lessons over the previous 10 or so years, the current design emerged. The project as described in a previous post was completed in 2010. Since then, life and finances have kept me from making any further progress. Hopefully, this year, I can get back to it and make some more progress.
Saturday, June 16, 2012
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.
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.
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!
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.
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.
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. |
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 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 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 |
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.
Sunday, May 27, 2012
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 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.
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 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.
Subscribe to:
Posts (Atom)