Electronics > Electronics

brains without microcontrollers?

(1/3) > >>

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?

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!

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?

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:
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?

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.


[0] Message Index

[#] Next page

Go to full version