New Project -- Driving 30 Steppers

[bwevans]

Im starting a new project that involves 30 (really) unipolar stepper motors of the 5v variety that must be simultaneously (mostly) orchestrated in some manner. Previously I have made a small pcb for each stepper consisting of an 08m, ULN2003, associated resistors (ala schematic in manual section 3 pg15), and a low value power resistor and the program makes gratuitous use of the toggle command.

This works well and good when you are making 2 or 3 steppers hum away but now we are talking 30. I would also like to move from the small separate pcbs to a larger all inclusive version and I am curious if I can get them to exhibit some rudimentary flock behavior. (However flocking isnt really the problem here.)

Plan A, an extension of what I had been doing, is to cram 30 08ms & 30 ULN2003s on a pcb with a 1 wire serial network connecting to a master that decides which motor lights up and when. Plan A is expensive and Im concerned about jitter in the movement of the motors every time information is received. Plan B involves moving to fewer 18s or 28s having each one drive a group of steppers (via same ULN2003s) and look into a master running a few digital potentiometers to clue the group leaders into a desired movement. This gets away from the slower serial comm but Im afraid toggle'ing the extra motors will slow things back down again. Other possibilities might include shift registers or some buffered decision making process.

My question is what kind of big picture plan would you consider for driving & orchestrating 30 steppers using ULN2003s? Any tips or suggestions for tackling this huge project?

Thanks in advance,
Brian

 

[Jeremy Leach]

Quick initial comment - Think about your power supply !

 

[moxhamj]

What an interesting project idea! For a power supply, I'd look at an old PC power supply. You just need to load up the 12V and 5V with a bit of a load (eg an old motherboard, or a couple of 5W resistors).
08Ms may still be the most cost effective. How quickly are all the steppers going to be moving? I'm thinking that 2400 baud is approx 300 bytes a second, so if a master sent 30 bytes out onto a single wire bus it would take 100ms. If one update on positions is sent per second, each 08M would have say 850ms to move its stepper, then they would all listen for an update. Will that be too much jitter?
Or (just brainstorming here), send the position data as pulse widths read with pulsin, and then a few 28s are given the job of sending out all the pulses.
Or send the position data as analog voltages, with a few 28s doing pwmout.
Or sample and holds eg, one 28 and 5 4051's with 30 caps, and each 08M reads its value.
How fast are all these motors moving?

 

[bwevans]

Yeah power supply was an issue until I found a nice 40A 5v supply for $40us that will keep me from hacking another pc power supply. I dont expect more than 20 or so on at one time. I will naturally run a separate supply for logic.

Re movement, for now lets say each motor will twitch stepping 5 steps in one direction and immediately return. Imagine all motors in a line with the twitching 'bristling' up and down the line. This is where some basic flocking comes in. The motors immediately near the epicenter will have to 'decide' to twitch or not while the epicenter moves along the line.

OOOOOIOI*OIIOOOOOO...
OOOIOII*IOIOOOIOOO...
IOOIIO*IIIOOOOOOOO...

*=Epicenter, O=Off, I=On

So the epicenter moves along the line, the motors nearest have the highest probability of twitching. The epicenter moves and the process repeats.

I have a feeling to prevent stuttering this may have to move fairly quick. The pulse in could work. I was thinking each 08(m?) given a unique ID could read an analog value from a digital pot (controlled by a master) to know where the epicenter was and make a decision based on probability of whether or not to twitch. Rinse repeat. This should move faster than serial comms or maybe even pulsein would allow...?

Im open to anything!
Brian

 

[wilf_nv]

I would suggest that "flocking" behaviour is not a function of centralized commands but rather of response of individuals in a group to local neighbourhood conditions.

Like cellular automata (google Conway Game of Life) , each picaxe controls it's own stepper and all picaxes use the same simple algorithm to respond to the state of its near neighbours. When a disturbance occurs, the effect ripples through the group and causes complex emergent group behaviour such as flocking and other local and global dynamic patterns some of which are self sustaining.

Such GoL systems do have a central clock. The picaxes can use a common clock input which also serves as a communications bus to simultaneously broadcast changes to algorithm parameters such as coupling constants, thresholds, time delays, etc.

One variation could have a dominant cell at the center that can initiate action based on some internal central pattern generator or external sensors. This "disturbance" causes its nearest neighbours to respond, which in turn causes their neighbours to repond, etc. on successive clock pulses as the disturbance ripples out from the center.


Edited by - wilf_nv on 24/01/2007 19:53:42

 

[moxhamj]

This sounds like a neural network simulation of sorts. Neural networks tend to have one single output, which in neurons is a frequency, but is functionally equivalent to a voltage, or a binary value sent serially or a pulse width. The harder bit is that neural networks have lots of inputs - eg in your case the inputs are from a number of motors near the one that is moving. Picaxes only have a limited number of inputs.

