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.

WIDJETS Control Box, Rev: A,  the original bread board

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.

WIDJETS Control Board, Rev: B.

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.

WIDJETS Control Box, Rev: C

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.

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.