H-Storm News

2005 Jul. 15

The newest GCC, version 4.0.1 for ARM targets is available for download. For this release I've finally succeeded getting through the whole build process without errors, which means that the toolset is complete with the ADA tools and runtime libraries. Note, however that a large percentage of the runtime would be disfunctional even if it linked, since the underlying OS support might be missing. As one example don't expect ADA sockets or threads to work.

2005 May. 14

I've built and published the GCC 4.0 toolset for ARM targets. This is actually the second attempt, the first one didn't include the Fortran and the Ada front-ends.

2005 Apr. 11

I'm almost done with the H-Bridge. I've fixed the last known problem with it. It now supports go-to-distance operation, where you supply it with a top speed, an acceleration and deceleration speed, and a distance to travel and the bridge will drive that far with a nice trapesoid speed-profile. Since it uses actual speed and distance values plus the PID loop for controlling the speed, it pretty accurately stops at the desired location, with much better than 1% error. Note however, that the speed-information is acquired using back-EMF and distance is calculated by integrating speed over time, the actual position will be much less accurate, even though the device thinks it did a great job. I will run some measurements on the precision in real-world environment once my robot base is completed enough. I will try to add some video to the website as well at that poing. I've also added torque limiting which is basically a limit to the maximum PWM modulation. This is helpful when the motor that is used is rated for a lower voltage than the battery is used.

I'm planning on changing some minor things in the HW design (basically replacing the low-side drivers with a cheaper, higher-speed driver). I will update the webpage with the new design in a couple of days.

2005 Mar. 27

A lot of things has been going on in the past two weeks (taxes, home improvement, you know...) but I've managed to have some progress. There were two small improvements in the H-Bridge:

Odometer - this is a 32-bit counter that adds up the sampled back-EMF voltage (which is proportional to the speed).
Acceleration limits - independently programmable acceleration and deceleration values. For this feature to be usefull, I've scaled the speed-request value up 4 bits (so now it is in the -0x3ff0 - 0x3ff0 range).

I've redesigned the PCB quite a bit. I've replaced the custom programming connector with the 6-pin standard ATMEL one. I've also removed the phone jacks for the TWI interface and replaced them with 6-pin IDC connectors. Though the phone jacks are a clean solution they have a fatal problem: most standard phone wires are assembled with crossed wiring, i.e. pin1 is connected to pin4 and pin2 to pin3 on the two connectors. While that's OK for a phone, it's quite not OK for micromodules: not only it would cross-connect the clock and data lines, it would also mix up GND and VCC. That would take care of the digital circuits on the board for good... So while I liked the idea, this option is way to dangerous - as a result, I removed it from the board. All other micromodules will get this update in the near future. I've also added support for an external shut-down switch: when the switch is open, both high-side FETs are turned off, leaving the motor un-energized. The switch itself is not in the high-current path, so it can be any type of small-signal switch or even a digital output. The last modification was the inclusion of mounting holes on the board.

2005 Mar. 14

I haven't updated this page for a while but it doesn't mean that nothing has happened. I was quite busy bringing up the H-Bridge µModule. I have everything in place for the back-EMF control loop, and made lots of experiments with various motors and parameters. I discovered that a regular R/C car motor can easily trip the 20A over-current protection when used in low RPMs (even without load). As it turns out this is due to the fact that with low-RPMs there's practically no back-EMF generated thus in the 'on' period the full battery voltage is applied to the motor windings. True, that the duty cycle is quite low, so the average current is low as well, but the momentary current over the motor can be quite high, as it turns out more than 20A. I had to work around this problem and have found a way to throttle the power delivered to the motor but keep the bridge operational under overload conditions.

I also had truble measuring the back-EMF voltage accurately. This was caused by the the commutation noise and the uneven feedback voltage due to non-perfect field inside the motor and the switching windings. The commutation noise can be mitigated by a low-pass filter in the analog sampling circuit and the unevenness of the feedback voltage can be dealt with computing some kind of statistics over the 'off' period. Average is one obvious example but I went for minima searching. This works better when only a few samples are collected (high RPM or high-load conditions when the 'off' time is pretty small) provided that the input signal is smooth enough - another benefit of the low-pass filter in the analog section.

I've also implemented a PID loop and fiddled around a lot with various paramters. In the end I've figured that 16-bit precision is enough, with 10-bit input signals (from both the request input and the back-EMF input) and 8-bit control signal. I've found a rather clever way of limiting wind-up in overload conditions so recovery from such situations is quite fast.

I've also worked a lot on the TWI implementation and I think I've finally made it working. There are some places where code should be clean up and factored out, but the main logic is there and is working. I also have to come up with a good serial communication protocol, that is efficient and can be translated back and forth between TWI.

