Kurts Ps2 Brat

Well my parts for a new PS2 brat arrived two days agao and I have most everything built. I am having some fun :smiley:. Some current photos (with no dust):
http://i416.photobucket.com/albums/pp245/Kurts_Robots/DSC03298.jpg
http://i416.photobucket.com/albums/pp245/Kurts_Robots/DSC03299.jpg
Things went together pretty smoothly. So far I don’t have any weapons to mount on the two ends. Not sure what the best way is to mount the L brackets on the round top. Currently each one just has one screw and nut holding them. Will investigate more when I have something to mount there. Will soon also mount the wireless camera to the front and maybe an IR sensor.

I like the DIY ps2 cable, it made it small enough that the PS2 receiver fit inside the 4 standoffs of the electronics carrier behind the BB2 board. I also still need to cleanup the wires.

One minor issue I ran into with the PS2 Brat tutorial lynxmotion.com/images/html/build155.htm is in step 4 it mentions setting the baud rate to 9600, but I think the downloaded offsets program outputs at 38400. No big deal.

Now to start playing with the brat code. I made some modifications to the earlier code, like converting the movement functions to be integer based instead of floating points, which I will now start to debug.

Kurt

Well I updated the brat code to convert everything to fixed point math instead of floating point and I think I have things working now. But I am not sure in this simple case how much it is worth it. So I created a simple TimerA counter with an ASM interrupt handler and instrumented the Movement function. For example here is the integer version:

[code];--------------------------------------------------------------------
;[MovementCB] = This callback will be called by movement in a loop in between when HServo is called and
; while it waits for the Hservo to complete. The function has the ability to abort the wait and potentially
; other calls to movement by setting the variable fAbortCommand. Note Movement will not clear this flag, as
; this will allow whole sequences to be aborted easily.
MovementCB:
gosub PS2INPUT[0] ; call Ps2input but tell it we are not the main loop
return

;--------------------------------------------------------------------
;[Movement] - This is the main Hservo interface. This function takes new positions for each of the Legs servos
; in 10s of a degree as well as the time we want the movement to take. We then compute the speed
; of each of the servos, such that all of the servos complete their moves at the same time.
; This function does not return until the servos have completed their movement.
;
; This version has a call back function that is called in a loop after the HSERVO command has issued, until
; the movements have completed. This allows the program to call off to other Input devices or dow other background
; tasks while the movement is active.
;Should never need to edit anything below this line. Add user subroutines above this and below main.
lefthippos1 var slong
leftkneepos1 var slong
leftanklepos1 var slong
righthippos1 var slong
rightkneepos1 var slong
rightanklepos1 var slong
last_lefthippos1 var slong
last_leftkneepos1 var slong
last_leftanklepos1 var slong
last_righthippos1 var slong
last_rightkneepos1 var slong
last_rightanklepos1 var slong
lhspeed var slong
lkspeed var slong
laspeed var slong
rhspeed var slong
rkspeed var slong
raspeed var slong
MoveTime var slong
MaxSpeed1 var slong
longestmove1 var slong

;movement [lefthippos1,leftkneepos1,leftanklepos1,righthippos1,rightkneepos1,rightanklepos1,speed1]
movement [rightanklepos1,rightkneepos1,righthippos1,leftanklepos1,leftkneepos1,lefthippos1,MoveTime]
TCA = 0 ; clear out the counter
wTimerCnt = 0 ;
enable timeraint
; several step movements may be interrupted, so check flag and return.
if fAbortCommand then
return
endif

if(MoveTime<> 0)then
gosub getlongest[lefthippos1-last_lefthippos1, |
leftkneepos1-last_leftkneepos1, |
leftanklepos1-last_leftanklepos1, |
righthippos1-last_righthippos1, |
rightkneepos1-last_rightkneepos1, |
rightanklepos1-last_rightanklepos1],longestmove1
MaxSpeed1 = ((longestmove1*stepsperdegree1)/(MoveTime/2))
gosub getspeed[lefthippos1,last_lefthippos1,longestmove1,MaxSpeed1],lhspeed
gosub getspeed[leftkneepos1,last_leftkneepos1,longestmove1,MaxSpeed1],lkspeed
gosub getspeed[leftanklepos1,last_leftanklepos1,longestmove1,MaxSpeed1],laspeed
gosub getspeed[righthippos1,last_righthippos1,longestmove1,MaxSpeed1],rhspeed
gosub getspeed[rightkneepos1,last_rightkneepos1,longestmove1,MaxSpeed1],rkspeed
gosub getspeed[rightanklepos1,last_rightanklepos1,longestmove1,MaxSpeed1],raspeed
else
lhspeed=0;
lkspeed=0;
laspeed=0;
rhspeed=0;
rkspeed=0;
raspeed=0;
endif

