I had a question regarding the ssc-32 controller. I am using a pic18f to interface with it and I was wondering if the following command would work:
assuming a 1500 starting position:
“#10 P2000”
(very short delay - before #10 reaches P2000)
“#15 P2000”
basically, I am trying to move the legs to the same position but with a phase difference. Would sending the second command interrupt the first command? or since they are geared towards different servos, it would not affect the first command? what will happen exactly?
I am a bit confused regarding your answer. Basically, what I’m trying to do is implement the “ripple” gait algorithm for my hexapod which requires the six legs to be moving with a phase difference between them.
In the case of legs, I believe you’re talking about a pair of alternating tripods. There are several steps to the cycle of each tripod. So you have a set of “waypoints” for each leg (tripod) to move to. Sometimes a leg moves, sometime it doesn’t.
You don’t need (or necessarily want) to make the move of each of the probably 6 steps all at once! The moves can be divided into several smaller steps, which makes the moves more like lines then arcs.
Study the LM code! You’ll be calculating IK, and you’ll have a “move” that will have the foot tip tracing a trapezoid in the vertical plane. For a round 'bot, each leg is at a slightly different angle, and thus legs swing through different arcs to get the foot tips to all move the same. for an in-line 'bot, there are two different moves, which are basically mirror images.
Then we get to rotations and translations. But we’re still just adding a move vector.
The SSC-32 controlls each servo independently or in group moves just as precisely as the instructions are received. There are no known issues with the serial port and how many commands it can handle, or with the speed in which the commands are received. You can command each of the 32 servos independently in real time, or in any combination of group moves, with whatever delays between the commands you want to implement. It will not miss a beat! So in your example servo 10 will not effect servo 15 in any way. Hope this helps! 8)
First of all, THANK YOU all for putting the time and effort and answering my questions. I’m feel lucky that there is such a supportive community out there!
Yes, I just wanted to make sure that one servos command does not affect another…
Now, I can continue with our project which is to control the hexapod wirelessly through bluetooth, make it smart enough to avoid obstacles and navigate around them, ability to climb the stairs and finally automatically dock onto its charging station when battery levels are low.
We’re using PIC18F4685, PIC18F2685 (to act as a SPI to UART converter), SSC-32, BlueSMiRF and a C# gui for manual commands.
I’ll keep you guys updated and will definitely seek help as the project progresses.
Welcome to possibly the best robot support forum out there… This place is a great resource for all your robot needs, there are lots of great minds here in these forums. Ask away and you’ll usually get many answers to your questions!
Good choice on the PICs. SPI to USART? You mean for the PS2 Joystick controller? That’s an idea I’ve toyed with. Maybe I will try it. I intend to add a PIC18F2685 or similar PIC to handle sensors. Some are already I2C, which is great, but the IR rangers are analog, and it might be worthwhile to “handle” them.
I’ve got a BlueSMiRF in the mail, that should make things interesting. Not sure how it will all play with my existing BlueSMiRF-ready IBM notebook, 'tho.
The USART to SPI converter was because the PIC18F4685 has only 1 USART channel and it’s trying to communicate with the BlueSMiRF and the SSC-32 through UART. So, we had no choice but to use a smaller pic (PIC18F2685) to act as the middle man between the BlueSMiRF and the PIC18F4685 controller.
The BlueSMiRF is a pretty good device. The only thing is the manual they sent with the module was for a different kind of firmware! For example, the manual said that the Passcode for connecting to it is “default” but the passcode for my module was in fact “1234”!!! so watch out for those kinds of things!
So it’s BlueSMiRF to SPI? Well I guess that’s one way in. But my SPI pins are tied up with I2C.
I’ve been simply using the USART to send commands to my 'Bot controller (18F4620), and the output of the board goes to the SSC32 AND back to the terminal program. The SSC32 doesn’t seem to mind debug messages.
I think I saw those passcodes in the TWO tutorials I’ve read. I’ll keep that in mind when my hardware comes and it’s time to install. What baud rate do you get out of BlueSMiRF?
well, the BlueSMiRF uses uart to speak to pic18f2685 and the pic18f2685 sends that to the pic18f4685 through spi. and on the other hand, pic18f4685 uses uart to speak to ssc-32.
Yes, it seems SparkFun is changing the BlueSmirf modules, but keeping the same part number. We’ve addressed some of the changes here, in Step 5 and 9. lynxmotion.com/images/html/build125.htm
Besides the differences in passkey and default baud rate, with the new version, it’s possible to get a command list. The old version’s manufacturer did not allow distribution of the command list.
Unfortunately I can’t answer this - you’ll probably have to contact SparkFun to find out about any conflicts. I looked on their website; they don’t seem to have the documentation for the BlueSmirf module online - at least, not that I could find.
As far as I understand the Sparkfun BlueSmirf is simply a modem used with Bluetooth. They sell a dongle to add Bluetooth to a PC or laptop, but if your laptop already has bluetooth then you don’t need their dongle.
James sent me the direct link to the new BlueSmirf’s datasheet. Remember, this datasheet only applies to the new BlueSmirf modem. You can read a bit about the differences and how to tell which one you have on that tutorial I linked earlier.
The SparkFun document you linked to looks like it’s using a really old version of the BlueSmirf - since during installation it shows up as “BlueRadios” instead of “SparkFun”. I’m not sure that there are any other differences, but our guide covers the same installation plus some.
Thanks Beth, this looks like good, fresh information. I have your '125 document bookmarked as well. I’m still watching the mail for the hardware to arrive!
I noticed that RovingNetworks is just “up the hill” from me in Los Gatos. Not that I’m expecting too much in the way of problems. Still, nice to know that I can make a local call…
Thanks for keeping tabs on this product for your customers. I’m sure that this will be a very useful adjunct for LM robots!
Sounds like a great project!