I just updated my github with changes for the DIYXBee stuff. In particular I now allow you to put the XBee on the USART (digital pins 0,1). Note: When you do this, you can not enable debug support. Alternatively you can define cXBEE_IN and Out to use softwareSerial. I also put up a a sketch up with this for a Quad, that if the libraries are installed in the correct place should show up under the Examples menu.
Kurt
Hi Kurt,
Thanks for the explanation and your update for the XBEE. Looking forward to check that out.
In the mean while I had to try the idea I had with the circular movement for the COG shifting. I’m so happy with the result that I shot a quick video. The quality is horrible but you will see the result.
The COG logic works like this. The body is following a circular path. The body is always in the opposite direction of the leg which will be lifted. The body translation is limited to only move perpendicular from the walking direction. This prevents the body from shifting backwards and then going forward really quick.
The bot still is a bit wobbly since it need more “all legs on the ground” steps in the gait. I have a gait like that but it is not optimized and pretty slow at the moment. Could not wait to shoot the vid 
I also attached my files so you can take a look at how it works. (Sorry it still is BAP code)
Xan
Quad circular COG shifting.zip (150 KB)
Sounds good. Will take a look!
Kurt
Just browsing youtube and your video popped up. 
hay nice.
Look like you got it working real nice.
Do you still have the “double gait speed” and “double leg lift” in the code. I found that playing with these gave some interesting results.
Yes, walks really nice, spider-like moves!
Alan KM6VV
Thanks guys! This logic will do the trick
More to come soon!
@Jonny: “Double gait speed” and “Double leg lift” will still be in the PS2 version. I’m using my DIY XBEE V2 remote. It has analog sliders for the gait speed and lift height 
Xan - I believe I have most/all of your new stuff integrated into the Quad fork of the Arduino code (uploaded to github). I ran into a few issues with the port in BalanceBody. In particular: BalTotTravelLength will be zero if we are not traveling and then you do a divide by this value… So I detected that it was zero and simply zeroed the other variables…
I would like to see how this runs on a symmetrical quad, so I will probably stop working on the Lynxmotion one and go back to making similar changes to my Orion code base.
Kurt
Sounds good Kurt, I’m not sure if the BalTotTravelLength is still used. I think this logic should be part of the gait engine. I also need to figure out a clean way to shift the body when rotating. This is not working yet.
I will have some play time tomorrow evening!
Hi Guys,
I just rebuilded my quad with the BotBoarduino and the new type of PS2 (including lvl shifter). Is it correctly that the new PS2 remote is not backwards compatible with the old receivers? This is a bit of a bummer. I always use one ps2 remote for testing all the bots.
Kurt, I think I need to connect the XBEE remote to RX/TX of the BotBoarduino. Is that correct?
Xan
Yep - I am pretty sure not compatible… So now I have 2 of these on my desk. I don’t have any of the new ones with the level shifter, but have a new one that Jim sent me when he first discovered the issue and wanted some help…
Kurt
Correct. V1 PS2 remotes / receivers are not compatible with V2.
Hi Guys,
As you know I replaced my BAP with the BBduino. And I still can’t get my PS2 remote to work. I did some debugging and I’m getting lost…
I’m using the PS2 V2 incl lvl shifter
It is connected like this:
First Question:
Is the PS-V2 Compatible with the BAP? I’ve connected the PS2-V2 receiver to one of my other bots and it didn’t work. There was no connection with the receiver. Is this normal or could this be a hardware failure?
Second question:
I connected my Logic Analyzer to compare the signals.
Here is the PS2 signal from the BAP. Notice: the receiver is not connected. So this is just the signal from the BAP.
Here is the PS2 signal from the BBduino. Notice: Again, no reciever connected.
Shouldn’t these signals be the same?
Kurt, I’m using your QuadC_PS2_SSC32 version from GitHub
Xan
Hi Xan,
Sorry to hear you are having problems getting the PS2 to work. Sounds like it could be hardware issues, if you can not get the receiver/transmitter to link up. I don’t have one of these level shifters, but I will do what I can. (Jim was going to send me some, but…) I do have one of the V2 ones, that he sent me when he first ran into the issue, which I now have working with the Arduino Due… The issue is that these PS2’s are not 5v tolerant, but instead run at 3.3v (like the actual PS2 consoles)
The level shifters are really darn simple. They have a voltage regulator and a couple of capacitors on them to take the input voltage coming from your Microcontroller and convert it to 3.3v.
It then has inline resistors on the CMD, CLK, SEL lines to limit the current. These resistors were setup with default surface mount resistors, but also had holes for axial lead resistors, if one needed to unsolder the SM and change to a different value… Also there is an empty resistor location that allows you to solder in a PU resistor for the DAT line (if necessary), likewise maybe fore SEL line, although the final version looks slightly different than the last design I saw and maybe the 2nd optional resistor is to optionally connect up the ACK line…
To your questions, yes it should also work on the BB2. Usually when I can not get them to connect, I try only connecting up the power/ground to the receiver and see if they will link up. If not probably hardware problem. Do you have a V1 version you can use?
On the Botboarduino, is the Jumper to enable the PU resistor installed? Not always necessary as the PS2 code also enables the built in week PU resistor on the CPU, but sometimes is needed.
Not sure what else to suggest.
Kurt
Hi Kurt,
The transmitter and receiver do link up. Well… both led’s on the receiver turn on so I think they do.
But the led’s on the remote keep blinking. The on/off switch on the back doesn’t work. It is always on. And one of the 4 batteries get really hot…
Adding those things up sure looks like an hardware error.
So if I get it correctly the problem with the ps2 compatibility is that the NEW PS2 remotes are 3.3V and not 5V?
This means that the old 5V remotes should work with the BotBoarduino right? How did you get your’s to work? I have some V1’s lying around…
I have the JPU installed on the BotBoarduino.
Also the speaker on the BotBoarduino doesn’t beep either. Is it not used, or used differently? The BAP speaker beeps on powerup.
I’ve also tried to communicate with the XBEE module. But without any luck.
Thanks, Xan
Edit: I’ve added a picture of the boards.
Serial: Xbee (also tried on P6 and P7)
P6: black PS2_DAT
P7: green PS2_CMD
P8: yellow PS2_ATT
P9: blue PS2_CLK
P10: to RX on SSC
P11: to TX on SSC
Sounds is probably chicken and egg… I do play sounds when you hit the start button on the PS2… But since your ps2 does not work, well…
Not sure if you would see anything different, but here is a picture of the Botboarduino on my Quad:
As I said I am using a V1 PS2 remote. You can use the old cables if you like, but I prefer using 2 extension wires. Here is an example of one I have set up.
I have a tendency to put a piece of tape on the receiver and label each of the pins. As you can probably see, I remove the black plastic ends off of one end of both cables. Optionally if I want to be nice and safe I take some heat shrink and put that over each of the wires… Often I don’t.
I take cable one (usually the black wire) and connect it to the first pin(Dat), I then connect the 2nd wire to the 2nd pin (CMD). Then I skip the next pin and connect the black wire from the 2nd cable to the 4th pin(GND)(which is also the first pin in 2nd group), which is ground. Connect red wire from 2nd cable to the 5th pin(power). Then I connect the signal wire from the first cable to the 6th pin(SEL), and the signal wire from 2nd cable to pin 7(CLK). The last 2 pins are unused.
To use this, then I simply plug the first cable into IO pins 6-8 (DAT, CMD, SEL/ATT), and plug the second cable into 9 with black going to ground, yellow to signal…
Code compiles for xbee so will try that out later.
Edit: Also when I am not sure what is happening, I often go back to one of my different test programs. For example the Botboarduino test program. I commented out the I2C test as I don’t think I have the code in place for it. This code uses the Serial port with a baud rate of 38400. Bring up Serial monitor (button toward upper right of IDE. But assuming PS2 in the right place 6-9, plus SSC-32 on 10-11, there are tests that for example check to see if the speaker works. Also a PS2 test that shows the ps2 data as it changes. You press one of the buttons on the board to exit this mode. Also an SSC-32 test which issues a VER command and prints out what it received back (if anything)…
Kurt
Botboarduino_Test-130309a.zip (3.38 KB)
Can you try without anything connected to pins 0 to 2 just in case there is some interference?
Can’t quite see the connections between the PS2 level shifter and the BBuino.
Also, the code we have uses pins 12 and 13 for softserial (between the BBuino and SSC-32).
Yep - I meant to also suggest disconnecting the XBee from 0-1, as to allow debug output and the like.
Note: my code up on Github he mentions has the SSC-32 on 10,11 as set in the config file:
#define cSSC_OUT 10 //Output pin for (SSC32 RX) on BotBoard (Yellow)
#define cSSC_IN 11 //Input pin for (SSC32 TX) on BotBoard (Blue)
So I made sure the test program I put yesterday is configured that way as well. Either/both programs can easily be changed by updating some defines.
Kurt
Hi Guys,
Kurt, Love your little test program! Found out that the PS2 remote is defect. I replaced both receiver and remote with an old version and now it’s working again
Thanks!
Good to hear that it did the trick. Hopefully you are having some more fun again and playing with the quad code 
Kurt
I believe I integrated the last round of Quad changes into my Quad fork of the Arduino_Phoenix_Parts github. Changes also included allowing each servo to be able to be specified if it should be reversed or not. Defaults built in to main file. Moved/Renamed Symmetrical quad setup to be example under Phoenix, but did not test (don’t have that setup). Put debug outputs in code back under #ifdef plus under if… Plus migrated the change for servo inversion to other servo drivers.
Again little or no testing…
Kurt
