Are the PS2 sticks known to be erratic? I’m trying to control a pan/tilt with the left analog stick, but am not seeing any real change in readings and no change in positioning. I’m using code taken from the ps24wd1.bas program.
8-Dale
walter.bas (9.8 KB)
The Lynxmotion ones are usually pretty good. You still usually want some slop in the code, like + or - 2 or 3 from center (127 or 128). The old Sony wired ones that I have tried are another story! They don’t tend to get back to the same zero points…
Kurt
The code I am using is from the existing ps24wd1.bas program. As far as I can tell so far, I’ve ported over all the right bits of code. I’m not getting anything close to the movement I expected to get. I don’t know if I have messed up some timing or not though.
8-Dale
Hi Dale,
I think the problem is that you are computing a pulse width centered at 1500 with a range of: 750 to 2250, but then passing this directly to HSERVO.
But Hservo has it’s own input units, which are clock ticks centered at zero. which the conversion looks like: (X * 16) - 24000 for the Bap28 and
(X * 20) - 30000 for the Bap40/Arc32. (Another case where the code has to be modified to go between the two processors)…
So you might try:
hservo [PanServo(PanPos16)-2400\MoveSpeed, TiltServo(TiltPos16)-2400\MoveSpeed]
Kurt
Hi Kurte
Late last night I had an AH HA moment, and it finally dawned on me that I was not using the proper values due to having the Atom Pro. 
I did use the proper formulas in the rest of my code for the steering servos though. 
I finally got a formula that works for at least one side, but I think the reason it doesn’t work for the other side is my sticks never seem to go to 0 (meaning 0 - 255). I only seem to get 127 (centered) to 255 for the range on my sticks.
I will try this also.
8-Dale
Personally if it were me, I would change this part of the code into hservo units.
Change the init of the two values to 0 instead of 1500.
Change the update of values:
PanPos = (PanPos + (lhori-127)) MAX 12000 MIN -12000
TiltPos = (TiltPos + (lvert-127)) MAX 12000 MIN -12000
Then simply pass it through to the HSERVO like before…
If the pan/tilt move too slow or too fast I would then scale the values in these calculations…
Then again I like to change lots of code Example in your code I would change the normalize function to use parameters and a return value… Something like:
Normalize[NormalizeValue, NormalizeNull]
if NormalizeValue < (NormalizeNull-DeadBand) then
NormalizeValue = (127*NormalizeValue)/(NormalizeNull-DeadBand) MAX 127
elseif NormalizeValue > (NormalizeNull+DeadBand)
NormalizeValue = (127*(NormalizeValue-NormalizeNull)/(255-DeadBand-NormalizeNull) + 127) MAX 255
else
NormalizeValue = 127
endif
return NormalizeNull
Then your code using it can look a little cleaner… Probably produces about the same results code size/speed…
Gosub Normalize[lhori, lhori_null], lhori
Gosub Normalize[lvert, lvert_null], lvert
Gosub Normalize[rhori, rhori_null], rhori
Gosub Normalize[rvert, rvert_null], rvertBack to playing
Kurt
I changed the init as soon as I remembered the -12000 to +12000 range of HSERVO.
This does not seem to work. I am not getting response based on the stick position.
I will think about doing this. Right now, I don’t fully understand some of the code, so am leaving it be for now.
I agree. This is much cleaner.
Are the analog sticks supposed to go from 0 - 255? I am only getting 127 (centered) to 255 on my PS2 analog sticks
8-Dale
From the sound of it you are missing the most significant bit in your reading the PS2 routine. 
I copied the Read_PSX_Data routine directly from the ps24wd1.bas program. I only changed the name of it.
My current formula is:
TestPos = (((lhori - 127) * 1.411) * StepsPerDegree) ' MAX 12000 MIN -12000I wanted to see the raw value being created by the formula, which never goes negative. If my sticks would give values < 127, this formula should work fine for all stick values. I calculated the 1.411 constant by doing 127 (half stick range) divided by 90 (half servo range in degrees).
8-Dale
Have you tested the controller with our simple test code to display the values in the terminal? This would eliminate the math from the equation. wutha, remove math from the equation… 
Bwaaaahaaaahaaa
The printed out by that program go by so fast I can not tell what is happening. All I can see is lots of 255 values no matter what I do on the controller.
I have in my code:
serout S_OUT,i9600,"Remote, Left H: ",dec3 lhori\3,", Left V: ",dec3 lvert\3,", PanPos: ",sdec6 PanPos\6,", TiltPos: ",sdec6 TiltPos\6,", TestPos: ",sdec6 TestPos\6,13]
which does print the raw values. However, I am doing it at a slower speed.
8-Dale
You can click disconnect to see the values. If they are all 255 then you are on the wrong pins or something is wrong… This would be a good help for me if you could get it to work. This will eliminate any code issues you may be having. You said your code prints, but you never actually said what the values were.
This is simple really.
If the test code works, meaning you get 0-255 across the entire range of the controller, then you have a code issue.
If you get 127-255 repeated twice in the throw, or you get 0 until moving the stick half way up, then 127-255 through the rest of the range, then you have a hardware / PS2 controller problem.
I’m unable to disconnect while the test program is running. I actually can’t do anything in Basic Micro Studio (#30) while this program is running. In fact, I just had to forcefully kill BMS because it was sapping 20% - 60% of my CPU time and I could not get it to come to the foreground.
I do not get 0 - 255 on either of the analog sticks (horizontal OR vertical). All I see is 127 - 255, at least when I am doing my own serouts from my software. I only see 255 values from the test program, which is weird.
I only get 127 - 255 on the analog sticks when running my own code. I’ve never seen them go below 127. I can read all the buttons perfectly.
8-Dale
If you think you have problems with studio, then uninstall it and reinstall it. I’m approaching this with logic, but it’s not getting me anywhere. Troubleshooting is a process of elimination… Eliminate something already…
I do know how to troubleshoot. Just because you and I might go about troubleshooting the same problem in different ways, it does not mean either of our methods is wrong. I am confident all my connections for the PS2 controller are correct. If I reverse my PS2 connections, I get a very fast blinking connect light on the receiver. I change a single thing and then retest - otherwise I have no idea what caused any change that might occur.
Troubleshooting does not always involve eliminating something… I will continue working on this on my own.
Dale
I am an experienced troubleshooter. I was merely trying to help you. Troubleshooting is in fact a process of elimination. You determine what the possible causes are. Define a test. Test something, and depending on the results you may be able to eliminate a possible cause of the problem.
Your case involved a PS2 controller and code you wrote or modified. You state the program shows 127-255 from the joysticks. My test would have determined if it was the code or an electronic problem with the PS2 controller.
Do you see the value in knowing your PS2 controller is working properly before trying to locate a code problem that may not even exist?
I will get out. But I will also help if you want me to. I really do wish you well.
I’ve been doing this right along, but I may have misunderstood your definition of “eliminating something” as meaning something unintended. I interpreted it as meaning physically eliminating something, where it could have meant eliminating a possible cause.
I tried your test, but was unable to read any usable results from it. I could not see anything but a bunch of 255 values going by when I changed the sticks to different positions.
Oh, I definitely know the value in knowing the hardware is working good or not, and at present I don’t have full confidence in my particular PS2 controller and cable combination.
I’ll be ordering a brand new Lynxmotion PS2 Wireless Controller just like the one I have, so I can compare and have parts I can swap in and out so I can isolate the cause of this problem better. I’ll test the entire new controller, receiver, and cable together before I do any swapping of parts, and I will mark everything before I do anything at all so I know what’s original and what’s new.
Right now, I don’t really have a reference or additional experience with this to go by, so I can’t point a definitive finger at the cause of the problem. I only know what appears to be the problem, which may or may not be the case. The actual cause of the problem remains to be isolated. This is my first real experience with any remote robot control, and I need to have a known good (as in I test it and it works in all respects) controller to test with.
I think it would be really cool to be able to control WALTER’s four wheels using the analog sticks. I already have a tentative control scheme mapped out, and it will be quite interesting and I am sure unlike any remote control scheme you have seen to date if it works out. I’m also again seriously considering putting together a stock A4WD1 rover so I can run your stock control programs and get a better understanding of how they work. Rovers are much less expensive overall for me to play around with, and I really enjoy tinkering with them.
8-Dale
Hi again Dale,
As someone who has played around some with these for a bit, I would not necessarily use the word erratic for the stick values, but I do find that they do not have near the precision of some other things like a RC transmitter or our DIY remote control. I often only hit a few discrete values between the center location and full extents. For most of our projects like the brat or rovers this is sufficient. For some programs like rovers where you may want additional control sometimes we use another button/buttons to select a logical gear to help control the speed.
I agree with Jim that using the PS2 test program is a good start as it allows you to see the raw data from a simple program and allows you to see how the values change. If you were seeing all 255s, maybe you did not modify the program to work on P0-P3 (IE enable the built-in pull-up resistor). I modified a version of the program to do so. I also modified it to only output to the terminal if something actually changed. (I hate all of the endless scrolling of stuff as well)
If the values do not change properly then you can experiment changing pauses and the like. Sometimes if you query too fast, the Transmitter and receiver do not have enough time to talk to each other…
The test program also reads in 12 extra bytes of data that for the most part we never use. (it shows how much pressure is on each of the different buttons…). When we setup the mode value for 0x79 that gives us this additional information. Since most of my programs don’t use this data, I sometimes simplify my PS2 init code such that it leaves it mode 0x73. It might be worthwhile to see if the controller has more precession if it knows it does not need to produce those extra 12 bytes of data. My C Library code for example defaults to mode 73
OK now if you are happy with those results, the next thing I would look at if I were you was the function Normalize. I understand what it is trying to do, which is to try scale the returned value such that whatever the actual center point maps to 127(or 128) and two ends map to 0 and 255. That is suppose the observed center location is at 132 instead of 128. Then you have 132 values on one side of the range and only 123 values on the other side…
Personally for your use, I think you could skip all of this and could easily simplify this and simply say if the joystick value is within the deadband units of center, set it to your logical center, else use it as is…
Got to go.
Kurt
test.bas (3.81 KB)
The “erratic” was a question only - I should change the topic name a bit. This is my first experience with the PS2 controller as a robot controller. To control WALTER the way I would like to will require three analog sticks - two for wheel control and one for the pan/tilt on the front. I could probably use the D-Pad for the pan/tilt though, but I have other plans for that. I really want a DIY remote, but am really unsure if I could pull off building one, at least not all of it.
I did not modify it for P0 - P3 and to use the pull-up. I just made that change and reprogrammed it. Still not sure what I should be seeing and where, but I am seeing a lot of zeros now until I change something on the controller. I definitely don’t like all the continuous scrolling - it really makes it impossible for me to see what I need to see and follow it properly. I will try your version.
I see where timing is very important with all this.
I don’t see any use for this additional data for my control purposes either.
This is probably true. However, I still have not fully analyzed all of the code I took from the ps24wd1.bas program, and therefore don’t understand a lot of it yet. I am not able to dig into analyzing code like I used to be able to do so it takes me much longer to gain the understanding I need.
8-Dale
Kurte,
I like your version of the test program MUCH better! Now I can actually see what I need to see without all that scrolling making my eyes do things I would prefer they not do. Now I see that my analog sticks are returning values < 127, but that leads me to another question.
I have:
serout S_OUT,i9600,"Remote, Left H: ",dec3 lhori\3,", Left V: ",dec3 lvert\3,", PanPos: ",sdec6 PanPos\6,", TiltPos: ",sdec6 TiltPos\6,", TestPos: ",sdec6 TestPos\6,13]
Shouldn’t this print out the proper values for the left stick? Maybe I am suffering from the fast scrolling thing with this also, and am missing what I need to be seeing.
I just had to forcefully kill Basic Micro Studio #30 again (after uninstalling and reinstalling it) while Jim’s ps2test program was running on my Atom Pro and outputting to the serial console.
8-Dale