If you want total flexibility, every motor/picaxe needs to know the value of every other motor/picaxe. If 30 motors have 30 inputs each that is 900 physical connections, so some other smarter system needs to be implemented.

One possibility is for there to ba a master picaxe. This might send out serout messages to each picaxe asking "what is your position?" If the timing is such that the receiving picaxe is ready for the message, then it won't waste too much time with serin. Then when the master picaxe has collected all the values, it sends out a series of 30 bytes to the data bus and each motor/picaxe can do its own calculations on these values.

Having built these sorts of things, my comment is that there is a certain level of complexity, maybe with about 10 units, where the time taken to build the system becomes much greater than the (fun) experimentation time.

I'd say the easiest way to make this work is to do the entire simulation on a PC, and then send out each motor position via the serial port. The picaxes then only have the job of taking a byte value and turning it into a motor position. The calculations for the interactions between the motors as, say, a wave spreads down the group, are done on the PC.

Edited by - Dr_Acula on 24/01/2007 22:43:50

 

[wilf_nv]

Dr.Acula penned:

<i>This sounds like a neural network simulation of sorts.

snip

Having built these sorts of things, my comment is that there is a certain level of complexity, maybe with about 10 units, where the time taken to build the system becomes much greater than the (fun) experimentation time. </i>

I would say there is little resemblance between CA and neural networks. Neural networks are fuzzy while CA are quite deterministic. You could construct a Turing machine from CAs.

The biological like behaviour of CA becomes apparent in groups above some minimum number of cells. A single CA is no fun at all.

While CA widely inhabit computers, I have always wanted to design a hands on electromechanical version.

wilf

 

[moxhamj]

I suppose &quot;neural network&quot; encompasses a whole range of things from fuzzy logic to quite deterministic logic. The fuzzy circuits for memory are quite different to the very deterministic neural circuits in the retina.

I was thinking more of the practicalities of programming 30 picaxes to respond when the one next to them responds, and then wanting to change the rules and having to reprogram them all. Maybe 28s or 40s might be better.


Edited by - Dr_Acula on 25/01/2007 01:07:01

 

[wilf_nv]

I first learned of the Game of Life many decades ago, reading an article by John Conway in Scientific American where he described a virtual reality of cells battling for survival on a computer screen.

A few simple rules cause cells to form dynamic colonies which eat or are eaten by competing cells and colonies. Some colonies evolve and some are steady state. Some move and some are static.

Individual cells live or die (on /off)
depending on the state of their neighboring cells.

The 2 rules of the GAME of LIFE state that:

An living cell survives if surrounded by 2 or 3 live neighbors

A dead cell comes alive (a new cell is born) if surrounded by 3 neighbors.

Under all other conditions a cell will die of either too few or too many living neighbors (of loneliness or overcrowding).

Here is an example of single cellular automaton implimented with a PicAxe 08

<A href='http://www.user.dccnet.com/wrigter/picaxe/picaxegol.gif' Target=_Blank>External Web Link</a>

To play the game of life you need a 2D array of picaxe cells eg 8x8 with each cell connected to 8 surrounding cells with a resistor.

These resistors form a summing network that allows a cell to determine how many of its neighbors are alive.

The picaxe cell determines the state of its surrounding 8 neighbors using the 8 resistor summing network, each input of which is connected to each neighbor output (pin0).

The voltage at the ADC4 input is measured when the clock command occurs on serial input 3 and then the cell output is updated.

If any two neighbours are alive the resistor network output is 2/8Vcc.

If any three neighbors are alive, the resistor network output is 3/8Vcc.

Besides lighting the LED, a bi-directional actuator (with limit switches) is shown that could move one of an array of mirrors to project the GOL on a very large screen (projected on the clouds?).

The Clk line is a serially broadcast command word that synchronizes the update of all cells and also serves to broadcast other commands that initialize cells to a known state or change the thresholds of life and death, etc.


wilf


Edited by - wilf_nv on 25/01/2007 08:17:47

 

[Rickharris]

Suggestion - Why not use a &quot;normal&quot; small DC motor in a similar way to the beam robots. The motor sits in the middle of 3 AA cells to power it with the shaft facing down and resting on the floor. When ends of the cells provides the other support so it leans slightly to one side. When the motor is active the robot moves erratically in a given direction. It can tilt, e.g. when the motor is reversed and will then move off in a different direction.

This is easily controlled by a picaxe 08 and simple sensors or even using typical solar beam electro mechanical techniques to produce quite lifelike behaviour.

As an alternative you can use the motor with an off centre weight to jiggle the bot around in semi random movement - again a beam technique.