brains without microcontrollers?

[Gopher]

I'm designing a very simple 6-legged walker. Eventually, I may have no choice but to go to a microcontroller, but I'm starting very simple, initially just a walking chassis with no sensors at all, then adding on sensors and their supporting logic one at a time.

For the first version this is no problem at all; it'll just walk constantly when on, so aside from a power switch, it's just a matter of sending the correct power to the two motors. Once that works, I'll build the H-Bridges and controllers for each motor. I've already designed both of these circuits with no problems; they will just convert three signals, "Go," "Left-Reverse" and "Right-Reverse" (each controller will just take "Go" and the reverse signal for it's side) into the A/B inputs for each h-bridge.

Those extremely simple circuits are waiting for implementation/testing, while I've moved on to designing the next circuit. This is where the fun begins. The next circuit will take in data from photoresistors, and output the three control lines for the motor controllers (namely, Go, reverse-R, and reverse-L). Everything I've seen about photoresistors assumes, not surprisingly, that you're using a microcontroller.

I may have to resort to a microcontroller, but I'm not giving up that quickly. Anyone worked with photoreceptors without a microcontroller before? All I want to produce is simple photovore behavior, so I need a way to compare the resistance of two different photoreceptors.  Ultimately I'll also want to stop when it finds a bright enough spot, but that I think can easily be done with voltage triggers.

I sat thinking about this last night, and the best I could come up with was a fairly complex circuit involving capacitors and flip-flops. Anyone tackled this kind of thing before, or just got any general advice?

[Admin]

Ok so I am a little biased towards using microcontrollers . . .

Although there are advantages to not using one, such as compactness and efficiency of circuit (power, speed, etc), what hardwiring lacks is flexibility and intelligence. With software you can easily tweak in seconds, with hardwiring you have to solder and unsolder components.

I also admit that microcontrollers do have a sharp learning curve, as I struggled when I first used them too, but they offer so much for robotics. Your current robot design is a little small for a microcontroller . . . but just keep this in mind for when making your decision!

[Gopher]

Oh, I'm aware of the advantages, and I have worked with microcontrollers before. I'm a professional programmer, and while these days the work (and therefore I with it) is mostly in high-level languages - php, java, etc - I've written in more languages than I can remember, including writing machine language for half a dozen different chipsets.  I used to have a partner in crime back in high school: he did hardware, I did software. We lost touch years ago, after going to colleges on the opposite ends of the country, and I've hardly done any robotics since, though I have done a few simple electronics projects over the years.

Anyway, enough personal history. Practical conciderations aside, not using a microcontroller is just one of the goals I've set myself for this project. Making a roach brain in software is relatively trivial, I want to see what I can do in pure hardware, to make myself flex my brain in a different way than it's used to. Though I rarely construct them, I really enjoy designing logic circuits. To minimize the inconvenience of hardwire troubleshooting, I'll be testing all the individual circuits  on a solderless breadboard before I begin building the prototype. I'm also applying everything I know about modular software design, which is why you hear me talking about particurlar subsystems; when I have all subsystems working independently, I can go back and optimize them before I put them all together.

The best I've come up with so far for the light sensors is this:
Each sensor outputs to a capacitor. The brighter the light, the faster the capacitor will fill and discharge. When a capacitor discharges, it's output is sent to a set bit on a simple latch. The latch produces the output, indicating which sensor filled it's capacitor first. A flip-flip is toggled by the discharge from either capacitor (each has it's own); when it is turned on, a signal is sent to a transistor which blocks flow to the capacitor, preventing it from re-charging. When both capacitors discharge, both flip-flops are reset.

There's more details required to make this work than I'm covering here of course, but my real concern is that I'm uncertain whether a capacitor can be used in this way at all? Also, can you buy d-latches or flip-flops as stand-alone components, or will I have to build them from transistors?

[Admin]

There are several ways you can go about it . . . Ive only done this in software, but it will work in hardware too . . .

Its called the 'split brain' approach, in that there is no comparison of sensors on the sides. Here is how:
A circuit on the left side reads from the left sensor, and directly controls motor speed on the right side only.
A circuit on the right side reads from the right sensor, and directly controls motor speed on the left side only.

Neither side has any idea what the other side is doing, but yet still it will make 'intelligent' decisions on which way to turn. If both sides get equal light, both sides will drive at the same speed, hence it will go forward. If the left side gets more light, the right wheel will go faster, and the robot will turn left - where the brighter light is. Its basically differential drive.

I am not sure exactly what circuit you would use . . . but here are the steps:
photosensor/phototransistor
amplify signal (op-amp?) so that its rail to rail output (spands a good range)
signal controls a mosfet/transistor (transistor must output wrt signal amplitude)
mosfet controls motor

The problem that you might have is that the mosfet cannot be an on/off switch, but vary linearly with the signal amplitude. Anyone know how to do that? 
Perhaps the signal is a varying PWM? 555 timers?

[Gopher]

Hmm. I can see how that would work; I need to be able to toggle between seeking light or seeking shadow, but that's not a big problem,  just a bit of control logic. Definately a hell of a lot simpler than the lines I'd been thinking along.

Thanks! I think that idea will work pretty well.

[dunk]

hmm, don't know if i should complicate the matter just when you appear to have settled on a design but this would be worth considering too...
have you considered using a comparator ic?
these devices compair 2 voltages and tell you the highest.

for your roach, connect the photoresistors between the 2 input pins of the comparator and +ive power.
connect the 2 motors to the 2 output pins.
if left photoresistor is brightest, power right motor.
if right photoresistor is brightest, power left motor.

there's an example of a line following robot built using one of these here:
http://www.robotroom.com/Sandwich.html

dunk.

[Admin]

Using the split brain method, to toggle between photovore and photophobe, just swap which side controls which motor.

So if the left sensor controls the left motor, the more light it recieves causes the left motor to go faster - or turn right and away from light.

I think the comparator ic method that dunk metioned would be easiest, but its completely binary - meaning the possibility of oscilation if both sensors get about the same amout of light. The split brain method gives you a smooth curve between which direction to go . . . but tends to go real slow in low light situations.

[Gopher]

dunk: That's actually something I meant to look for, but I wasn't sure if they existed or not. Just did a search and found several that might do the trick right off the bat; thanks for reminding me!

I don't know if I'll actually implement a true split-brain, or simply apply that same logic. I'm planning a modular design; the side panels will have the electronics for controlling the legs on that side, reduced to two digital inputs - one for on/off, one for forward/reverse. the light sensors will be on another panel. In a way I'm designing it around a simple microcontroller, even though I'm not using a microcontroller; I want to be able to take it apart and insert a different logic board, attach the desired sensors, and just connect a few wires to make it go. In theory I could reuse the same logic boards with a wheeled chassis, or even with different sensors - a different sensor circuit could use accelerometers instead but return the same two-bit turning information to make the same light-seeker logic into a hill-climber.

It's more work this way, I know, but I'm all about delayed gratification. 

[Admin]

More work, but I think in the end you will come out with a much greater understanding in electronic control. We dont build things we know exactly how to do . . . trying something never done before is part of the fun 

[Gopher]

Absolutely! When you're learning, the harderst way usually is the best way.

[sdk32285]

while not much different then a micro you can use an FPGA. this way the work/programming is all software but its technically still hardware. Also with a FPGA more than one event can happen concurrently.
Also, you can buy stand alone D flip flops but that would probably end up being the same if not bigger than the FPGA

[Gopher]

Well, I don't think I'll need a lot of flip-flops; I'll use a comparitor ic in the sensors. I may require a few bits of internal status info in the final logic controller, but that's it. And while an FPGA might not technically be breaking the "no microcontrollers" rule , is definately goes against the spirit of it. I don't expect the final logic core to be too complicated. The final version will have two photoresistors, two tactile sensor "antenna" for detecting ledges, a voltage trigger attached to a solar cell, and a mic. Steering control is determined based on the photoreceptors; when hiding instead of charging, the photoreceptor input is reversed first. If both antenna are off the ledge, it backs straight up unil only one is off. It then turns away from the edge (both antenna will be on the front, and will have a ground contact far forward and further to the sides than the feet) until the second antenna is back on the ledge, then finally returns to it's standard logic. If it works out, this will produce a path that "bounces" along an edge if the bot is attracted to a light source beyond it's reach; it might "starve" for lack of light, but that's better than falling off the ledge and dying on the floor (or being eaten by the dog).
Anyway, busy working much of the day but I've made progress on the design; I should have a complete parts list put together soon, and then I can start scrounging and shopping. Is it just me, or is $1 apeice for nylon gears a bit pricy? Most places don't list prices, and I've found very few that seem to sell the kind of tiny plastic gears I need at all...

[Admin]

The cheapest plastic gears are the ones they sell as replacement gears for servos, since they are mass produced. Just search for places to buy 'servo replacement gear sets.'

[Gopher]

Thanks for the tip, I'll try that; I've found a couple of sites that seem to have a good selection, though they don't give prices for anything; the hard part is finding the kind of extremely tiny gears I need; I've scavenged a few from misc. small electronics, proving such gears exist, but all I can find in online catalogs below about 3/4" P.D. are metal.

:goes to search for servo replacement gears...:

[edit]
:60 seconds later:
Why is it so many places fail to give any dimensions on these things? :sigh: