Axon2, Lynxmotion PS2 wireless controller and Webbotlib...

[KurtEck]

A Lynxmotion forum member did some posts up on the Lynxmotion forum, about having problems getting a Lynxmotion wireless PS2 controller to work on an Axon2, using webbotlib.  In fact the person ordered two of them and neither of them worked.

I thought I would take a look at it as back in 2010, I had my old Biped Brat working on an Axon2 with a PS2, with an older version of webbbotlib.   So I used project designer and the like to create a simple test program and sure enough it could not talk to the PS2.  I then created another project, but instead of using the webbotlibs implemention for a PS2, I used my own and it worked.  There is more details, including a zip file with both test programs, and pictures showing the Logic Analyzer data from both up on the Lynxmotion fourm thread: http://www.lynxmotion.net/viewtopic.php?f=22&p=80457#p80457

Kurt

Kurt

[Webbot]

Thanks Kurt. I must have introduced a 'funny' somewhere. I'm away next week - but will get around to having a look when I get back

[tzankoff]

A week?!?!?
Nooooooooooooooooooooo!
 

I'm kidding. I can wait a week. Besides, I have other upgrades to my robot that I can do while I wait.

[Webbot]

Ok - back home now - it looks like the controller is not initialised by the code from PD.
Try to fix it by adding the code yourself in, say, appInitSoftware or at the end of appInitHardwasre by adding a call like:-
C:-
sonyPS2_calibrate(&_the_ps2_controller, 27);
or for c++
_the_ps2_controller.calibrate(27);

where '_the_ps2_controller' is your device name in PD.