; Note, the positions are in 10s of a degree and the steps per are in 10s of degree so need to divide by 100
hservo [lefthip(-lefthippos1stepsperdegree1)/100 + lefthip_start\lhspeed, |
righthip(righthippos1
stepsperdegree1)/100 + righthip_start\rhspeed, |
leftknee(-leftkneepos1stepsperdegree1)/100 + leftknee_start\lkspeed, |
rightknee(rightkneepos1
stepsperdegree1)/100 + rightknee_start\rkspeed, |
leftankle(-leftanklepos1stepsperdegree1)/100 + leftankle_start\laspeed, |
rightankle(rightanklepos1
stepsperdegree1)/100 + rightankle_start\raspeed]

gosub GetTimerVal
disable timeraint

wMovementCalls = wMovementCalls + 1	; number of times we called this.
lMovementDTSum	= LMovementDTSum + wTimerCnt

     ...[/code]

So I am only measuring the conversion times up through the call to HSERVO. I then added code to the processing of the start button, that when we hit start to turn off the brat it dumps out the counters.

For the integer version I get: Calls: 33 Tot: 43961 Avg: 1332

For the floating point version I get: Calls: 25 Tot: 34503 Avg: 1380

The counter is clock/32 or 2uS. So the floating point/integer math cost about .1ms per call to movement. Probably not worth the trouble :frowning:

Thoughts?
Kurt

Nice idea putting the receiver in the back of the BRAT. I wish I could get back into using my BRAT, but I still need to get a replacement 475 (I reversed the polarity and smoke was emitted. :frowning: ).

As far as the programming, I can’t really understand what you are saying, but if it only saves you about 1ms, I don’t think it is worth the trouble.

Brandon

With Hunchback, I attached the L brackets as you did, then drilled a few holes so that I could use three of the mounting holes. 8)

Yep, I sort of figured you might do that, but I was not sure we were allowed to use power tools. :laughing:

From your first set of pictures I could not tell if you maybe used some other metal plates or brackets. But it is probably best to keep it simple…

What power tools? I used my bare hands! :laughing:

Nope. No plates or brackets, just additional holes and zip ties. :stuck_out_tongue:

Ok, So I now have the three brackets screwed into the top plate with three screws each. I cheated and used the power tool. :laughing: Also have some switches (some different ones than the picoswitches) coming and ordered from toys east…

So I have been playing around with the code. I have the similar code that I posted on Fish’s thread earlier that added a callback from the Movement function to allow me to process other stuff while waiting for the HSERVO to complete. It is using the integer math version of these functions. I have it properly doing a query of the PS2 controller and seeing that the user wishes to rotate the turret and issue the proper HSERVO command for that.

However I have run into a roadblock. That is while issuing a second HSERVO on other pins should not impact an HSERVO that is in process on other pins. But in my case it appears to be doing so. Not sure yet if it is changing how the HSERVO command is running or if it is only is impacting the information that gethservo is returning. I have posted questions out to Nathan(AcidTech) with a stand alone sample program, so hopefully we should be able to resolve this. The following image shows some of the timing problems:
http://i416.photobucket.com/albums/pp245/Kurts_Robots/HServo-with-callback.jpg
Input 7 shows when I call movement (I simply toggle the IO line each time). Input 8 shows when my callback is calling HSERVO. As you can see the timings on the first part where hservo is called is not consistent, whereas when it is not called as in the second half of the trace it is consistent…

In the mean time I am thinking of trying a different approach. The current walking code has broken each step into a sequence of 4 steps, similar to the early Brat code that had fixed sequences like:

gosub movement -7.0, 20.0, 20.0, 7.0,-20.0,-20.0, 0.0, 500.0] gosub movement 7.0, 20.0, 20.0, -7.0,-20.0,-20.0, 0.0, 500.0] gosub movement 7.0,-20.0,-20.0, -7.0, 20.0, 20.0, 0.0, 500.0] gosub movement -7.0,-20.0,-20.0, 7.0, 20.0, 20.0, 0.0, 500.0]
Now the code is takes the PS2 joystick positions to generate the actual values, but it still has each movement take about .5 seconds. My idea is to update the movement function to break down the movements into sub-movements that take maybe .05 or .1 seconds, and after each call to HSERVO it would check the input states to adjust the values for the Turret (maybe guns), to be issues as part of the hservo call within Movement. Not sure if I explained it well enough, but…

