My mech CLYDE suffers from the same issue. When I send the walk sequence to the legs, have to wait to control pan and tilt head. I am using a SSC-32 with bluetooth. Would a combo of BBII for pan/tilt and sensors and SSC-32 for leg servos, allow me to achieve this?
Yes, If you have a BB2 and a SSC-32 you can do two things at once. The BB2 could be used to independently control pan and tilt while it’s walking. There is a way to do both with just the SSC-32 but you will need to develop a sequence that moves both the leg servos as well as the pan and tilt servos. The down side is that the movements would be fixed, it would move the same way over and over every time it walked.
I have noticed that even if the SSC-32 is used with the BB2, you still need to write the code so that you can do two things at the same time. When I send a command to the SSC-32, it plays a loop. If you want to do something during the loop, you will need to include it inside that loop. A walk sequence for example might have 4 seq steps that equal 2 physical steps that bot takes. If you want to take several steps, you need to execute the same sequence X number of times to make your bot walk a certain distance. This can cause the program to spend a lot of time in the play seq loop, therefore you might need to add code in the play sequence loop to do other things while the bot is walking.
I don’t remember what you may have on Clyde to tell you. but assuming that your BB2 has an Atom Pro on it and you are using HSERVO commands to control the servos, then if you right your code right then you should be able to control both the legs and pan/tilt with one microprocessor. You just have to be careful on how the code is written.
Kurt
James is using an Atom Pro with the Hservo command. Acidtech has written a really good SSC-32 (group move) emulation, so it’s sort of like there is a built in SSC-32. However there is one thing that you need to check. The Atom Pro has only 20 I/O pins. For our BRAT there are the following connections.
6 leg servos
1 turret servo
2 picoswitches for gun motors
1 picoswitch for the lasers
2 gun switch inputs
1 speaker
4 PS2 controller
So he has 3 left over. Your bot should also be able to be controlled in this way. Another thing, you should be able to develop your walking gaits with the SEQ and the SSC-32 connected. Then get the raw values for implementing it in the Atom Pro code. I really like Clyde. I think his walking gait needs work, but I like the overall design very much. 8)
Edit: I fixed the list to more accurately reflect what’s on the bot.
Well, not quite. There are (or at least, there will be) 2 laser pointers, but they are controlled by the third picoswitch. There is a switch on each gun though, so I still only have 3 pins left. 
Why not run both guns off one battleswitch? (those guns are quite slow) And I’m curious about using two additional pins for gun switch inputs besides the already mentioned pico switches. What are the inputs for? Four total for the guns?
Good idea but then one gun would be wasting ammo unless the target spans the width of both guns. There needs to be an IO multiplexer that zoomcat posted about a fews weeks back.
Since the guns are unable to move independently of each other, it leaves a large gap between them. Firing both guns would draw more current and waste ammo.
Besides, it’s cool to alternately fire each gun
Edit: Bah… Mike! 
I seem to be able to control both a pan tilt head and a walking hexapod independently with just an SSC-32. The great thing about the SSC-32 is that after sending a move command to one pin, you can send movement commands to other pins with out effecting the first. Here is the main control loop for my code:
[code]Public Sub RunIKEngine()
Do
'Get new foot position inputs
ReadInput()
'Adjust for collision detection
’
If BodyDoNextCalc = True Then
MainIKRobot()
CheckAngles()
BodyDoNextCalc = False
End If
If BodyIsReady = True Then
BodyServoDriver()
startBodyTimer(BodyMoveTime)
BodyDoNextCalc = True
'Could set this with a timer that measures the calc time and waits for the
'[movetime - (last calc time + buffer)] to grab input and do the next calc.
'It would reduce control lag.
End If
If HeadDoNextCalc = True Then
MainIKHead()
CheckAngles()
HeadDoNextCalc = False
End If
If HeadIsReady = True Then
HeadServoDriver()
startHeadTimer(HeadMoveTime)
HeadDoNextCalc = True
End If
Loop
End Sub[/code]
Essentially, the head and body can run independently, sending out servo commands to just their pins.
For reference, BodyIsReady and HeadIsReady are set by an event timer that times the length of the move and tells the loop that the previous move has been completed and that the bot is ready for the next move. Saves me from anving to send “Q” queries over and over.
Yes, the SSC-32 does a great job!
The HSERVO command command on the Atom Pro works sort-of in the same way. That is you can issue another HSERVO command to other pins while the first one is still going
It looks like you did a very nice job in organizing your code.
Actually this is the main important thing. That is your code is written in such a way as to make it possible to do both things at the same time. You could do it the way you mentioned with knowing the timings of the commands or you could have done it with the “QP” command. This is again similiar to using the HSERVO command where you can simply wait for the previous hservo command to complete or you can time it and/or query it to know if it is done and do something else during that time.
The brat code is written such that it now, calculates what sequence to run next and then makes several calls to Movement to complete the sequence. The movement function calls HSERVO and then simply waits for the HSERVO to complete (HSERVOWAIT) before returning. So the challange is to allow other things to happen. Probably the easiest way to make this happen without a major rework of the code would be to change the movement function, such that after the HSERVO is issued, to get into a loop that does a loop calling GETHSERVO on the pins and loop until the command is complete. In this loop you can then add a code to be processsed during this time. This code could query the input devices and issue other HSERVO commands. If you wish for the other inputs be able to abort out of the current movement, you could maybe add a global flag like AbortSequence, which when set, you would exit this loop and return and likewise if movement is called again with this flag set, it simply returns. You would then reset this flag at the top of the Main loop.
Again I hope this makes some sense.
Kurt
When I originally wrote HSERVO I included a fairly comprehensive hooking system for it. It’s never been documented mainly because it is fairly complex. The very first test of HSERVO was using this background hooking system to run the legs of a 2DOF hexapod Jim had sent me. The front end was handling PS2 inputs and simply set a variable to tell the background process how to run the legs(eg move forward/backwards/rotate left/right or any ratio of those movements). The background callback was called after each movement of any servo was finished and then sent the next appropriate movement depending on what the forground variable was set to.
Sounds like there may be some interest in revitalizing and documenting that functionality. If so I’d be happy to provide the information.
Hi Nathan,
I would be interested in taking a look at it.
Kurt
Yes Nathan!
I would as well!
Alan KM6VV
I third that!
OMG! 
that was awesome!
The video quality was FANTASTIC! There was no video static at all when it was walking. I have to ask, was that PIP created using RoboRealm?
This would be a great entry level video bot kit.
Thanks! 
Nah, nothing fancy like that, just spliced the video clips together. But those are the original clips, I didn’t modify them in any other way.
That would be a Wifi camera as opposed to a standard 2.4ghz wireless camera. These are pretty much the ‘standard’ for Mech Warfare for exactly that reason, MUCH less interference, you’ll never see static or picture breakup. You lose framerate if you do encounter interference however.
I would also like to second that it looks great 
May have to pick up a wifi camera. Suggestions on an inexpensive one that works well?
Kurt
P.S. - I would still like to play with walking and doing something else at the same time
Wow!
I’m really impressed by the response of the WiFi cam. Excellent video and visualisation. I loved the end of the film .
And pics yet?