WTW, the ground sensors sound interesting. Are the ground sensors proximity devices or tactile? Are you doing anything to dampen the foot? Are you calculating adjustments to the deck incline of the hex body?
Sorry for all the questions, its just that I’m totally fascinated by this stuff and I’m getting so much out of this forum. BTW, I’ve decided on a purpose for my bot. I’ll detail it more in the “projects” topic, but basically, I’m going to construct my bot to fetch my newspaper. Yeah, I know, sounds pretty pedestrian. But if you think about the challenges of getting it to do that without human intervention, its a pretty interesting problem. And imagine the look on my neighbors’ faces when a big yellow spider dashes down my driveway to snag my newsrag!
Question for you and/or Nick: WRT your power connection…are you using a single battery to drive the servos and the servopod? I haven’t gotten far enough into the board layout to figure out how I get power to the board or if I need some kind of power regulation and distribution. If I recall, theres power regulation on the pod, and I’m guessing I just connect the +/- lines off the battery to a pair of pins on one of the headers on the board. So a 7.2 vdc 2800 mAh nicad or L-ion ought to do the trick? I was reading that these Hitec servos are engineered to take as much as 9v, but I’m worried about power regulation on the pod.
The primary ground contact sensor will be a simple tactile microswitch with some minimal debounce. The rationale here is sampling speed. Analog inputs require signal-conditioning which increases latency. I need to know as soon as possible when the foot touches the ground. Assuming that there are no other obstructions, the servo pulse output immediately prior to contact should yield a reasonable approximation of leg extension.
It is not necessary to be 100% precise, since the goal is to equalize the legs, not to achieve a specific extension. Since all legs use the same sensor system they should all have similar positioning error. A higher level controller will periodically sample all planted legs and attempt to equalize their extension.
I am designing in some FSRs to give me an analog indication of the load on each leg. I’m not sure how they will fit into the overall control scheme yet.
I haven’t spent much time on refining the power system. I probably won’t worry about that until I get the gaits working well. I have noticed that the Pod regulator runs a lot cooler at 6v than at 7.2v. Servos also have some pretty high peak loads. In some cases enough to reset the controller. In general, a separate power supply for electronics is probably a good idea.
The newspaper idea sounds like a fun challange. Are you thinking remote control? Or will it be able to recognize the newspaper?
No, definitely autonomous. Here are some of the planned behaviours:
Wakes up at specified time
Opens garage door
Sense whether door is open or closed
Travels to pre-set location to search for paper
Searchs for paper within a limited and learned search area
Recalls where paper is statistically likely to be found
Senses movement
Senses sound
Senses approximate sizes of objects around it (within say 25 feet)
Flees objects that approach rapidly
Flees objects that approach to within 15 feet
Calculates escape route
Maps current location and movement
Behaves aggressively if trapped
Flinches when startled (away from stimulus)
Senses difference between soft terrain (lawn) and hard terrain (concrete)
Drags payload when on soft terrain
Carries payload when on hard terrain
Finds newspaper and picks it up
Returns to garage with paper and deposits it at the basement door
Returns to its dock and connects to power
May explore garage if power level is not adequately depleted
Senses power level
Returns to dock when battery is depleted
Calculates when to return to dock based on activities performed from last charge
Chirps when exploring (mapping)
Chirms affirmative tone when objectives complete
Screams when threatened or harmed
Send email if paper not found
Persists to complete objective until complete, even if startled or threatened
Returns to dock if harmed and sends email
A fairly challenging list, but I’m workout the details and primitives for each of the behaviors. The servopod should have enough I/O to support, but I’m a little concerned about flash and ram. Of course, I’m used to the piggyness of windows so I’m hoping the program footprint is much, much smaller…
I’ve already prototyped a gripper that uses mechanical leverage to wrap its “fingers” around an object, so I only need a single servo to operate the gripper. I’ll get a movie up soon.
As you say, the ServoPod has enough I/O. I suspect that some of the higher-level functions such as mapping may exceed the RAM capacity.
My plan was to use the Pod for first-level real-time control and sensing. This would include gait-control, obstacle and threat detection (and the associated reflexive behaviors). I want to keep the CPU load for the Pod at a level that allows the control loops to be responsive.
Higher level functions requiring more memory and/or cogitation would reside in a higher level processor. I’ll probably do this via wireless from a host for development. Ultimately I’d like to have this reside in a PPC-class machine on-board.
Let me know if you are interested in collaborating on some of the Pod code.
Actually, I’m not planning to using vision for terrain recognition at this point. I’m approaching the problem much like we do…using the differences in “perception”. I haven’t worked completely through this problem yet but in broad strokes I’m thinking about computations using pressure actuation, leg stroke or stride and deck inclination. Now I have something of an advantage in that I’m not expecting FidoBot to be very smart in terrain recognition, because he only needs to differentiate hard terrain from not-hard terrain. There shouldn’t be any other choices in this specific application. Of course, “air” (as in void) could be considered not-hard terrain and I have to take into consideration the possibility that he might step off of a curb, thinking he’s stepping into lawn. I’ll keep you posted on how that shakes out.
With regard to object recognition, I suspect I will have to use a combination of sonar/ultrasound and vision. I’ve found some interesting sonic transducers that have potentional for ranging as well as detecting soft objects. I had also come across a project where this guy had developed a rudimentary vision recognition SW module and was seriously planning to look more into that. I apparently didn’t bookmark the site tho, so now I’m hunting around.
BTW, for video hardware I’m look into the CMU-2, or something very much like it. It processes the video from the camera using its own onboard microcontroller and outputs a variety of data from the video stream via a serial connection.
First, you’ll need to know the average value that a foot’s pressure sensor gives when it’s standing on it on a firm surface (we’ll call this “x”).
Then, when a leg goes to the standard “down” position, and finds a value lower than x, it stops it’s gait and pushes down with that leg until a value near x is reached.
After a certain distance of pushing down, and not getting a large enough x, the hex aborts it’s attempt, backs up a bit, and tries another approach.
This would probably work well with surfaces such as mud, which you wouldn’t want the whole bot mucking through, as well.
It would also probably take care of low terain obstacles, such as a 2" drop.
This is assuming an analog pad sensor with a variable resistor or something like that, right? Have you been having luck with consistent readings from your sensor setup? That algorithm would work, and I think it might be a little simpler than what I have bbeen kicking around. I was thinking about using a straight microswitch with position monitoring on the leg servos. OK for voids, not so much for the soft stuff tho. With the resistor pad, I have this issue of having to accomodate varying payload weights (inconsistent weight of the paper). I could do a read test on each sensor once I got the payload on and adjust ‘x’ accordingly. What do you think?
I have a servopod and I have two important questions.
Is there any way to use a USB cable instead of the I/O cable because my better computer doesnt have the correct port?
Is there anyway can make individual codes such as walk forward and turn in there own documents. Then reffrence them or “use” them with out going in and copying the codes down??
Question 1 - Try a USB to RS232 Serial adapter. You will then need to make sure the terminal program of your choice has API capability with the USB port you are going to use (i.e. Realterm realterm.sourceforge.net/)
Question 2 - not sure what you mean here. If you are using Isomax based on Forth you can utilize a WORD for the particular ‘function’ you would perform. These WORDS are defined once (downloaded into memory on your controller) and utilized with a simple call - the name of the word, whenever needed.
However, on the fly file opening from the downloading PC for immediate code interpretation is not something readily supported within the Isomax language itself. You would need a PC controlling program that performs the required file opening, writing to serial port, and closing. The Servopod could certainly prompt your PC to do this. It is not all that inconceivable that it could be done but I caution, the amount of work to do this is significantly more work than just ‘copying the code down’.
The Servopod Isomax language doesnt have a construct that could readily be related to what you have termed a ‘document’ to my knowledge. What exactly would you like to accomplish with your proposed document modularization that could not be done with WORDS? In either case you would still have to download (copy) code.
I’ll keep you posted on how that shakes out.