I recently purchased two sets of the Lynxmotion wireless controllers and receivers along with the controller cable for a robot I am upgrading. I only need one set, but I bought two in case something goes wrong with one of them. It turns out there might be something wrong with both sets as I am having an avalanche of things not working right.
Controller #1 seems to respond to fresh batteries, but has some funny behavior. When pushing the ANALOG button for the first time, both red and green LEDs on the controller blink twice then turn off. A second press of the ANALOG button results in just the red LED staying on for a few seconds before turning off. This pattern seem to repeat on subsequent button presses.
Controller #2 appears to be DOA as there is no LED activity regardless of what I do.
Receiver #1 has the green LED on but the red LED will either not come on at all or blink for a little while and turn off.
Receiver #2 has the green LED on and the red one constantly blinks, but not seem to make a connection with the controller.
The receivers are plugged into the controller cable which is connected to my Axon II microcontroller. Power is provided by the 5V regulated bus. I have tried every controller and receiver combination with no luck at all. I do have an actual PS2 wired controller that I am using until I get all this problematic wireless stuff straightened out and everything works just fine. Joysticks move the servos and button presses perform other functions. Horray!
I seriously feel burned by all this, though I am sure there is some kind of solution out there. Please advise. Thank you.
I will leave it for Lynxmotion people to talk about possible hardware failure. With the Controllers, I would of course double check batteries…
Controller 1 sounds like it might be working fine. Also Receiver 2 sounds like it might be OK… Now to some possible ideas and or issues.
Note: I have had one of these working on an Axon2 awhile ago. My Code for the PS2 was last modified in July 2010, so I may be a bit rusty with the Axon2.
I have had some receiver/Atmel processors, whose processor built-in pull-up resistor on the DAT line was not sufficient. I had to add an external one, from +5v to DAT. I did this inside the receiver case (in the back side of the connector…)
To try to see if a Transmitter and receiver will connect to each other, sometimes it is easier if only the +5v and GND are connected. That keeps any issues of software from interfering.
If above works. I have found (on multiple processors). If I have code running that is constantly asking the PS2 receiver for data, it does not leave any time for the receiver to talk to the transmitter and will be in constant blinks. Solved by adding more time between calls.
You did not mention, what code you are using to talk to PS2. I was not using the code that was later added to webbotlib. Not sure if you are or are not… Not sure what init it uses. Sometimes the init code/timing can be temperamental…
Hello kurte! You’ve given me some things to think about and try. I’ll go down your list in the order attempted.
No luck.
I believe that I have the appropriate resistor (10k Ohmz) and will implement one by the weekend. If I should use a different value, please let me know.
I tried gradually bumping up the time between calls all the way up to 1 full second without the resistor just to see if that would work. Needless to say, I am still here typing.
To avoid any confusion, I just want to point out that each of the two sets has one part that does not seem to work. One set has a controller that seems to work and a receiver that does not whereas the other set has a receiver that seems to work and a controller that does not.
I took the seemingly functional components and hooked them up to my robot and both seem to work. They don’t talk to each other at the moment, but that might be remedied by one of kurte’s suggestions.
I will most likely be making a return or exchange, but will I have to send all the parts back (since technically both sets are in some way defective), or can I just send back the bad controller and bad receiver as one set?
Well, that was quick! I went ahead and applied the 10k resistor to the DAT line and reconnected the receiver…to no avail. I plugged the wired controller back in just to make sure I did not screw anything else up in the process and it still works. Whew! Glad at least that went right. Okay, now…what to do next…
Thanks for the info. I was not aware of that one. I don’t mess with resistors much. Heck, there are days when I don’t know the difference between a microchip and a potato chip…aside from the fact that they crunch when you step on them! I’ll pick up some 1k resistors and try again.
I called up this morning and explained the situation. Another controller set is being sent today and I will return the bad controller and receiver in the SASE when the replacements arrive.
Poop! Still no good, but at least there was something of a different result. The receiver at one point had both LEDs on (as opposed to the red one blinking all the time). Using the controller did not make the robot move however. However, I did gradually bump up the delay between calls to the joystick and after going all the way to 1 second again, I still had no desired result.
What code are you running on the processor? Are you using webotlib? I was running my own code with my brat. Since then I needed to change to a different processor on the brat to test out the Arduino code. But if I get some free time I might be able to try running a simple test on my axon2.
The part of my code that employs the use of the PS2 controller is as follows:
[code]
stickVal=controller.joystick(PS2_STICK_LEFT_Y); // gets value of Y-axis on left joystick.
servoVal[2]=servoMoveServo(2,stickVal,1); // moves one servo according to that value
stickVal=controller.joystick(PS2_STICK_RIGHT_X); // gets value of X-axis on right joystick.
servoVal[1]=servoMoveServo(1,stickVal,1); // moves another servo according to that value
if (controller.buttonsChanged())
{
buttonVal=controller.buttonsRaw();
// each button press triggers a function call which moves servos or triggers other devices connected to the microcontroller, but have no impact on joystick functionality.
switch(buttonVal)
{
case 1024: // L1
someFunction();
break;
case 1: // Select
// code
break;
case 8: // Start
// code
break;
case 2048: // R1
// code
break;
case 4096: // Triangle
// code
break;
case 8192: // Circle
// code
break;
case 16384: // X
// code
break;
case -32768: // Square
// code
break;
case 272: // L2 & DPadUp
// code
break;
case 288: // L2 & DPadRight
// code
break;
case 320: // L2 & DPadDown
// code
break;
case 384: // L2 & DPadLeft
// code
break;
case 528: // R2 & DPadUp
// code
break;
case 544: // R2 & DPadRight
// code
break;
case 576: // R2 & DPadDown
// code
break;
case 640: // R2 & DPadLeft
// code
break;
}
displayInfo=true; // variable used by another part of code; has no impact on joystick functionality
}[/code]
It may take me a little time to get set up again, as I have moved to new computer, removed the Axon2 from robot… My Brat was written using version 1 of webbotlib and I rolled my own PS2 code.
I have included a zip file here of what code I had at the time… I also have the beginnings of a version of this that I used project designer for and used the PS2 code from webbotlib, but I don’t remember what state that was in.
My assumption also is that you have your PS2 hooked up to use the regulated +5v power and not the unregulated. Too high of a voltage will also keep it from properly talking…
Kurt
Should also mention, that at times it is hard to get the sender/receiver to sync with each other. Sometimes I have better luck if while I do a reset of the processor, I have the transmitter off, then turn on and at times it may take a couple of attempts. Depending on the underlying code sometimes I need to hit the Analog button to get them into the proper mode. Again a lot of this depends on the timing of the code. DeBrat Checkpoint.zip (29.7 KB)
I really do appreciate your time and effort on this. Hopefully, something good will come out of this. I have the control lines plugged into E4, E5, E6, and E7 with power plugged into the regulated bus (F1, to be specific).
I pulled out my board, powered it up, used project designer, went to AVR studio, built the hex file, tried the GUI boot loader and it failed as I am running 64 bit os. Would have thought someone would have fixed that in the last 2 years
Well, I was able to program my Axon2 with my AVRISP2… So I built a quick and dirty Webbotlib (c++ version) project with the PS2 on a software SPI bus and tried it out and it did not work at all. I hooked up my logic analyzer and was not getting any data at all back on the DAT line. The CMD, CLK, and SEL lines were doing stuff… But it looked like it was trying to use a different command to do a query. Here is a screenshot of the data on the logic analyzer.
So I hacked up a new project, used my old PS2 code and it did talk. Not sure if it is 100%, but I was able to get it to print out data when it changed… Here is a screen shot showing the correct data:
So you might try, this project and see if at least your PS2 will talk or not… Then you probably need to contact WEBBOTLIB and say there is a problem… I have included both test programs in the zip file. Axon2 PS2 Test Programs.zip (39.4 KB)
Well, I tried using Kurte’s code to resolve this wireless controller issue. The wireless controller still does not work, but the red LED on the receiver did stay lit this time while the controller had the sequenced blinking LEDs (when pushing the analog button) as mentioned before. The wired controller continued to work properly.
I’m not sure if this make any difference, but I just want to provide some previously unmentioned details. I said earlier that I have the control lines plugged into E4, E5, E6, and E7. More specifically, the layout is: MOSI is E5, MISO is E6, SCK is E3, and Select is E4. It is within a software SPI bus with the Master Mode box checked.
Kurte, you mentioned that your attempt to use a software SPI bus did not work at all. As of now, I have not tried using a hardware bus per the statement in the webbotlib docs (webbot.org.uk/WebbotLibDocs2/46240.html) about using a software bus over a hardware one. Just for the heck of it, I will try a hardware bus, but I am not exactly sure what lines gets plugged into what pins.
In the meantime, Lynxmotion has sent me another wireless controller to replace the defective unit that I previously mentioned in the thread. I will try it out when I get home tonight.
As I mentioned previously, I confirmed that the Wireless controller was not working with Webbotlib on an Axon2. I never noticed it before as I had not used my Axon2 for awhile and when I developed my Brat code for the Axon2, webbotlib did not have any support for it so I rolled my own…
What I found out yesterday is that with the Software SPI (have not tried hardware), the Wired PS2 appears to work when you do the transitions on the trailing edge of the clock and the wireless appears to work when you do it on the leading edge. I hacked up changes in the ps2.h file (part of each release) and was able to get the wireless to work. Should be a way to get both to work.
Webbot has not been able to test this as he does not have a wireless controller. I will see if having two different macros and options in his definition software is sufficient, or if I can find a way that works for both without changes.