Any other suggestions?
Kurt

I thought I would give a quick update. I think I know what was wrong or at least a way around the issue I mentioned in the previous post (Thanks Nathan).

But while doing it I have now have a version that does break down the moves into smaller sub-moves that take a max of 100 time units. This appears to be working. I still need to test and compare this walking both how and speed versus the previous version. I may add code to allow me to use the PS2 to change the timings… I am also in the process of integrating the features of the Hunchback into my current version.

My version of the brat code and the Brat servo offset finder also now save and retrieve the offsets into the EEPROM of the Atom Pro. So I can go back and forth between the two programs to tweek the offsets.

Having fun!
Kurt

I think for awhile I may take a diversion from the making the brat work, twist and shoot at the same time. For one reason I don’t have all of the needed hardware yet. The toy parts were shipped yesterday from Toys East with a 12-14 day estimated arrival time and the switches have not arrived yet either.

Yesterday I had an unplanned diversion, when our water system went dry, which is saying something with 2 wells and a 2800 gallon tank. Took me awhile to find the leak, which was an underground connection of the 2" main line coming from the pump house. We found wet spots below, but the water was traveling along the sand in the trench so it took awhile…
As this is about the third time we have had tank draining problems, I may do some other diversion to mount some sensor on the tank that somehow signals me when the tank gets maybe half empty… Not sure what yet.

But my planned diversion is to convert from using the PS2 controller to using a modified version of the DIY transmitter/receiver. I am planning to update these to use XBEE modules. So far I simply have two XBEES talking some. One is connected to an atom pro. It is mounted in a AppBee-Sip from selmaware selmaware.com/appbee/index.htm, which takes care of the 5v to 3.3 v conversions. Could probably also use this one from SparkFun sparkfun.com/commerce/product_info.php?products_id=9132, which is a lot smaller. Yesterday I simply had the second unit plugged into a Maxstream USB module connected to my PC running X-CTU…

My first version program simply had my Pro send out Hello World strings, which worked. Now I will probably have it switch baud rates to 115200. Also I thought I might try out XBEE and the Appbeesip which bring out the RTS line converted to 5v. With this the XBEE should be able to buffer up any input it receives and wait until you do a serin with the RX\RTS pins to receive information. Of course I could also use HSERIN/HSEROUT.

Next step will be to change some of the DIY transmitter code to build a packet to send with all of the information. Also write a simple receiver function that receives and verifies the info. May first try it on my Hex as I had versions of this code that worked with the DIY so simply need to replace that function.

Then on to the Brat and. May get a third simple XBEE/board such that I can change the DIY transmitter code to have a function to choose which robot to control, likewise maybe another one on the rover…

Also may add functionality to send information back from the Bot to the DIY to display on the LCD. For example maybe have an IR sensor and display the distance on the remote LCD. Should be fun. Not sure if I should describe the progress here or back at the DIY stuff…

Another idea that came to mind that I may play with at some point, is to interface 1 or 2 WII nunchucks to an Atom Pro. There are simple connectors/boards to connect the numchuck to a micro-controller. They use I2C communications. So would then simply need the controller to package up the data and send it out using an XBEE. But…

Kurt

Bummer about the water situation… Whoa, 2800 gallons emptied into the ground! Yikes, look out for sink holes! We are on a well and the biggest problem is when there is no power, there is no water. lol Our well is only 80 feet deep. I imagine yours is a great deal deeper than that. :wink:

Sounds great on the new direction kurt! Would you recommend us getting the spark fun units? Is the code universal enough, or should we get the exact same hardware as you. This will ensure the BRAT Mech can be run at the competition without issue. 8)

Hi Kurt,

Sorry to hear about your water system problem. It do remind me of a problem my father had this spring (my mom and dad lives far up the mountains). He also has a well with a water pump system. To make it short, the water thank almost exploded! :open_mouth: The safety system that should stop the pump didn’t work… So the pump kept increasing the pressure until my mom came to my dad and said she heard a very strange sound… :unamused: The water thank was very old and rusty so it ended with a big crack/hole. :laughing:

Your XBEE project sounds great! Maybe using the DIY thread is the right to use? Or a new XBEE thread?

