Hi all,
There are multiple threads around the forum containing questions, examples and modifications for my code on this moment. I think that it is a good idea to start a new thread for my Phoenix code here.
I would like this to be the central point to discuss my code.
The current version of the code can be found on my BlackWido Project page or on the Phoenix build Tutorial.
So please feel free to participate.
Xan
Xan and Kurte,
Thanks very much for the reply and your support, I’ll be checking for the proper version on my compiler, probably just missed a detail while getting all the elements together. This hex has been nearly two years in the making. I have spent very little time on forums, mostly reading, so I’ll have to read up on proper forum/thread edicate. Sorry about hi-jacking your thread. 
Brian
Hi Brian,
I hope that he current IDE version will solve the issue. If not, let me know!
2 Years? Wow, or you really are a busy man or it is going the coolest hex that mankind has ever seen 
Like I said in my blackwido thread: Don’t worry about it 
Xan
Xan,
Yes on both counts I’m busy, with job, fixing family cars and motorcycles, housework, building CNC, other machine shop projects . . . . . you get the idea. 
Making the coolest robot ever? (I’ll try to keep this short) I think it comes down to one’s own reason for building one of these to begin with. Ive been tinkering with mechanical stuff for 30 years, and completed an electronics degree two years ago. It opened my eyes to the possibilities of what could be built that was previously not feasible for the “average dude”. My aim is to build the best quality, best engineered insect-inspired robot platforms that I can, and make them able to navigate uneven terrain, make them autonomous & remotely controlled, and eventually get my Masters Degree in Robotics. Yep, I’m a geek! 
I’m grateful that there are others with similar interests and skills who are willing share their knowledge. It makes the journey of building a better bot faster and more rewarding. I’ll get a thread started for this bot soon. Be safe.
Brian
Xan wrote
I have updated the IDE and it compiles fine. Mine was just old. I have taken some time to get a little more familiar with the functions of the IDE, and I have read over a printed version of your program (Ripple in this case) to get an idea of what’s happening. Most of it I can follow and understand in a general way, with my limited programming skills. 
So far I have uploaded all versions into the BAP to confirm them and see what works. I think I am not getting communication with the Lynxmotion PS2 controller. The robot “snaps to” when the program is started, and it beeps indicating no communication with the PS2. I have also tried it with a cabled PS2 controller. I have been over all the cables/connections carefully, confirming them with your tutorial. The SSC-32 is jumpered to 38.4Kbaud. All other functions of the bot work when controlled by LM Visual Sequencer. I have not tested the LM / PS2adapter for electrical continuity, will check that next. Mine is two years old and has the black wire, not the white.
Are there other things that could be an issue for communications between BAP board and SSC-32 board?
I was noticing commented code in your programs that resembled output code for a serial LCD. Is that what it is for?
; serout s_out, i9600, [sdec TravelLengthX, " ", sdec TravelLengthZ , " ", sdec TravelRotationY , 13]
Looking forward to better understanding your code and getting this bug to crawl.
Brian
Hi Brian,
Have you tried the reset button, sometimes I’ve to press the reset button one or two times.
Hi Brian,
You can say that you’re a busy man for sure! I know the idea of being to busy to spend time on robotics. I’ve got it once and a while…
I think that our admin helped you with that already
There still is a bug in that part, I’ve posted this question several times but nobody seems to know what is going on. I’m also working around that by pressing the reset button several times. I hope that someone will come up with a solution one day
Some leftover debug code I also use a LCD for some quick debugging sometimes. But the s_out writes to the 9 pin sub-D connector.
Xan
Three things.
We need to know if you are using the MiniABB, or the Bot Board II. They have different pin assignments for the PS2 controller. Which board and which pins are you using? If this isn’t it, then test the controller on a PS2 game console.
The s_out sends data from the Atom chip to the PC through the serial port. You need to open a terminal at the bottom of the IDE, select the proper baud rate, and click connect. Then you will see what the atom is sending to the port. It is a good way to debug, but with all commands like this it can adversely effect the timing specific commands within the program. Think about what it’s doing when you implement it for troubleshooting.
I will ask Laurent to look at the PS2 code for this when he has time.
YEAH
Thanks, I think that you and Laurent can make a few people happy by solving this problem!
Xan
My guess is that it is a timing issue, with the commands that turn the PS2 controller into analog mode. I have had the same problem on my Hex. Many times I can get it to work by hitting the mode (or on some contrllers) Analog button and make it work. Other times I found that the lock in mode function worked but it was not in analog and I then had to reset the processor.
A little while ago I hacked up the sample PS2 code for the Propeller chip to download the initialization strings and found if the timing was off I would run into this same problem. My guess is that initialization code be simplified some. I am not sure most of our programs need the native mode turned on, such that we can receive the button pressure values. From memory, I don’t think any of our sample applications use this information). Just a thought.
Kurt
Hi there,
try to delete the “nap 4” in the PS2 code, nap is not working fine on BA pro, replace with a “pause 100” it should work
Hi Xan,
I remember that you posted a video of your blackwido walking very fast, when you removed the Query command for waiting for the SSC32 to be ready… Or something like that
One bottleneck is the communication speed between AtomPro and SSC32. To transfer all data for a hexapod takes about 47 - 49 mS. You can avoid this by not using the “Q” command for waiting for the SSC32 to be ready, but instead start sending the data to the SSC32 47 - 49 mS before its ready. I’ve done this and it works great. And Phoenix walked even smoother. 
I wish the SSC32 “Q” command returned a value for how much time that was left instead of a “+”.
I measured the SSCWait sub and it looped for about 110 mS (GaitSpeed = 200 mS) ! 
I was thinking that’s very much wasted time! This mean that the calculation takes about 80 - 90 mS included the time it took for reading the RC inputs.
What I did was to add a pause command
pause (GaitSpeed - 135)instead of the SSCWait sub. You have to experiment a bit with the subtraction value (135).
If Jim or Mike are reading this: Is it possible to make a movement query command that return the actual time thats left for the current move?
James verified this fixes the problem. We will update the website with the new PS2 code soon. I added the NAP command to the 8.0.1.7 bug list. With the Atom the NAP 4 command resulted in a 288mS delay. A NAP 4 on the Pro is an 8mS delay. When we tried NAP 144 for the 288mS delay it still didn’t fix the PS2 problem, so it looks as if NAP is broken in 8.0.1.7.
I’m asking Mike to look at the request. He’s actually working on the SSC-32 firmware right now anyway. He’s looking at the ONCE command.
Were you or Xan going to attempt to keep us poor PS2 users with new improved code?
Thanks Jim! That would be awesome.
BTW: If he updates the 2.01XE does he also updates the 2.01GP with the same functions? (I’m using GP… )
Of course. The code are the same for PS2 or RC, its just the PS2Input or RCInput subs that are different. All kinematic calcualtions are the same.
Yeah! That did the job! A IDE bug… Great. sry I didn’t think of that… Thanks!!
Yep I’ve encountered the same problem! When my code was about half way I had the problem that I had to wait for the SSC to be ready. If the data is send to early the servos will not reach the final position and if I send this to late the movements won’t be very smooth. As you’ve noticed timing is a big issue here. But since the code is still changing you also need to measure and change the value by hand. That’s why I added the “Qâ€
The bi-directional communication between the Atom Pro and the SSC-32 is still useful even if you decide to just wait a specific amount of time to refresh the leg positions. It can be used to access the 4 analog inputs on the SSC-32.
Here’s what could be a pretty simple way to really give the Phoenix some personality. If the bot is stopped for a few seconds, it could become bored. Maybe lift and lower a couple legs, maybe at random. Even adjust the body level or orientation above the legs. Just an idea…
Hrm, maybe I will postpone my video session till we have the smoother code. 8) Thanks!
Hehe… Believe it or not but I’m already working on this Before my lipo arrived (yep, phoenix is walking but I’ll post that later) I’ve worked on a “Aliveâ€
Hehe… Believe it or not but I’m already working on this Before my lipo arrived (yep, phoenix is walking but I’ll post that later) I’ve worked on a “Aliveâ€