I’ll periodically post status here, for those that are interested.
As of today, I assembled the basic platform/legs/servos.
The only electronics I have ready to go is the SSC-32.
The ‘brain’ will be a PIC board that includes an 18F8720, with code running Hi-Tech C. This board has other useful HW on it, such an IIC mux, RS232, etc.
Sensors will eventually include optical, audio, and collision avoidance.
I plan to include an inductive battery charging station (needs some experimentation).
Using LynxTerm, an SSC-32, and a power supply, I have ‘taught’ the little guy to stand up (more like a squat), take a single step, and go back to a resting position (belly on the floor).
Today I got a ‘sequence’ worked out to take 4 steps (one for each leg). It still needs work, though, he moves rather awkwardly.
Meanwhile, in thinking about the idea of having a ‘mass’ that can be moved under SW control, so that the center of gravity can be changed (like a cat moves its head and tail to adjust its balance): It occurred to me that I can mount the bot’s batteries on a sliding bearing, and use a micro-servo to move the batts back and forth, maybe an inch or so in each direction. Since the batts have to be there anyway, and they will be the single heaviest item in the whole bot, it makes sense to make use of their mass.
The ‘brain’ is all hooked up and working. I burned code into the PIC and verified some basic functionality. So far, it can do this:
Init the CPU board.
Turn on/off power to the SSC-32.
Turn on/off power to the servos.
Turn on/off power to the sensors (no sensors yet).
Send commands to the SSC-32.
The PIC brain has a 2nd serial port which can be hooked up to a PC (or whatever) so that it can report what it’s doing or receive commands. I suppose in the future I might add some sort of wireless hookup here…
The power system includes an “ideal diode” between the battery and the FET switches that control the power to everything else. The “ideal diode” is an LTC4412 chip and a SI4965 MOSFET. It allows me to hook up external power and/or an alternate battery, without disconnecting the normal battery, and without the diode-drop loss of an ordinary diode.
The PIC brain board is powered from an LM2940 LDO regulator. To help avoid PIC resets due to brownouts when the batts are getting low, I put a Schottky diode after the regulator, followed by a 1000uF cap. Another diode is in the ground leg of the LM2940, so that the output V is still very close to 5V. I probably will modify the SSC-32 to include the same diodes and cap, to make it less sensitive to brownouts. Or, I’ll just remove the SSC’s on-board regulator, and let it run from the LM2940.
No batteries yet. It still gets power from an AC supply.
No sensors yet.
So how is the walking coming along? I have a 3dof Quad as well and find it a little harder to walk than say a HEX. Would you explain how the steps are done? I am using my PC to control my quad, with Visual Basic 6.0 as the interfacing platform. I also wanted to know what power supply configure is implemented. I cannot get the Quad I built to lift it self up from a crouch, with 8 servos total for lifting. Hey keep up the good work and thanks ahead of time…
Hi, I have basic walking working, using the model posted in this forum by Laurateus, under the topic “Multi-Leg / Quad Walking Gait”. I had to study the pictures for awhile to understand what they are really showing me. I’m using the 7-step gait, not the 5-step.
I can post the details of the sequence tonight.
The location of the Center of Gravity (COG) is critical. Very soon I’ll be adding some mechanics so that I can shift the position of the batteries, and thus move the COG at will.
I haven’t actually done a hex, but it seems to me that it’s MUCH easier.
Power supply: I am currently running from a 6V 5A AC supply. No problems - it lifts itself easily.
I see now that my current power supply is a bit on the weak side. I figured I needed more current to lift the Quad. Tomorrow I will obtain a 10Amp power supply and try things again. The walking defiantly needs an algorithm to shift COG however don’t you think more mechanics to move batteries is a little cumbersome? Have you tried using the legs to shift the COG. I was experimenting with the walking process by shifting the weight to the opposite direction of the leg in motion. I have not had good luck yet but it looks promising.
Has any one used a device to detect the center of gravity like an accelerometer?
Yes, the walking can definitely work without adding hardware to move the COG (I’m doing it now). Any workable sequence involves shifting the legs to move the COG.
However, it is important that the COG be very close to the actual center of the bot, otherwise there will be at least one leg that cannot be lifted without instability.
Then suppose that you lift a leg, and use it to do something (not walking) - you could easily tip. For example, extending one leg to touch, probe, or whatever.
Then suppose that you are walking on a non-level surface - now your COG is not in the right place, and walking may be impossible.
So, I’ve concluded that moving the COG under SW control will add a great deal of smoothness and flexibility to the gait.
My plan is to mount that batts on a sliding track, using wheels and tracks from ‘N’ gauge model railroad stuff. I’ll use a small servo to move the batts forward or backward on the track.
The track idea that your going to implement sounds good I am just not to sure about carrying extra payload. I too have ideas about using the legs for probing and poking however I am considering implementing an accelerometer to adjust the COG. This should generate data concerning the platforms angles and hopefully I would adjust as needed. I have also thought about making small feet to increase the contact patch in hopes that the COG will be less of a problem.
Got any pictures? I would like to see your 3dof design. Keep up the work, Hell it keeps me plugging along.
The gait is not quite cooked yet, but it’s close I think. The scripting language used in the file is the syntax used by my home-brew sequencing program. The comments explain what it does.
In the first picture you can see the power switch on the little board on top. That board also has the LM2940 regulator and the two Schottky diodes and such.
The second picture is a close-up of the PIC board. The big chip is the 18F8720. The small chips with red wires going to them are FET switches that control power to the servos, SSC-32, etc. The big white square connector is for the hi-current connections that go to the battery and the servos. The multi-colored cable has all the other signals on it.
Yes, quite right Mike (about Tachikoma). My wife is Japanese, and the 4 of us (counting two daughters) watch a lot of “anime”.
And yes, the sliding batteries thing is not there yet, because I don’t have the batts yet. I’m looking into using a laptop pack, but I want to find one that has the charger circuitry built-in if possible (most packs have only monitoring and safety circuits in the pack).
I’ve got routines worked out now for walking forward, walking backward, pivoting right, and pivoting left. I think the only thing missing is crab-walking sideways, but that’s optional.
I’m doing the code as a “state machine”. This makes it easy to keep track of what’s going on. The basic walking has 17 states, pivoting has 13 states.
I still don’t have the “movable COG” in place. It will really improve the pivoting. Pivoting seems difficult to remain stable otherwise.
This weekend I worked on the “sensor board”.
I built a permanent version of the audio portion (two mics, feeding op-amps, similar to Mike’s ‘audio board’). The board includes a PIC 16F88 micro to do the A/D readings and such. I just did some quick testing, and it works! The PIC is able to “hear” a sound, and record the relative amplitude.
The 1st shows the sensor board, partially completed.
The 2nd is the schematic so far (more stuff coming).
The 3rd is “the lab” - note the vintage test equipment .
The stuff related to U3 and D3 is not actually on the board yet - I need to do some more prototyping first. The two signals labeled “PROBE” are planned to be a short-range proximity sensor that I’ll mount near the end of the two front legs, so that he can check for cliffs, etc.
.
