Well, pathetically enough, I’ve gotten hooked on yet another project (is this the fifth that I now have planned?!).
Now I know what Jim feels like!
Anyhow, here’s the working schematic that I’ve got going.
I’ve yet to assemble a complete schematic, since I wanted to post this and ask you guys to give it a look-over for any more obvious misconceptions, first.
How’s it look? img1.putfile.com/thumb/8/24220565627.jpg
I think I’ve explained the logic at the digital level well enough, but here’s the overall behavioral intentions from the robot’s point of view:
High priority:
Robot will turn loosely right when detecting arena edge on the left.
Robot will turn loosely left when detecting arena edge on the right. Low priority:
Robot will go forewards when detecting an object in front.
Robot will turn in place, sharply to the right when detecting an object in back.
Robot will turn loosely right when detecting an object to the left.
Robot will turn loosely left when detecting an object to the right. Lowest priority.
Robot will not go anywhere unless it detects an object or finds itself close to the arena edge.
(I might be changing that if I can’t get the rangefinders to cover the full arena adequately, but that’s how it now stands.)
I still have to add in a way to delay 5 seconds after pressing a button before the robot starts activating.
Methinks I’ll just use a 555 for that.
Woops!
Me just realize that Putfile didn’t much desire to keep my 300 pixel-per-inch resolution.
Tomorrow, I’ll upload the pic in broken-up segments so it’ll be readable.
If anyone would like the real deal, I can send them the .sch or the full .jpg file by email.
I resized the images so that they’d be readable, as promised.
Right now, my schematic uses transistors for driving the motors.
I might have to move up to FETs, but I doubt it, since I’ll be using el cheapo servo motors.
In any case, I’m not much worried about that at this point.
No matter what I use, it’ll be in the same general H-Bridge design.
Here’s the H-bridge logic: img1.putfile.com/thumb/9/24311452612.jpg
Upon close review, it seems that I’ll have to adjust the sensor control a bit.
Right now, I’m assuming that no two object sensors (SHARP IR rangers) will ever trigger at the same time.
If this did happen, there would be some nasty shorts between those sensor’s respective flipflop outputs.
Now that I think about it, though if the bot were flipped over, or if my hand happened to cover two sets of sensors during testing, or any other such scenarios, it would happen.
So, I’ll have to put some more priority circuits in there to deal with that.
Something tells me that there’s a much easier way to do this…
But I find that I learn a lot more by trying to hammer it out by myself first and consult the real gurus after I’ve made a nice mess of things.
I’m going to go out to the library and re-check-out a robot book.
In it, I believe the author details how to make simple line-following robot called Sandwich out of non-programmable logic.
I’ll have to see how he managed to get the lower-priority sensors to shut up when the big boys start talking.
Could you use the such a set up to execute stored commands in a biped like the RN-1? Like Punching left/right or chasing down movement while staying constrained by the ring and preforming a grab when quarry is aquired?
Hmm…
Well, this sort of logic works well enough with a rover because one can just send a 0 (off) or 1 (full on) to each motor.
The direction in which that is sent determines forewards or backwards.
With servos… you need PWM (Pulse Width Modulation) which is a series of 0’s and 1’s (offs and full ons).
The longer each 1 is, the greater the servo position.
So… to keep a long schpeel short, no, it can’t be feesably done.
It’s possible, but so complicated that it wouldn’t be worth the effort.
Controlling one or two servos with a 555 timer in an astable setup (astable means that the ON time and OFF time don’t have to be equal) is possible with sensor input, although even that would get a bit hairy, quickly.
I was thinking more along the lines of it triggering the servo controller to execute a command. If it sensed movement in front it would execute the code that moves the 'bot forward. When/if the edge of the ring is detected it would stop the movement and send commands to execute turns. Summat like that rather than haveing to create the code or movement on the fly it would send commands to the servo controller in response to sensor stimuli rather than user controls.
Ah, now I gotcha…
Well, the 3-state buffer is primarily used for data communications, so you could use it to at least disable and enable any data lines you have…
As for sending stored sequences…
Well you’d first need an IC capable of storing specific strings and then releasing them when one of it’s inputs are triggered.
I haven’t come across any designed for this.
Keep in mind… you can do all the things that you’ve so far said with a microcontroller.
Hook some of the microcontroller pins up to sensors.
Then have your micro interpret those sensors in the appropriate means and send the appropriate stored servo information.
Your micro will need to determine high/low, analog value, measure pulse, or read incoming characters, depending on what type of sensor it is.
All of which are capabilities of most microcontrollers.
