Okay, the setup is an ARC32 on a Phoenix hex. Powered by a 7.4 lipo that feeds the arc directly, and uses regulators @ 7.0 VDC to feed the servos. Now, the ps2 controller isn’t a Lynx controller, but it looks awful close. Only one the store had in stock at the time…
Anyhow, the normal operation for this reciever is one light comes on with power, the other blinks until it connects to the controller, at which point it stays on solid. I was powering it from the 5v/gnd pins on the AUX1 header, and it worked fine for months.
Then I made some changes to the wiring to clean it up a bit, and one of the things I did was reassign my servo pins so that I could open up the 28-31 pins for other things. I flipped the jumper to power it off VCC. Everything seemed fine, I turned the robot on and saw the reciever connect. Then I pressed the start button and the bot went to its home position, but the second the servos jumped, the second light on the PS2 reciever went out and it wouldn’t respond. After cycling the power, it still only has the one light on and will not connect to the controller.
I assumed I had done something wrong, or it was defective, and got another one, which did exactly the same thing. Probably not a faulty rx if it happened twice in a row. Especially if it connects at first and then fails the very second it recieves its first command?
Now, all I can think of is maybe the header I plugged it into experienced a voltage spike when the servos all jumped, and that fried something. Is that possible? I figure if I had it plugged into pin 31 it shares a more direct ground path with the servos compared to when I was stealing power off the AUX1 header.
Basically I’m just looking to see if anyone has either experienced this before, or has any thoughts as to what might have happened and how I can prevent it on (sigh) the next controller I buy. Any help would sure be appreciated…
Just tried a hardwired Sony brand controller and it works with the ps2 test program, but the Phoenix code wont respond to it unless I comment out a line in the code that checks that the controller initialized properly. But even then, the bot doesn’t function correctly. The servos all have a ton of jitter when I do it that way.
It responds through the console just fine though (servo calibration). So confused…
Try adding a short pause in the ps2 initialization routine. After sending before receiving. I’m not a great programmer, but I remember back when we were testing different brands and some were effected by adding pauses. You will have to experiment with it.
Well, finally made some progress. Bought another controller, this time I added its own dedicated 3.3v LDO regulator and 1k protection resistors on each of the data lines. Now the robot will turn on and actually move, all without frying the reciever!
Now on to the next problem… Running the newest Phoenix code, on a fully charged 2s lipo (with the low voltage commented out) it will get up and walk around a bit, then it lays down and ‘turns off’ within 1-3 minutes and the power has to be cycled before it will do anything again.
I also noticed it sometimes reacts slowly to an input… For instance if I make it lean and then let go of the sticks, it will take a second or two before it will go back to center. But only some of the time.
The good news is my turn came up to order a Raspberry Pi, so if I can’t make any more progress with the ARC I may ditch it, go to some therapy to repress all memories of ever using it, and toss the Raspberry Pi on there with a botboarduino…
Yes - It appears there are PS2 receivers out there that are not 5v tolerant, so yes hooking up resistors and the like should help.
If it were me, I would probably play around with the PS2 test program and see what type of results I was getting… There is a test program that is part of the tutorials: lynxmotion.com/images/html/build034.htm. You will have to modify to use the IO pins of the Arc32…
Alternatively I used to have debug code in the PS2 input control, that you could compile in, that would look at the data coming from the PS2 and if it was different than the previous time, would print it out on the debug terminal. That code was removed, but you can easily add the equivalent…
Do you have any sound on your Arc32? I have a simple speaker from Radioshack that I connected up to a servo extension wire that I plugged into my Arc32 phoenix. It also helps to debug, as if the code is hung trying to get the PS2 into the proper Analog mode, it will continuously make sounds… If this is the case, sometimes I have run into issues that some controllers don’t like to stay/go into extended analog mode… If this is the case I often change the lines that look like:
ReInitController:
if DS2Mode <> PadMode THEN
to look more like:
ReInitController:
if (DS2Mode & 0xf0) <> 0x70 THEN
There are I believe two places you would need to change. This relaxes the test to simply ask am I in Analog mode instead of am I in Analog mode and have an extra 18 bytes of data available(mode = 0x79), even though I am only using the 6 extra bytes, so mode (0x73) is perfectly fine… I also sometimes simplify the commands sent in the PS2 init as again we are not using all of the data anyway…
Also in cases like this, I use the LEDs on the board to help debug. For example maybe toggle an LED on the board each time you enter the ControlInput function for the Ps2. This way (assuming you can see the LED), you can see if the program is still trying to do something or completely hung…
Don’t have enough information here to help debug… Like is the robot hanging in PS2 stuff, or maybe you did not fully remove any LiPo test code or…
Hmm. I have been using a modified version of the PS2 test program though I haven’t tried it with the newest controller. I’ll load it up and see what happens. I’ll also try making those changes for analog mode and see what happens, thanks.
welp, looks like it may be a moot issue now. I was just tinkering around with it… made the changes to the code, checked the charge on the battery, bot still behaved the same way. Was going to ask if maybe the 1k resistors I added to the data lines could have messed it up. Remembered to try the ps2 controller test to see what it was seeing… Anyway, I plugged it back into the computer to load the code, flipped the on switch and a capacitor exploded! Guess I have another item on the to-do list…