My code changes since 'early Lynxmotion test by KurtEck' has added the ability to set rumble motor and to read the oush button info as an analogue value (ie how hard you've pressed the buttons). Am assuming Lynxmotion device supports this?


Let me know how it goes.

[KurtEck]

Tzankoff (the one who reported it...) - Let us know if you have a chance to try this out.  If not I will dig my test setup out again...

Yes the Lynxmotion controller supports Rumble and the analog of how hard you press the buttons.  But personally I don't use that information and have my initialization code leave me in mode 0x73 instead of going to mode 0x79 (0x70 says Analog mode).  The 0x03 or 0x09 is how many extra words of information for the PS2 to report back.  Since I don't use the extra 12 bytes of data, no use in wasting the time retrieving them...   But that is me.

Kurt

[KurtEck]

I don't think it made any difference... Still investigating. 

FYI - In the C++ code, I was getting a warning in ps2.h that the function calibrate does not return anything...

Ok, I believe the issue is on what edge of the clock the data is valid.  If I change my Logic Analyzer to say that the data is valid on the clock trailing edge, then it shows up like you are trying to send the valid bytes: 0x1 0x42...  And the PS2 is not responding to it.

With my Code, the Logic Analyzer shows the right data, when I say that the data is valid on the Leading edge and the PS2 is happy.  Actually It is happy if I say it is either on trailing or leading edge...  So I wonder if some devices are different that way...  Or maybe the timings are different enough...

Will look some more.

Kurt

[Webbot]

@KurtEck
In WebbotLib are you using hardware SPI or software SPI to connect the stick? If its hardware then I don't really have much control over the signal vs clock stuff.

As for the c++ calibrate message then if you edit Controller/Sony/ps2.h at line approx 191 you will see:

Code: [Select]


boolean calibrate(uint8_t deadzone) const{
      sonyPS2_calibrate(m_cstr,deadzone);
}

Change it to:-

Code: [Select]


boolean calibrate(uint8_t deadzone) const{
      return sonyPS2_calibrate(m_cstr,deadzone);
}

You don't need to re-compile WebbotLib.

Thanks for your assistance - I'm rather slowed down as my 'test' board has a defunct SPI header. So am struggling ie hardware vs software problems. Will try another board.

[KurtEck]

I am using the software spi.  Will try some other stuff tomorrow or the next day...

Yep that took care of the compiler warning.

Kurt

[tzankoff]

What the hell? Updates to this thread and I was not notified?!? AHHHH!
 

Anyway, I do initialize the controller...

Code: [Select]

TICK_COUNT appInitSoftware(TICK_COUNT loopStart){
marquee.print_P(PSTR("Fergybot4000 by Tony Tzankoff\n"));
controller.calibrate(20);
return 0;
...and in my main program contains the following:

Code: [Select]

TICK_COUNT appControl(LOOP_COUNT loopCount, TICK_COUNT loopStart){
if (!controller.isAnalogMode())  // added this because sometimes the connection would break
{
controller.setAnalogMode();
}

// code will be inserted here to drive a pair of wheelchair motors hooked up to a Sabertooth 2x25

// moves servos
stickVal=controller.joystick(PS2_STICK_LEFT_Y);
servoVal[2]=servoMoveServo(2,stickVal,1);
stickVal=controller.joystick(PS2_STICK_RIGHT_X);
servoVal[1]=servoMoveServo(1,stickVal,1);

// code for buttons
if (controller.buttonsChanged())
{
stickVal=controller.buttonsRaw();

switch(stickVal)
{
case 1024: // L1
functionSomething();
break;
// additional cases follow
}

}
In case you are wondering, I do have a pull-up resistor in the DAT line. Like before, the wired controller works just fine whereas the wireless controller does not (both before and after the resistor was added).
 

[Webbot]

Like before, the wired controller works just fine whereas the wireless controller does not (both before and after the resistor was added).

Just to clarify the above: the PS2 code works - but not for a wireless (LynxMotion) controller?

@Kurt - is the wireless a bit more fussy about timings?


@tzankoff
Looking at your code you are testing for fixed values. ie your 'case 1024' could be replaced by a more meaningful 'case PS2_BTN_L1' as all the button values are defined for you in ps2.h

Code: [Select]

// Define constants for buttons. These can be ORed together
#define PS2_BTN_SELECT 0x0001u
#define PS2_BTN_L3      0x0002u
#define PS2_BTN_R3      0x0004u
#define PS2_BTN_START  0x0008u
#define PS2_DPAD_UP    0x0010u
#define PS2_DPAD_RIGHT 0x0020u
#define PS2_DPAD_DOWN  0x0040u
#define PS2_DPAD_LEFT  0x0080u
#define PS2_BTN_L2      0x0100u
#define PS2_BTN_R2      0x0200u
#define PS2_BTN_L1      0x0400u
#define PS2_BTN_R1      0x0800u
#define PS2_BTN_TRIANGLE 0x1000u
#define PS2_BTN_CIRCLE  0x2000u
#define PS2_BTN_X      0x4000u
#define PS2_BTN_SQUARE  0x8000u


[tzankoff]

Just to clarify the above: the PS2 code works - but not for a wireless (LynxMotion) controller?

Something like that. Here is the thing. A while back, I ordered *two* sets of wireless controllers from Lynxmotion (in case one went bad or something). One set had a controller that did not work. The other had a receiver that did not work. When asked what to do, Lynxmotion told me to send the non-working pieces back to them and they would send me a replacement controller set. The replacement set has arrived, but I have not opened it yet. The controller and receiver pieces that I still have seem to work when power is applied, but they do not want to talk to each other.

@tzankoff Looking at your code you are testing for fixed values. ie your 'case 1024' could be replaced by a more meaningful 'case PS2_BTN_L1' as all the button values are defined for you in ps2.h

I know. I saw all that. I guess I am just more of a numbers person. Besides, I could not get those values to appear on screen when writing the initial code. Everything kept returning 0, which said to me I was doing something wrong. However, since I got the numbers to appear, I just went ahead and used them.

Like KurtEck said: "...but that is me."

[KurtEck]

Did not have a chance to work on this today...  But yes wireless controllers are fussy.  The Lynxmotion, madcatz and a few others are pretty compatible with each other.  Some are a royal pain.  Never had much luck with Logitech. 

Sometimes the are somewhat sensitive about timings, like needing a certain delay after the select line changes.  Or maybe the data line needs to be in a specific state before the select...

Note some controllers work better with 3.3v, so you might try that.  Also to get a receiver to connect to a transmitter, you might try only applying power and ground to it, turn on power, then turn on power to remote and see if the two lights on receiver comes on solid.  Pressing analog button, should force analog light to come on for awhile...

Kurt

[tzankoff]

Everything kept returning 0, which said to me I was doing something wrong.

...and I just now figured out why. I am an idiot.

[tzankoff]

Note some controllers work better with 3.3v, so you might try that.

I'll give that and a couple of other ideas a trry and see what happens.

Also to get a receiver to connect to a transmitter, you might try only applying power and ground to it, turn on power, then turn on power to remote and see if the two lights on receiver comes on solid.  Pressing analog button, should force analog light to come on for awhile.

I tried that once before, but there was no real success to show for it.

[tzankoff]

Note some controllers work better with 3.3v, so you might try that.

I just tried plugging in to 3.3v. Both LEDs on the receiver remain solid and the analog light goes on when I push it. But a second or two later, it switches off.

Afterwards...
1. Another push of the analog button has both LEDs on the controller flashing twice before going dark.
2. Another push after that has the red LED solid for about two seconds before going dark.

Subsequent button pushes repeat this pattern...and once again, the wired controller does not seem to have any problems.

[KurtEck]

Sounds like maybe this receiver likes 3.3v...

It is normal for the analog light to turn off after a second or two.  Probably to save battery power.  But it does sound like it is now connecting.  Now can you try my PS2 test program (not based on webbotlib) and see if it is happy...  It is in the zip file on the tread on Lynxmotion (http://www.lynxmotion.net/viewtopic.php?f=22&t=8079). 

I need to take a look through webbotlibs code again to see if I can figure out how to muck with the start-up of the output.  Things like maybe some devices don't read the proper edge or for example in the traces I saw from webbotlib, the data line changed after the select, then the clock changed, then the data changed and then the clock changed.  You can see this is the logic analyzer screen shots that I posted up on Lynxmotion...  I remember I had to work on that with some other versions to make it work properly...

I need to figure out how the modes are set/used in the software SPI code and maybe have to modify one to make it work.

Kurt

[tzankoff]

Just to clear up one little issue, what should be the value of the pull-up resistor on the DAT line?

[tzankoff]

KurtEck, one more thing.

I really do appreciate the help you are providing. You are the only person that I am aware of who has successfully hooked up a wireless controller to the Axon. Then again, once I saw your tutorial and saw it work, I stopped looking any further.

You seem to be going through an awful lot of trouble over this thing and it makes me wonder if I should just stick to a wired controller with an extension cord or something. Then again, you seem to have come too far for me to just say "forget it".

Needless to say, I am something of an idiot when it comes to these robot things. While I have learned a lot in the time that I have spent building and subsequently upgrading my robot, I don't quite have the know how that you do.

There are things I don't understand, there are things I will never understand, and I don't have fancy machines that do stuff. All I have is a little bit of money, some scrap plywood, simple power tools, a few servos, some wire, an inspiration, an idea...and that's about it which pretty much explains my creation thus far...



...and makes me wonder who the real bonehead is.
 

Slight kidding aside, I thank you for all that you are doing and hope something can become of this.

[KurtEck]

about a 1K should work.  However I have had reasonable luck with only using the built-in PU of the Atmega... At least over 50% of the time...

Kurt

[tzankoff]

A 1k resistor is what I have in place at the moment. Both with and without a resistor, the wired controller works and the wireless controller does not.
 

[Webbot]

@KurtEck - I also appreciate the hoops you are going through. The WebbotLib code seems to work for me with a wired PS/2 controller. I don't have a wireless one and so am unable to contribute to the conversation. I also don't have access to the same lovely toys you have! Your logic analyzer screen dumps put my old analogue o'scope to shame!

If required I can add a new device to Project Designer for a 'wireless PS/2 controller' once the issue is sorted.

Thanks for the help - think you may need a 'source code credit' here. In the meantime then definitely a +1.

[tzankoff]

Well, I just got off the phone with Jim at Lynxmoition. He insists that the receiver should work at 5V. I'll take his word for it. He knows better than I do. However, he does not have experience with the Atmega640 or the webbotlib library that is being used in my application.

He said there should be a 1k resistor on the DAT line, which I have. He suggested that I try applying power only to the receiver to see if there is a connection, which I have done before (with no success) but will try again.

I did inform him that I tried a wired controller as well as a wireless one, both with and without a resistor, and with both 3.3V and 5V. In all cases, the wired controller worked whereas the wireless one did not.

I will be sending back two of the three controllers sets that I have. One of them is the bad set I originally received and the other is the replacement set which does work, but also falls victim to this communication conundrum. Since the remaining controller and receiver set show signs of life when power is applied, it is implied they might talk to each other once this mystery is solved. If that is the case, I will not need the second good controller.

Thankfully, I have other upgrades to my robot that I am in the middle of completing and can put this issue aside for a little while.

[KurtEck]

Yes I have several of these receivers hooked up to several different robots, and they are all hooked up at 5V.


As I mentioned in previous posts, Some of the issues is with the software.  My Lynxmotion PS2 wired up to the Axon2 works when I use my own software, but not yet with Webbotlib.

I am hacking on it right now.  I am trying to get the output of webbot lib to be be closer to what I am generating with my own software.  I am measuring it with my Logic Analyzer.  Webbot - Yes this analyzer by www.saleae.com has saved my rear end many times.  It is one of the best $150 I spent... So far I have hacked the fill character to be 0xff instead of 0x00 to keep from having the signal drop low at the start of the packet.  No luck so far.  Trying to slow the bus down (my code is running about half the speed).  Will let you know when I figure something out.

Kurt

[KurtEck]

  I have had some success.  I changed from Bus mode 3 to Bus Mode 2...
I am now getting data

Not sure if attachments work, but try to show a working trace.

The thing I changed was the macro:

Code: [Select]

#define MAKE_SONY_PS2(select) { \
MAKE_SPI_DEVICE(SPI_MODE_2,SPI_DATA_ORDER_LSB,select,0xff), \
255,255, \
{255,255,128,128,128,128}, \
{128,128,128,128}, \
27, \
FALSE, 0, FALSE,\
0}The changes were the mode and the fill character.

Have not tried yet with wired.  Not sure if I still have one of those around.

Kurt

P.S. - The trace also shows you how much time you are wasting if you tell the PS2 that you want the key press pressures, and never use them.   That makes up the last 12 bytes of data in the trace

[KurtEck]

Quick update.  The wired Sony PS2, does not like these changes.  Should probably investigate more to figure out a common setting that works for both, but may simply add a different init setting for the two different types...

Kurt

[Webbot]

Kurt,
A quick response - to say thanks for your digging and effort.
Not too worried about the time fetching the extra 12 bytes - but more worried about works/not.
The 'fill byte' was partly my ignorance at the time....couldn't work out why some devices sent 00 and others FF but its really down to the SPI mode that's in use.
Happy to create a 'Wireless' and a 'Wired' controller type to Project Designer and the code - as you say - it's no more code just init stuff.

Interesting to see what SPI mode etc you use in your code. If you need to slow the bus down then give me a shout. If memory serves  - it seems to run at full speed for a software SPI bus as my assumption was that this would always be slower than a hardware one. Are you able to compile WebbotLib libraries? Hopefully you can just run 'make'. In which case we can jointly change the software SPI bus code to add a delay.

[tzankoff]

Ahhh...the sweet smell of progress!
*pause*
Yeah, I am just kidding a little bit.
Forgive me!

I was busy finishing up the wheelchair motor assembly on my robot and getting everything working properly. The only thing missing that I was hoping for is the ability to use a wireless controller. Not really required at this point, but it would still be nice to have.

I'm sorry if I bumped a dead thread, but I came across this link while cleaning out my bookmarks and thought "I have not been here in a while". Has it really been four months plus? Good grief!

[Webbot]

Not sure what you are waiting on....
Kurt gives  a workaround/code change for the wireless and says that wired and wireless work differently. I only have a wired so have no way to test his code change for wireless.
If your waiting on a new Project Designer release then I would suggest that you just try his fix (for wireless) in the meantime.

[tzankoff]

I really was not waiting on anything. Just checking to see what, if anything, was new. I'm sorry if I created any confusion. I'll try his fix or stick with a wired controller. I'm sure things will be fine either way.