Keep up the good work about it and keep us posted. Thanks for sharing your ideas, sounds like an excellent idea to send data back to the DIY. That would make it easier to make a menu system on the DIY so that the robot can send a signal back for telling the DIY that the command was received. Also sending sensor data was a great idea!

This should not be difficult, since there is quite a lot of info on the internet about interfacing the nunchuk to various systems. The fact that it can be done using I2C should make it fairly straight forward. I’m not sure wireless I2C would work though since there are timing considerations on the bus. You would have to capture the binary I2C data that would normally be sent directly from master to slave and send that over the wireless serial link and then ship it off to the remote I2C device. There may still be timing factors to deal with, but I think it should be possible to do. I’ve done some work with I2C, and it can be a pain sometimes, but is worth getting to know how to use.

8-Dale

Thanks, Actually probably lots more than that went into the ground. We had wet areas starting in the winter that we thought it was runoff down the hillside. I think the leak just got worse and worse until the wells could not keep up. Both wells are over 400 feet down, mostly through solid rock. Luckily we had the presure pump wired up with an extra float at the bottom, so it shut off before it could burn up…

It is hard to say. Here is a picture showing three different XBee holders that I have:http://i416.photobucket.com/albums/pp245/Kurts_Robots/DSC03306.jpg
It shows an ABB card that I am currently using to play with some of this code with. The largest of the cards is the Maxstream(DIGI) card that connects up to the PC with USB. I purchased this one when I thought I wanted to flash some of the chips to other versions. The one that has wires on it is the selmaware version. This is the one I will try using first. The smallest/Red one is a USB one from sparkfun, I purchased this before I purchased the DIGI one as it was cheap and USB, but some of the utilities (X-CTU) say things like hit the reset button, which this one does not have. The other one I mentioned getting from sparkfun is I think the same size, which is a lot smaller than the selma version (but does not bring out the RTS line).

If RTS does make serin work a lot better, than I wonder if we could simply solder a wire to it and take it to one of the two IO pins on the BAP28 that appear to only output 3.3 volts…

I am leaning as I am going, so at this point I don’t see any reason to choose one of these boards over the other, except price/availability.
Selma version is ($15 + 5$ to assemble) Sparkfun ($9.95). I plan to purchase a few of these sparkfun units to play with. Also may get a few more of the series 1 XBees to start off. I do have a few of the XBee Pro 2s. But series 1 and Series 2 don’t talk to each other… The pro version may be nice as they are higher power and can talk farther, but then again it would influence the run times on batteries.

Once I get going fully on this I will move to a thread in the Remote Control forum.

As for universal enough, it will depend more on what you all use in the competitions. If you go with something similar to DIY, than most of this should work fine. If you go with a gutted PC joystick with other buttons, than the UI portions of the code will change, likewise if I do setup a WII version, which as lynxguy mentioned may not be difficult.

Well back to play

Kurt

This is great! I opt for the smallest one of course. But maybe the higher power one, we’ll need to see specs to decide. Man I just ran out of time. I gotta run. See ya next Tuesday. Have a good weekend!

I took a slight detour from working on the XBee to install the guns on my Brat. I currently have them wired in using two pico switches.

I have done the wiring of the guns as mentioned in the thread:lynxmotion.net/viewtopic.php?t=5221

Now I am playing with the software. I currently have it that the left gun or right gun will continue to fire as long as I have the L1 or R1 button down. I believe that James(Fish) has his code to turn off after it fires, using the switch that is bultin to the gun. I think I will combine the two. If you quickly click on the gun it will continue until it fires once. If you hold it down it will continue to fire…

Then back to XBee.

Kurt

Very nice! I like the option of selective fire.

Quick update,

I did update the code to handle the guns as I mentioned, which when you released the fire button, it would start looking for the IO pin associated with the switch of the gun until it went low. Then I found I could not turn one of the guns off. So I am pretty sure one of my wirings is not working properly. So I updated the code again, that if it is waiting for the gun to fire and you press the switch again it cancels the gun then… that way it works fine until I fix it and is a nice failsafe to have anyway…

Kurt

My code actually does this. The internal button is only held down for a moment, so if you’re holding the button down, the motor just keeps on going.

Wow Kurt…catching up on this thread as I intend to ender a BRAT for Robo Warfare in April. You have done some excellent work!

I should be getting my parts from Lynxmotion next week and start working on my BRAT. Hope to post my progress on this board.

Mark