Maybe we should put a 3.3v regulator on to supply the PS2! Other things (like cameras and WiFi modules) need 3.3V as well. A BBII-compatable WiFi module w/regulator would be interesting!
Alan KM6VV
I am going to be doing that I think today, but something that I keep thinking about is that there are not allot of people who are having an issue with the PS2 module.
I get these from the largest manufacturer of game controllers. But they are extremely cheap. If they work out of the box, they are usually good for life. I’ve never heard of anyone having them fail after they were working for a time. We can replace it if it’s been less than 30 days since purchase. Beyond that it’s an electronic device that hinges on user made connections, of which we have no control. We win some and we loose some, but overall it’s a reliable product.
Hey Jim,
I just got this last week, I will send an Email and get this back to you… Thanks
Hi kurt
Moved speaker to P7, same results. will i have any issues if i use digital servo?
EDIT I think I found my answer I have a few servos that are new out of the box that are acting odd (i’ve had some of them over a year+)
Kurt,
I’m trying to load your XBEEBRAT on my BAP28. I’m unable to get it to compile. I get
Error: FILE F:\DIY XBEE - PACKET MODE\XBEE PROJECTS\XBEE_TASERIAL_SUPPORT.BAS(LINE 561) : [TOKEN BHSERINHASDATA] : Redefining to Variable
Error: FILE F:\DIY XBEE - PACKET MODE\XBEE PROJECTS\XBEEBRAT.BAS(LINE 255) : [TOKEN ,] : Unexpected token type
I’m i trying to install on the wrong board?
Hi Phil,
I have not tried getting it to run on an Arc32 yet. Maybe I should try to compile it. Let you know maybe tomorrow…
Kurt
Hi Phil,
It has been awhile since I looked at the brat code and it indeed is currently busted.
The variable you mention was defined twice, once in the main program and again in that file. So you can remove it from that file. Then you will find that another variable is not defined. If you search on that variable you will find it is commented out. So uncomment it. Then you find the code is using the old GetHservo call so need to change to the new command.
Two place here:
After some quick changes those look like:
IF (ABS(bPacket(PKT_LJOYLR)-128) > TravelDeadZone) THEN
; We also only process this if the turret servo is idle
if(hservoidle Turret)thenand
do
notidle = !(hservoidle lefthip) or !(hservoidle righthip) or !(hservoidle leftknee) or !(hservoidle rightknee) or ! (hservoidle leftankle) or ! (hservoidle rightankle)
if notidle then
gosub MovementCB
endif
while (notidle and (not fAbortCommand))
Note: currently I don’t have a brat setup with a BAP28 on it to test it out…
Kurt
Kurt,
Made those changes and was able to complie the code. I want to use the brat code to learn how to control the legs.
I have the upper torso of my biped constructed and the legs waiting on a purpose. I want to hopefully have a complete biped
running on an ARC32 when I’m done. I thank you for all your help
Phil
Hi good morning, for there using the 2 sliders on the control of the robot. Or not used?
Hi, Sorry I do not understand the question.
If you are asking, with the DIY remote control, do we send information about the position of the two sliders as part of the data packet that we send to the robot, the answer is yes.
If you are asking do the different robots use this data, it depends on the robot, but all of mine use some of it…
Kurt
I would like to have information on the remote control. and know it is used for the 2 sliding.
img593.imageshack.us/img593/2541/diyremote26800.th.jpg
Uploaded with ImageShack.us
ok, thanks
hi,
another one in progress
pot not mount yet. I received it with button today
thanks to all for your work
Looking Good!
Kurt
Hi Kurt,
I hope you are doing fine!
I’ve tested your latest API mode code (finally! 
). Since I’m using the extra potmeters I had to do several adjustments, but I’ve the DIY transmitter running fine (just some minor LCD bugs that I’ve to look into). So far just tested on the T-Hex robot. I got some few minutes yesterday for testing. The communication and control of T-Hex seem to work fine, except for one thing. When doing continuous body rotations I get the same bug that I got when using the ARC-32 running the non-API mode, similar to what I posted earlier in this thread:
I’ve not tested if the bug disappear if I don’t send the LiPo voltage to the transmitter yet. Anyway, the problem is that the robot halt for about 0.5 sec now and then ( a bit random). I did never had this problem with the other XBee code.
I hope to do some more testing about it later today. I’ll post the code in my T-Hex thread afterwards.
Like I asked you in the other post; Did you try sending values back from the robot to the DIY transmitter?
Hi Zenta, I have not played with that part in awhile, so looks like a little more testing to be done. Maybe there is some place trying to do a resync that does not need it…
Kurt
Hi Kurt,
Ok, I’ve no idea whats causing this and I’ve not much free time for debugging. But I hope to do some more testing to verify that its the XBeeOutputVal sub that causes this, simply by comment the line (like I did for the ARC-32).
So until the bug is solved I think I’ll stay on the old XBee code since I need my robots to work perfect for a little robotic course I’m going to hold on two local libraries. They are going to arrange a “robot day” for school kids, so its going to be fun! 
I’ve done that before. Taken the bots to the local schools for a show. It’s really fun to see the wide eyes of amazement from small children. That was years ago though. You will do a great job I’m sure. 8)