Hey Nick,
It seems as though something I thought about earlier on is true. Every time a component is moved the weight change necessitates the gait to be manually adjusted.
Do you forsee the FSR’s aiding in relieving some of the effort?
Otherwise it sounds like it would be more prudent to first get everything in place and balanced before even attempting to start the walking process.
Does this sound right?
Tinman
After you get the robot walking, you should add a voice synthesizer and have it say " I’ll be back"… Muahhahaha stupid ducks.
Tin, the FSR circuit could be used to “fix” minor shifts in weight without any real issues, but I’d rather not rely on that.
For instance, what if the FSR circuit fails, or is too slow?
PLOP.
With all the regular unavoidable mechanical errors further errors would probably be quite crippling.
I’m hoping to use the FSR circuit to help program those gaits, though.
Once I get the damaged FSR’s replaced (in about a week or so), I should be able to write a simple display program that shows their values.
So, when I’m making the gaits, I’ll be able to center the bot’s COG much more accurately than doing the “poke and catch” method.
So, I should get more stable gaits, then.
By the way, I know that the LynxTerm is an open-source program, and all, but I can’t seem to find the source code for it.
Can someone point me in the right direction?
Here is what I have so far nick:
The Titanium chassis:
http://img467.imageshack.us/img467/4622/cloningdevice7td.gif
The printed Cloning processor board:
Have you given any thought to how you are going to use the FSR data programmatically? The PCT stuff I’ve been playing around with seems to be incredibly tolerant to things like shifts in weight and random shoves from me. Depending on how you incorporate the dynamic data, you may be surprized at what sorts of problems can be completely erased by using (as Brooks says) “the environment as it’s own best model”.
Well…
I don’t have any real experience with programming anything that’s external from the computer, and very little internal experience.
Pretty much, I’ve read a couple Visual Basic books and I’ve taken a QBasic class.
So, I’m still not sure how I’m going to integrate the FSR’s, yet, dynamically.
I haven’t even gotten a microcontroller, yet, so dynamic gaits are quite a bit into the future.
My first goal is to make a display program to simplify the static gait-building.
As for dynamic gaits, the first thing that I’m going to try will be on the computer side of the processing.
I’m going to take the LynxTerm and add a bit of code so that it frequently reads the analog input values.
Then, I’ll have it do a bit of algorithm (which I’ll develop and adjust with trial and error) to find out how much it needs to adjust each foot on the X and Y axis.
Then I’ll have it querry the current position of designated X and Y adjustment servos (probably the two servos closest to the waist).
And, then it’ll add or subtract that offset from each servos current position, and send the corrected position.
Do you think that’ll work out?
At the risk of starting to sound preachy about PCT (probably too late), I think a PID is what is called for to acheive that balance. Use your ratio as the input to the PID and distribute its output to something capable of adjusting it positively or negatively.
Here’s a good intro to PIDs
Hey Mike,
you send me a blue print of that chassis and I could vaccum form it up.
That actually would be fairly easy, with the exception of those ridges on the edge, this is very “do-able”.
You would have to provide a very accurate drawing with the dimensions to ensure a good fit over the components though.
Tinman
Tin, I don’t think that that was a robot’s chassis.
It was sort of a joke about making a cloning devices’ electronics and a titanium housing for it.
Now, all we’ll need is a pinch of fairy dust and some happy thoughts.
Andy, thanks for the PID intro.
I spent much of yesterday reading through it, and I seem to have at least a conceptual grasp of it.
It looks like my original plan was sort of a proportional control.
I’m going to go ahead with that, for now.
If dampening the proportionional control isn’t precise enough, or tells the servos to oscillate too much, I’ll try adding in integral and derivative control.
First things first, though, I’ll have to check out the SSC-32’s firmware and translate it into VB, so that I can start making my own terminal program.
Wish me luck.
You’re trying to reimplement the firmware? Are you not planning to still use the SSC32 just as a slave from the VB code?
On a different note, I know you had been talking about using the com port redirector over the socket connection to the WiPort. I think this makes you lose control over something valubable in terms of speed. In order to send the serial streams over the network, the WiPort has to group the data into packets. The ComportRedirector will be doing the same thing. The problem with this is that since the packets themselves have a fair amount of overhead, they avoid sending a packet for every byte. Instead they want to group together a lot of data at once and send it as a single packet. To do this, means waiting for either a buffer to fill up, or for some idle period to expire before saying, “OK, I have enough data now, lets create a packet”. Say this timeout is 10ms, that means if you send a very small amount of data, the network could deliver it in <1ms but it’s sitting around waiting to see if your going to send more data before it commits the extra resources of a packet to this small message.
On the WiPort side, you have the termination characters in the setup. This lets you define a couple of chars that when the WiPort sees them, the packing algorithm will end the packet then and there. This way you can just include 2 extra chars on the end of your return packets and have the WiPort send them immediately. I don’t know for sure, but I doubt the redirector is going to give you similar functionality. If however you don’t use the redirector and use only the socket based interfaces to the network, you’ll retain full control over packet delination and overcome any artifical delays introduced because of the stream to packet translation.
In the words of Homer Simpson, DUH’OH!
I feel rather silly at this moment, I caught the part about the cloning device and the Titanium, but I thought the drawing Mike did was seriously a chassis he wanted. LOL!
Tinman
Joke or no joke, I would love to have that chassis made if it’s possible, which is why I designed it in the first place. I have several designs in my folder that are just “sitting” there.
Andy,
OHHHHH!
So I can control the SSC-32 directly from the sockets?
Sweet!
That’ll save me a load of time.
I’ll have to start playing around with VB again and figure out which sockets I’ll need.
I’ll need to set up a TCP Client and a TCP Listener, right?
Hmm… I’ll have to take a look at the example code for VB on the site.
Thanks, Andy!
Just a TCPClient. Think of it like you a telephone conversation, one side intiates the connection (TCPClient) the other side has a phone with a ringer (TCPListener). Once they are connected, they are equal peers, but you are going to be initiating the connection to the WiPort which is already doing the listening on those couple TCP ports (10000, 10001).
Ahhhh!
Btw, the ports are 10001 and 10002.
(I know what you meant, but that doesn’t help others.)
Thanks again.
I should have enough time on Wednessday, between classes to take a look at the example code and start writing my own.
I’ll post my results when I have something that looks like it’ll work.
(Or, I’ll post what I’m stuck on, more likely. XD)
I cut the chest and backpack plates out of kydex, today.
Here’s my method for modifying the chest brackets to accept an electronics carrier:
(1) Do nothing
There, now you’re ready to mount it.
Believe it or not, with a bit of wiggling, you can stick four 1/2" hex bolts straight through the inside four holes in the chest ASB-04’s, through the kydex plate (die, lexan!), through the PCB, and into the standoffs.
I’ve updated the parts lists on both pages to reflect the changes.
I’ll be making the other five sides of each pack soon (like Jim, I’m tired of saying dates that I don’t hold to ).
Probably when I get frustrated programming.
BTW, a radial arm saw works very well as a planer, if you have a lot of time on your hands.
I tried sanding my 1/4" thick piece down to 1/8", first, but that just warps the butt out of it.
Good news.
Alex and Jennie (the guys from phidgetsusa) are replacing the 5 FSR’s that my beloved superglue ate through.
So, I’ll be getting to gait-building a few days after they arrive.
In the meantime, I have a few more finishing touches to put on the chestpack, and a complete backpack to design.
that must be some super glue
hey guys, looks like there has been a lot going on in this thread - and no wonder - Nick, you cannot receive enough credit from me on that bot, seriously cool!
On the up side though I now have enough money to buy the servos for my bot as I already have the Lexan kit for the Biped Scout so hopefull will have some legs running round before long, but having seen the humanoid I’m tempted!!!
Nick - As I see from the pictures there are 5 servos in each leg, ankle pitch, ankle roll, knee pitch, hip pitch and hip roll - is that right? My question is really how does the robot turn round if there is not the 3rd servo in the hip, as obviously the Biped scout has 6 servos per leg? Do you think that the 6th servo in teh hip isn’t needed or is it sacrificed for the space?
I’m thinking of using the HS5645 servos in the legs of my Biped - how do you find these - good? As far as the arms and waist rotate goes what servos would you use here? I’m just thinking aloud but seems like a HS5645 in the waist as this takes load, then something like HS5475 in the Arms to keep the costs down?
On the case of PCT since this is what I’m planning on using to control my Biped’s gait, I have scored a PC104 stack from work whcih I hope to mount on the bot (Pentium 3 700Mhx running Linux so should be lots of processing power!), but I don’t think that in a single Micro will be up to the continual processing - Nick I would suggest that as on the last page you use the WiPort to make a wireless comm connection to the SSC, and then run all the processing on the host PC, means you can also use any language you like, C/Basic/Java!
Anyway keep us updated