I started reaching the limits of the code-space in the ATMega48 controller I've used (4k that is), so I'm not sure how much of the following TODO list will made it to the final version, but here it is:

Add current reading and integration for power usage estimation
Add acceleration, deceleration limits
For that, I'll need better resolution in requestvalue. Probably 4 or so additinal bits
Add speed integration to estimate travelled distance
Add 'go to distance' mode with trapezoid speed-profiles
Add serial interface
Add servo-type interface
Add optical encoder support

Some items on the list are must haves, others are rather trivial to do. I might end up sacrifising the serial interface (in a way, that an alternative FW would use the serial interface as opposed to the TWI), and the optical encoder support. The latter is more challanging that it first sounds: the control loop works at ~120Hz, and it can't really go any slower than that, loop-stability would suffer. Now, even if the encoder would produce 200 counts per rotation and the motor shaft would rotate at 500 RPM, this would give us around 14 increments per sampling. Thats not a very accurate speed measurement, back-EMF can certanly beet that. You can get clever and instead of counting the ticks, count the time between ticks, but that method would stop working in higher RPMs. You can also combine the two methods, kind of like frequency counters work, but as you can see, things get complicated easily. Not to mention the mechanical complexity of the encoder plus the added price for the detectors and the wheel.

I would not have thought this but I think back-EMF is actually cheaper and easier to do PID control on than quadrature encoders.

Last but not least, I've added persistent storage to the code so that PID control parameters and the TWI address can be stored in the EEPROM and re-loaded upon powerup. This provides a simple operating mode, that does not require the full PnP discovery protocol implemented in the controller. The PC can be used to program the inital parameters and all the robot controller has to do is to update the speed request parameter.

2005 Feb. 22

I have now some preliminary code for the TWI implementation. I will soon update the web-site with it. It's still not final but what's mostly left is testing. I had serious problems with the TWI implementation in this AVR controller, I will probably rant about at some later time. For now lets just say that it almost made the project impossible. I had to completely re-architect the PnP implementation to work around these limitations and as a result the final protocol is completely different from the SMBus ARP protocol. I will have to update the documentation with the new information. Anyway, some early experiments show that the conflict-resolution and dynamic address assignment works even with multiple devices on the bus.

I also started putting together the H-Bridge µModule. The power portion is ready and so as some initial firmware where the bridge can be controlled from a PC through the serial port. The feedback amplifiers are not populated yet and the firmware lacks any control loop at the moment but that will follow soon.

2005 Jan. 30

Over the weekend I've managed to spend some time with the 32-channel servo controller. I've updated the project page with the new information. Basically, the HW is completed and works, the firmware lacks the TWI interface, but has a rudimentary serial protocol and there's a simple host application to showcase the capabilities of the controller. Over the course of the development I've encountered many problems with both the AVR-GCC compiler and the AVRStudio simulator. Just a few:

