To confirm (just to be certain), it’s the green LED next to the number 5 at the top of this page?
http://www.lynxmotion.com/images/html/build185.htm
The green one is connected to pin8 as well as button B. Is there a chance something physically (accidentally) pushes the button (like a hanging wire, battery etc.)?
Yes, that’s the one, and no…nothing is touching it or near it. It will be working normally when without warning uncommanded spastic movements begin. Often, the led on the PS2 receiver will begin to blink (loss of signal, I think) and then he pulls in all legs and collapses. I can turn everything off and then on again but the same symptoms are present. The only thing common to all the symptoms is that green led, which goes out and stays out during the symptoms. The adjacent red and yellow leds continue to quick flash throughout. The symptoms dissappear as mysteriously as they appear. No smoke, no smell, all battery voltages OK.
I can’t seem to find what causes those three leds to flash. I see where they are declared as booleans, and I see them set to zero (off). I have searched all of the code looking for what turns them on, and I could not find it. The schematic shows them connected to a port pin. Perhaps the port is reconfigured somewhere which causes the lights to turn on briefly.
Any ideas?
Yes. The jumpers are in place on JP, JA, JB and JC.
My initial thought was that this is a controller problem so I ordered another PS2 controller. I will let you know whether that solves the problem. I suppose that I could replace the Botboardino and the SSC32 as well, but my instinct tells me that there is nothing wrong with the boards. I have also added a voice system to the bot of my own design, so I thought it was possible that there was an EMI issue because the voice system has an XBEE radio in it. But I removed the voice system completely and I still see the problem… So, right now its just the bare bot with the two boards.
I would recommend to remove those three jumpers completely.
OK!. It might be the cause.
Not a bad line of thought. The PS2 wireless communication most likely uses a 2.4 GHz proprietary protocol. Other 2.4 GHz might interfere with it. Maybe try in a different room and see if the results change?
Sincerely,
I am cautiously optimistic that replacing the PS2 controller has been successful. I am not seeing any of the symptoms anymore. Have you seen that before?
I hope it stays that way.
No this specific case but as a general thing that happens when one part of an integration/robot stops working withing specs, yes.
It is quite possible the receive you previously used had damaged electronics inside which caused it to misbehave and maybe cause shorts, brownouts, noise on ground/VCC, etc. Considering that replacing it seems to have fixed your issue and that it is a low cost item I think that is satisfying enough of an ending.
If you want to know more, you’d most likely have to open up the receiver and connect probes (oscilloscope, logic analyzer, etc.) to gather data / analyze its responses while it is in use in your circuit.
Good luck with the project! 
If I get some time I may do that. The protocol is the same a SPI, I understand. I think it sends a leading byte and then follows that with a data word that has the state of the controls encoded bitwise. If that data becomes corrupted for some reason, it could cause the problem I was seeing. Are you guys familiar with it, or any reliable references as to how the data is structured? I recall seeing something from Lynxmotion about the protocol.
If you do let me know as I’d be curious about the results!
It basically works as a read-only SPI slave.
A good starting point would be the library itself (and its creator’s website about it). You can find our version of the library here.
You can find details on the protocol and physical interface here.
The Curious Inventor link seems to have the bulk of it, thanks for that. It looks like all I have to do is snoop on the clock, data and command lines while the controller is in operation. I have looked at that before with a scope, but only to confirm that it was working.
Yes, indeed.
A logic analyzer would be best here (or an oscilloscope with logic analyzer-like functionality).
Alternatively, since the rate of communication is pretty slow for that interface you could possibly use another microcontroller board to sample the signals and serve as a logic analyzer.
In theory to reproduce a signal you need at least a sampling frequency that is at least twice as fast (or more) than the signal being analyzed. Example: If the communication is at 100 kHz, you’d need to sample @ 200 kHz or more (preferably more, like 8-16 times the rate for good data reconstruction).
Since logic analyzers are typically expensive, many people have created alternatives using Arduino-compatible hardware. Here are some interesting ideas if you are curious to do so:
DIY Logic Analyzer - Arduino Project
Arduino Playground - Logic Analyzer
Arduinolyzer.js
Logic Analyzer Tutorial and Introduction
I am taking a close look at the Botboardino_CH3_PS2X sketch and the included files to better understand the details of how it works. There is an optional module included called OPT_GPPLAYER (#define OPT_GPPLAYER) that is referred to over and again in the code. Can anyone tell me what that is? Is it some kind of game interface? I can’t find any references to it on the net. I found an old thread here that refers to GP, but nothing that tells me what it is.
I’m assuming this refers to the GP Sequencer or General Purpose Sequencer is detailed here (older SSC-32 manual).
It allows you to use special extra EEPROM storage on the SSC-32/SSC-32U to play custom sequences.
In this way it allows the controller board (in Lynxmotion kits that would be the BotBoarduino) to tell the SSC-32/SSC-32U to play a sequence with just one short command (more efficient).
You can check an older topic here about this here, here.
According to the author of the Arduino version of this code, the GP Player code may work in this version of the Phoenix code (see here).
Ah, I see. It looks like no one ever used it. I am rearranging/ rewriting the code with the goal of allowing the hexapod to act in a more autonomous fashion, and I am removing the portions that are not used or unnecessary. So, the GPPlayer goes.
I intend to have the code run on a 1284P (Mighty Core) because it has much more memory. Then, I intend to layer on an autonomous mode that I can toggle into and out of with a button on the controller.
But this code is in C++ and full of (in my opinion unnecessary) C++ do-dahs that make it difficult to follow for someone not proficient in it. I’ll bet that I will be proficient by the time I finish it, LOL. In order to understand it better, I have been documenting the function and operation of each of the modules. I will post that when I am done for others who may wish to dig into it.
To follow on a previous post, I reinstalled the audio system on the bot and it all works fine together, so I presume the problem I was having was in the PS2 controller/receiver. I did have a look at that data stream, btw. I used my scope, which has logic analyzer built in (Tek 3014). It is, as you said, straightforward SPI except that the CS is active high rather than low. It looks like the Botboardino just polls the PS2 controller continuously, extracts the button and stick states, and uses that to update its variables.
Be careful, the comment from the author was regarding a different software (newer adaptation of it).
The GP sequencer may actually be used in the Pheonix code you are using.
Sounds great! Looking forward to what you found out about it!
Happy to hear!
Neat scope. Yeah, it is basically a simplified SPI-based protocol. Actually, this is far more common than most people expect. And the rest is mostly all I2C/I2S/SMBUS with some UART/USART sprinkled around for good measure… 
I have completed a review of the Lynxmotion hexapod software compilation, and I now have a pretty good idea of how it works. I have documented this review and am posting it as a .pdf. Anyone interested in the software might benefit from the many hours I have spent digging and following trails through the compilation.
Phoenix Driver.pdf (518.8 KB)
I have also come up with a way to layer on to the compilation in order to add an autonomous mode to the robot that the user can toggle into and out of with a button on the PS2 controller. I intend to write a C++ routine to do that and I will make it available on Github when its done and tested.
Comments on the document are welcome.
2 Likes
That is great! Thanks for sharing your work. I’ll review this in detail later.
Would you mind if we shared your code on the Lynxmotion GitHub for other Lynxmotion users? I think that would certainly be helpful to others. Of course, I’d only do so once it is ready! 
You might want to do an @ Kurte @ Xan and @ Zenta - they have all been heavily involved in the Phoenix code and have continued to work on it since. They may be able to offer additional insight and might have even covered some autonomous code already. Looking forward to what you create.
I said that I would post information regarding the modifications I have made to my Phoenix hexapod. I added an audio system in furtherance of my plan to make several theater robots (entertainment bots). I have a short you tube video describing it here … https://youtu.be/H7_1gzZ1FoM
2 Likes