mods, dunno if this should be in hard or soft ware…
been lurking for a few weeks trying to wrap my head around the impressive work going on round here!
ive been kicking around the idea of making a walking robot for a year or so. just stumbled onto youtube videos of the A-pod, was shocked, had no idea things were so advanced already, was exactly what i was envisioning.
anyways, i have a background in physics/math, and quite knowledgeable by necessity with programming and engineering.
i have experience using arduino controllers for some projects. it seems that the general mood around here is against arduinos though… seems like the ssc 32 is the favorite (just because its sold by the host company? heh).
what is wrong with an arduino? i believe they can run up to 40 some servos at once. is there a lack of processing speed or position resolution or what?
im finding it hard to sort out the exact info of the lynxmotion setups, if someone could just sum up the typical phoenix type setup that would be great. as in where they code is stored, what language, the general control/information flow, and what exactly each board does etc…
i want to build my own, not buy the canned kit. also looking to make something more “autonomous” with sensors not just a puppet running sequences like the kits. (even though those are very purdy)
This is the Lynxmotion Tech Support Forum. We’re just not a general purpose robotics forum. We allow the discussion of lots of different manufacturers stuff, but we will not tolerate bashing of our, or anyone else’s products here. The website has lots of information on how the hexapods operate. Click Information, Assembly Guides, then the product you are interested in. You will find assembly guides and tutorials for programming and use.
The current 3DOF hexapods are controlled by our SSC-32 servo controller. A very powerful little device. It receives servo positioning commands from a Bot Board II which holds a Basic Atom Pro 28. The Atom Pro chip is programmed in a custom basic code called MBASIC. The power of the SSC-32 is in it’s ability to coordinate servo moves. It is also able to store full blown sequences in an EEProm on the boardm by using our Sequencer program, or Zentas PEP program to easily create these sequences. Hey, even autonomous bots can take advantage of stored sequences eh?
Edit: Our bots are not running canned sequences though. They are running full inverse kinematics in real time to accurately position the legs for walking and or body moves / rotations. With the addition of our new ground contact foot switches you will soon see terrain adaption walking. 8)
I don’t think anyone here has said that there was anything wrong with the Arduino. You can use what you want. Can you spare 18+ pins to control the legs of a hexapod?
Most hexapods (most 'bots here, for that matter) are controlled by pair of boards, the SSC-32 for coordinated R/C servo leg motion, and a BB2 used for calculating the IK and simple navigation/sensor inputs.
If you haven’t done it yet, I wouldn’t disparage it!
well the main things im hesitant about at this point is using something that runs C++ or basic as is looks like most guys round here use?? i much prefer java or python. very leary about “custom” proprietary languages… i can trudge through C if necessary but i very much loathe the language. granted iv only used it for more software things so mabye its better for robots…
does the ssc itself contain such coding? could say an arduino be used as the brains with all the programing and just drive the ssc?
the ssc-32 looks interesting, i just dont know enough about it yet. how are these sequence programs stored? are they editable on the fly? i guess i still dont understand the difference between “inverse kinematics” and running a hard-script… from what ive seen with the excel sheet etc is that its just a series of parallel scripts for each motor.
AFAIK the phoenix style ones ive seen have no sensors, except a few with “after market” foot sensors. but your saying the ssc could incorporate sensors and modify the sequences?
To use the SSC32 you need to send commands through the com port. Java and python do this job very nicely. Take existing vb or c# examples from this site and run them through a code converter (search for C# to Java) code converters and you’ll get what you need.
Once you convert them post your code back to the programming area in the forum. viewforum.php?f=28
The SSC32 does the job hands down.
Conceptually if you want to understand how it works, for a minimal investment, I’d start with a simple project like this for around $150 bucks. otherrobots.com/Robots/Robot … fault.aspx
This will let you see how the SSC32 works with servos. Then you can decide to purchase a Hex kit or build your own.
The ssc-32 is just a servo controller with a couple of added features. It has to receive commands from elsewhere to function (controller board, PC, etc). As to programming languages and microprocessors, one uses the ones that are easiest to work with that will get the job done. Servos work from electrical signals, and could care less where and how they are generated.
Perhaps custom was the wrong word. It’s just BASIC with a lot of enhanced commands specific to the hardware on the chip. The Basic Atom Pro is a very powerful chip if you utilize the hardware specific commands. It’s also capable of being programmed to make use of interrupts. It can also be programmed in C but I have no experience with doing that.
Of course. The SSC-32 can be commanded by any device capable of sending TTL or RS-232 serial data at 115.2kbaud or slower.
A good place to start is to check out the manuals for the SSC-32.
Here is the users manual for the normal firmware. In addition to the normal servo controller functionality, it has a 12 servo (2DOF) hexapod sequencer built into the device. It operates in the background… lynxmotion.com/images/html/build136.htm
Here is the General Purpose Sequencer firmware manual. It’s used when you want to take advantage of the EEProm to store sequences. This functionality replaces the 2 DOF hexapod sequencer of the normal firmware. lynxmotion.com/images/html/build137.htm
The difference between IK generated walking and hard coded sequence walking is not insignificant… Hard coded sequences will only do exactly what it was programmed to do. The leg positions, the timing, the speed of motion, etc will never vary from the hard coded positions. You would have to store a separate sequence for walking in as many different directions as you want to be able to move in. If the legs are not lifting high enough, guess what, a new set of sequence positions will need to be stored. If you want a different gait, new sequence positions…
With the IK method a fairly complex routine is written that calculates where the legs need to be in real time for walking. These positions and the speed in which they are sent to the SSC-32 can vary in real time as the user, or autonomous code, commands. The gait is changeable in real time. In fact every property of the walking gait (leg lift, stride length, walking speed, gait, etc) is alterable in real time. The latest Phoenix code is about as perfect a 3DOF hexapod walking routine anyone has ever written. It’s a culmination of 3 peoples programming evolution. Laurent Gay - France, Kåre Halvorsen - Norway, and Jeroen Janssen - Netherlands.
One thing not mentioned here yet is the fact that the code is modular so the control aspect (PS2, serial commands, DIT RC radio, etc) is easily alterable without getting into the nuts and bold of the IK code.
No, the Bot Board II and Atom Pro 28 can be programmed to read the sensors and incorporate it into the IK engine. We even have a high speed (binary) version of the SSC-32 firmware that speeds up the communication considerably. We will be publishing this very soon. Lets see who finds this little “easter egg”… LOL 8)
like i said i have the basics of programing down, but use it only out of necessity or goofing around. mostly pretty base level stuff for data-reduction and image processing. never any “systems” stuff with dedicated hardware and multiple bits needing TTL etc or having to worry about converting to binary for speed boosts and such. im sure i can figure it out but itll take some playing.
dont really have the time to properly dedicate to it ATM but soon hopefully.
been looking more into IK and i think its starting to make more sense about why it is so powerful, give it a destination not a route. even rigged up some quick and dirty java applets to demonstrate a jointed leg moving to where you click. one thing though isnt quite making sense for me still, without sensors how does the leg know its run into something? for example on uneven ground, if you tell a foot to go to (x,y,z) and that location happens to have a hill, wont the leg keep trying to go “underground” to the specified point and lift the rest of the body out of wack? in essence shifting the origin rather then the foot till the coordinates meet up.
also, your saying the ssc does the IK on its own? i.e. you just feed the board a coordinate and it does all the work to move the servos till the target is hit?
also
so stock the ssc can only handle 12 servos but with this firmware it can do more? i was a bit confused because the standard phoenix has 3X6 dof. and by just looking at the pins, it has like 32 plugs for servos…
will have to dig around your guys code when i have the time. it is very impressive platform, id love to see it “controllerless” and able explore uneven terrain on its own even if its just aimlessly. im involved in astronomy work and there is serious work going on about things like these as the next ‘mars rovers’, semi-controlled autonomy would be huge for such things. damn light-speed time lag…
A technical reading and understanding of the ssc-32 manual should answer a lot of your questions.
Nobody said that. The ssc-32 can store some hard codes sequences. IK servo commands have to be generated (at least to my understanding) in some other processing environment.
The leg doesn’t know anything on its own. Sensors or other event detection mechanisms have to be used to detect any unexpected events concerning the leg.
The ssc-32 users manual is your friend.
I don’t really understand the “controllerless” statement, but with a a ssc-32 and some servos, you can start experimenting in this area quite easily and cheaply.
the bots on here are very impressive, but when it comes down to it, all the ones ive seen so far are glorified remote control cars. haha thats the only way i can think of putting it, but i mean it with no disrespect. in the end theres a guy pushing buttons making it do what it does.
there are lots of much simpler wheeled bots out there that have no inputs at all, turn them on and they react to stimuli, light, sound, proximity etc and press their own buttons so to speak. im interested in combining the amazing insect inspired fluid leg movements with sensor driven commands and autonomy
LM concentrates on the motive parts, and the motor controller to drive them. There is minimal code on the BB2’s CPU to do the IK for the legs.
There are options when it comes to the “navigation”. A PS2 interface is perhaps the best way to start, and after that an autonomous module can be written to replace the PS2 code module. Appropriate sensors can thus be added and , well, QED.
Sounds like you have picked yourself a good challange. The mechanics have pretty much worked out and there is a fair selection of sensors that are cost effective for the hobby realm, so all you have to is intergrate your autonomous programming and supporting hardware.
The difference between our walkers and an RC car are significant. With an RC car you push a joystick for throttle and steering and these simple “inputs” move simple mechanical or drive simple electronic circuits to move the vehicle.
In our walkers the person moves joysticks that result in variables in a controller changing value. These values determine what the robot does, and the robot could care less if it’s a person changing these values, or a sensor in a control routine. Adding autonomy is about as easy as it could be. Depending on the complexity of the desired behavior, you just add sensors and some control routine to the controller, or you add another controller to send the walking system instructions. The point here is all the heavy lifting has been done for you.
The fact is we purposely focused on RC as a method of control because it’s fast and easy to see the results. At least for the walkers, we leave autonomy to the builder because there are too many different methods, sensors, etc. to fit all the different customers requirements.
The SSC-32 is just a servo controller with built in features that allow group moves as well as the ability to cause several servos to all start and stop at the same times regardles the the throw differences. Any MCU (Micro Controller Unit) of choice can be used to drive the SSC-32. You just need to be able to send commands at the proper baud rates. If you like java, Parallax sells the Javelin Stamp Module.
may i know what is the pulse range for servo HITEC HS-645MG/the most HITEC servo ??? cos some of them said 0.9ms-2.1ms… and some of them said 6ms-2.4ms… which is the truth??? please help me…
It really depends on the types of servos. Analog servos typically have a different range than do digital servos. Probably one of the better posts on this is a sticky in the servo section: viewtopic.php?f=31&t=3172