AVR Studio fails to simulate correctly the TSM bit (i.e. syncron start of both timer channels
AVR Studio fails to simulate correctly the fact that TIMER0 and TIMER1 are running from the same pre-scaler and thus increment at the same time if the same pre-scaler output is selected.
AVR Studio doesn't simulate well the pre-scaler settings for TIMER0. It does however for TIMER1
The include file iomx8.h that comes with WinAVR (avr-gcc version 3.4.1) has incorrect definitions for many of the timer register bits.
Avr-gcc doesn't seem to correctly handle switch statements when compiled for size (-Os). At least in my case it simply removed the whole statement. If you download the sources thats the reason for the if ... else if ... else if statements in the statemachine code.

Not bad of a bug-list for just two days of work, heh?

2005 Jan. 23.

I've finished the initial assembly and testing of the new PCI CPU card. It works nicely and after spending two days tracking down a bug in WinIO, this morning the memory mapped operations are started working as well. I wrote a small utility that can be used to dump the configuration of the PLX chip and also to update the on-board EEPROM content. The EEPROM content can be constructed with the PLXMon2000 demo software that can be downloaded from PLX. The default configuration that I've created allocates four 16Mb memory zones for each available chip-selects. The lower 8M can be used to normal memory accesses and the upper 8M for simulated DMA accesses to the H-Storm bus. The wait-states can be programmed independently for each memory range so peripherals with different speed can be used on the board. I made some small changes to the design since the initial prototype. The most important thing is that the local-bus clock is now optionally derived from the PCI clock, saving an expensive clock generator.

2004 Dec. 17.

The next batch of PCBs arrived yesterday. I hope I'll have time to assemble at least some of them over the holidays, so that I will have some new stuff to put on the site. Some sneak preview:

There supposed to be a DC-DC power supply that can be plugged into any H-Storm connector and can provide 3.3V at 5A with 2.5V and 1.8V at 3A. It also contains a 5V at 5A power supply. All these are switching step-down converters. It also contains a 5V 150mA standby power source using a simple linear regulator. The last power source is a 12V, 1A step-up step-down converter. The input power can be anywhere between 7V and 16V. As you probably have guessed this supply should be able to power a micro ITX motherboard along a complete H-Storm system from a variety of batteries. What is unique to the supply is its wide input range: I could find one off-self ATX DC-DC converters that can run from both one and two standard 7.2V battery packs.
I've included a fast-Ethernet H-Storm peripheral card using the ASIX AX88796 chip. This chip is supposed to be NE2000 compatible so in theory should be easy to interface with. I've read some comments on its MII interface being hard to deal with. We shall see...
Another interesting peripheral card in this upcoming update is an FPGA board based on the Xilinx Sparan-2E series. Apart from the FPGA (XC2S100E) it also contains 512kB (256kx16bit) of fast SRAM and a PLL clock source. If all goes well, the FPGA can be programmed from either an on-board FLASH memory or by SW from an H-Storm CPU card. Of course the JTAG programming and debugging interface is also available.
This card is a bit special though: instead of connecting most of the available pins of the FPGA to the H-Storm connector it contains headers to which some of the pins are routed. The user- defined side of the H-Storm connector is left unconnected. The reason for this decision is two-fold, but the main one is that these connectors allow me to connect the FPGA directly to two CMOS image sensor panels.
There's a somewhat special CPU card in this batch as well: this is a PCI board with a PLX 9030 bride chip on it. This card � if works as I intended � will turn a regular PC into an H-Storm master device being capable to function as a regular H-Storm CPU card. In other words this card is an H-Storm - PCI bridge. Hopefully this solution will bring back the golden days of ISA-bus based PCs where designing and adding peripheral cards to a PC was within the reach of hobbyists. One of the cool features of this card is that you can piggy-pack an H-Storm peripheral card onto it, provided that you use straight connectors instead of the standard 90-degree ones. The card also handles the 5V-3.3V transition � most PC PCI buses are 5V based, while the H-Storm cards use 3.3V devices.

Let's see, what else? Oh, yes, there are going to be a bunch of small AVR based modules, called micro-modules. These little devices will attach to the H-Strom PnP bus only and perform various simple peripheral functions. Since the PnP bus is really just a TWI interface (AKA I²C) these devices should work with any device that's compatible with these standards. All mirco-module devices will support the H-Storm plug-and-play discovery protocol so there's no (SW) limit on the number of devices that can be attached to the same bus. There's also no limit in which configuration these devices are attached to the bus either: you can connect ten identical devices to the same bus if you whish or ten different ones, it doesn't matter. As you all know the number of devices connected to a TWI bus is limited by the speed of the bus, the value of the pull-up resistors, the strength of the drive circuits and the load capacitance of the devices (plus the cables). The practical limits in this application will be between 10 and 20 if my calculations are correct.

One card will be a 20A H-bridge motor controller with a whole set of feedback options: it will be able to monitor the current drawn by the motor as well as the voltage across the motor pins. These measurements will provide good short-circuit protection (though there is a HW shutdown as well) but also will provide means to use the motors' back-EMF to control the feedback loop. The module also has inputs for an optical quadrature encoder so the control loop can be closed that way as well.
Another little device will work as a R/C servo controller. Again, it attaches to the H-Storm PnP bus and provide control signals for up to 32 R/C servos. The resolution is supposed to be quite good, around 100 different positions for each servo.
There's another small module that attaches to a standard serial port (level shifters included) and provides H-Storm PnP bus signals. This module can be used in case you would like to control any of the micro-modules from your PC for example. You can think of it as an RS-232 - TWI bridge.

The last interesting circuit in the batch is a logic probe. Now, you might say, that's quite simple, but there are a couple of interesting challenges: I wanted to build a probe that can display not only low and high logic levels but high-impedance (�Z') state as well. For that I needed to pull the input of the probe to mid-power with two resistors. Of course I didn't want to introduce any additional loads to the tested circuits so these resistors had to be rather large, in the mega-ohm range. I also wanted my probe to work up to 100MHz (even higher analog bandwidth is required for that) so that I can debug fast circuits with it. Now the challenge is this: build a window-comparator with 250MHz bandwidth and a couple of mega-ohm of input impedance or in other words almost zero input offset current. We'll see how successful I was in that, but it turned out to be a non-trivial task.

So as you can see there's work to do here, a lot of it. But for now, happy Xmas for all, and see you next year!

2004 Sep. 1.

The H-Storm web-page is online.