This should come as no surprise to many of you. As you can probably tell, I enjoy doing stuff with my Lynxmotion hex robots. I also enjoy working/trying out different microcontrollers, including: Bap28, Bap40, Arc32, Nano, Axon2(AVR Atmega1280) and more recently Arduino Megs. Well a few weeks ago I was cleaning up my office and noticed a box in the corner that still had a couple of propeller based boards I purchased maybe a year or two ago and wondered how hard would it be to get the phoenix to run on a propeller. The current code base is using an SSC-32 to drive the servos.
The main board I am trying this out on my CHR-3 is: wulfden.org/TheShoppe/prop/prc.shtml as seen in the picture below
I have another board from Parallax (USB proto board) that I am using to try out some versions of the code on, with just one leg, as seen in the
I think I have the code now working reasonably well. I ported over the PS2 code as well as the DIY XBee. I have it configured such that I can change which of these are used by changing which control object I define in the top level spin object. I also have a control object that allows both to be used, whichever of the controllers first does a start gets to keep it until it does a relase…
As I mentioned, I think the code is now working reasonably well. Here is a video of it, showing it being controlled by a PS2. Ya I know I should setup a youtube account… s416.photobucket.com/albums/pp24 … edlegs.mp4
I have also included a zip file here with the current code. Note: yesterday I found out that wiring is a little mixed up on my robot and two legs are switched which is why I was pulling my hair out trying to figure out why it was not walking very well. So far I took the easy way out and simply updated the CFG object for which pins are which. Later I will dig into the robot and fix it to use the standard pins…
Note: The top level object is Phoenix.spin. I have also included several Object Exchange objects that I have modified or use.
Kurt
UPDATE: I updated the zip file with the standard SSC-32 IO pins, also fixed it on my robot…
You never stop to impress me with your programming skills, thats awesome. Thanks for sharing!
I’m wondering, have you measured how fast the code is for doing one cycle of calculation? After watching your video it seems fast enough. Did you experiment using the XBee too?
I think you’ve to decrease the max/min body rotation a little bit…
EDIT, Oh it looks like you got the XBee to work too… Excellent!
Well, one of the Parallax boards do have a nice little solderless breadboard! Maybe we need a little stack-able breadboard. The breadboard is tiny, but it is available separately.
Yes I think it would be great to have standard Lynxmotion board with the right hole patterns and the like. The Wulfden one works OK as by chance it does have the same hole pattern but is longer. It also requires you to either jumper out with either wires or resistors to make connections to the logic part of the servo pins… Great to experiment with. The interesting question would be to develop a board with a socket to plug the DIP into or use the smaller surface mount version. Also will be interesting when the propeller2 comes out.
Zenta: yep I probably should put some more limits in on the servos, but I like the sound of grinding gears
I took a few short cuts in converting the code. That is for example I converted all of the gait and servo code to longs as on the propeller if you declare a variable as a byte or a word it is unsigned. If you wish to use it as a signed variable you have to use a unary operator to say sign extend to 32 bits…
Also there are interesting issues with the propeller and using their objects. That is an object can only use the methods/variables that are contained within itself or the public methods/defines of child objects. So for example in this code there is a control object (XBee, PS2…), When I call the input method, it can not call anything within the parent object (like GateSelect). There are two ways to get the data back to the parent. The first is to provide methods for the parent object to call, like: control.BalanceMode which calls the BalanceMode member of the control object… This is the method I currently use. A second option would be for the parent to pass in a pointer to an array that the child object stuffs data into different array elements. May try this method if the current way proves not to be fast enough.
Zenta as for speed, I found that most of the time through the main loop up till waiting for the last servo move to complete was taking about 30-35ms and that was for the dual input controller that calls two deep for everything. That is the multi controller has code that looks like:
pub HexOn
'' Returns the current HexOn State
if WhichOne == PS2_ACTIVE
return CPS2.HexOn
return CXBEE.HexOn
So again if I converted the control code to fill in an array instead, it would save some time. However with the propeller chip, we save time in other ways. That is for example if you are using the PS2 controller to control the robot, it starts up a COG (propeller for thread), that continuously monitors the PS2 controller and fills in it’s own data. So when the main code wishes for the state it simply returns that data without having to wait for the SPI type data to happen. Likewise the XBee code uses another COG to do the equivalent of a hardware serial port. This is definitely a different animal…
You are really making a multi platform application from the phoenix code. Pretty cool to see the ports to all the different platforms. What’s next? RB-100?
Did I hear someone mention a carrier board for the Propeller?
These are some I designed for a Propeller board made by www.gadgetgangster.com . It was obviously inspired by the electronics carrier from Lynxmotion. The Propeller Platform boards allow stacking of other boards similar to what’s done with Arduino shields.
Yep, I am having some fun. RB-100 - Looks interesting, but don’t have one
But for now I Will do some more playing around with the propeller. But I may interrupt that interruption and go back to putting the Arc32 on the robot and finish testing the Arc32/SSC-32 combination, with ARC32 based offsets, etc. On the propeller side there are still lots of things to try out, like should I use their trig functions (which are lookup table based or continue with the ones in the phoenix code).
It is interesting to do the different versions as I learn different things, that I may want to back port into other versions. Like with this I had to redefine how each of the objects interact. Might be valid in the C++/Arduino versions to make use of this and define real interfaces…
I forgot to mention, if anyone is interested, I also think it would be reasonably easy to integrate in an RC receiver as another input method, such as: Hitec 6Ch RC Set, which I do have, or the spectrum, that Robot Dude mentioned yesterday in the thread: viewtopic.php?f=21&t=4399&p=67664#p67664, or the DIY stuff that was done earlier…
I believe that it would be easy to start up a new COG that simply monitors all N pins associated with the receiver (or a modified one like I did for the BAP) and updates an array with the current pulse widths. Then the main code simply has to use the values in this array without having any slowdown… May play with this on my USB prototype board…
Quick update. I have the first pass of an RC control object in place. It is currently setup to use my Hitec Laser6, where I use the Aux know to control which mode I am in, and I use the gear switch to toggle through the different Gaits or legs in single leg mode… The code detects when the receiver is turned on, by checking all 6 pwm values that they are in a valid range. When it starts to get a valid range it takes the first 8 samples to get in estimate for when the center point is for some of the joystick values…
The code in the zip file is currently configured for dual Xbee/PS2 controllers, but you can also easily choose any one of the three input methods, by simply changing the Control object in Phoenix.spin.
Next pass will be to clean up/ probably speed up some of the code.
Awsome work. I have done the same and ported it over to the Propeller platform.
I managed to get the Propeller to control the whole bot. It runs the IK and controls the servos of a little board I made up.
I posted a thread over at Parallax and there’s one over at TrossenRobotics in there current DIY contest. forums.parallax.com/showthread.p … ysprune=60
I’m at work at the moment but my code is at the link above.
I cant wait to get home and really take a look at your code.
Just glancing at it I couldn’t get the gait selection to work like in the original code.
So I came up with a different way of doing it so that it dosen’t have to go thru the if then loops.
I have also added a form of Interpolation.
A quick update. I updated the code to pass an array to each of the control objects that the current state is kept in, instead of having the main program always having to do a query to get each parameter. It does make some of the code a little fun to read, but I believe this speeds up and reduces code size. Also it made the ability to integrate multiple control objects in a lot cleaner. The current Multi control object does all 3. PropellerPhoenix.zip (62.1 KB)
I’m new to the Propp chip but I got a board some weeks ago,
when I found this thread I hooked it up to my Phoenix and was hoping to get the code working.
It has been a little while since I looked at this, but:
To only have a PS2 controller, go into Phoenix.spin and change the line:
control : "Phoenix_MULTI_Controller" ' Choose the controller file you wish to use.
to
control : "Phoenix_PS2_Controller" ' Choose the controller file you wish to use.
Look at my modified PS2_controller_new.spin file for connection information. That is:
[code] Connect DAT, CMD, SEL, CLK signals to four consecutive pins of the propeller
DAT should be the lowest pin. Use this pin when calling Start(first_pin)
DAT (Brown), CMD (Orange), SEL (Blue) and CLK (Black or White)
Use a 1K resistor from Propeller output to each controller pin.
Use a 10K pullup to 5V for DAT pin.
Connect Power 5V (Yellow) and Gnd (Red covered with black)[/code]
As for choosing different IO pins, you should be able to configure them to which pins you are using in the file Phoenix_Config.spin. As you I believe that most all IO pins are created equal to the propeller, but not sure about your board, on which things may be configured on which pin…
Do I need to rem the codeline where the other type of controllers pins are setup?
I can see that for example the RC Pins are using the same pins as my display.
Nope you simply need to define which of the objects you wish to use… On my machine I was testing using all three at different times, so I left them in commented out to make it easier to switch from one to another…
I’m getting the signal from the Sony controller, The serial seems to work, the LED on the SSC-32 bord is blinking a lot…
But nothing happens with any servo channel…
I have the serial as :
cSSC_RXPIN = 2
cSSC_TXPIN = 3
With a 1k resistor on the propp RX pin. (I was thinking that I need that to protect the Propp from the TTL from SCC board??? )
Do I need to use a level converter here??
Yep I believe I have 10K resistors on my Wulfden board that is between the IO pin and the propeller. If the LED is blinking on the SSC-32, it says it is seeing some data. Could be bad data… What are the baud rate jumpers set to on the SSC-32? I believe I have the code configured for 115200 which would require both baud rate jumpers to be set on the SSC-32…
Excellent!
- Looks interesting, but don’t have one 