Notes for Phoenix code?

Maybe it was mentioned before, but I’d really like to see the notes for the 2.0 Phoenix code on the botBoarduino (SQ3).

The monitor has a set of commands, which I have only partly worked out. The joystick commands have been documented in the program.

A lot of parameters! I think I discovered why my 'bot is being shut down on voltage. It’s not the 5v, it’s the servo battery. Right, because it is disconnected…

Are there any notes?

Alan KM6VV

Hi Alan,

Note: The SQ3 on Botborduino code base was an update of my earlier port of the code that Xan added in support to make the SQ3 work. In particular he added in a different way of doing balancing for the Quad. As far as I know there has not been any changes to this code base since the first posting.

After that time frame, I incorporated his changes back into my Arduino versions of the Phoenix code base. In particular into my Quad branch of the Phoenix in Parts project: github.com/KurtE/Arduino_Phoeni … ad-Support

You are right that there is not much (any) documentation on the Terminal Monitor. Note: I currently have the code set up that there are two sets of commands: The first are global ones: I don’t think there are very many and most can be configured out of the code base. Also some are probably not very useful right now and can be removed.

D - Toggles debug on and off. Allows me to have code in place that either outputs or does not. (The command simply toggles: g_fDebugOutput)

E - EEPROM dumping functions. There is some quick and dirty code here. If the next character is a h, it will dump in hex, if the next character is a w it will dump words. The next parameter is the start address. If not given starts where the previous one left off. Next optional one is the number of bytes to dump

Note: My quad version has two more commands B and “G…”, which I am not sure how useful they are. Especially the B. It allowed me to change how the balance worked. The G allowed me to enter all of the parameters that define a Gait so I could try out different ones without rebuilding.

Then the different Servo Drivers have an option to add commands to the list. Example on PhantomX with AX-12 servos, I have commands, to get the voltages, Set the frame length, Test to see if I can talk to all of the servos, reset an id on a servo. On an SSC-32 I think currently the only commands I have (optionally) include a servo offsets command (allows you to use the keypad to change the servo offsets and save away the changes to the SSC-32). Also I had a quick and dirty test that did SSC-32 forwarding, to allow me to play around and use programs on the PC like SEQ or terminal…

At some point I will try to update the Readme.md file on my project with more of this information.

Kurt

Hi Kurt,

I’m currently compiling LSQuadA_PS2_SSC32_Complete, although by now there might be something newer. Is this version too old?

I see D toggle debug on and off. I’d like to use the SSC-32 forwarding. When does the forwarding come on?

Turning both batteries on gets rid of the voltage warning.

PS2 connects. I get a note when I press start, and 2nd note if I press it again. L1 and L2 mak a sound also. About all.

Botboarduino test says SSC32 connected and PS2 not recognized, although I see all the buttons in the data coming back.

Turned on PS2_debug, but don’t get anything.

Didn’t see anything in your .md file I found in your github.

About time to recharge 6V servo battery.

Will do more later.

Alan KM6VV

Hi Alan,
I will be honest and say I have never tried the LSQuadA branch up on Lynxmotion as I don’t have that hardware setup. Maybe I should have added the body plates (lynxmotion.com/p-876-quadrup … kit-2.aspx) and likewise check out my parts bin to see if I have the parts needed to convert the CHR-3 types of legs over to the SQ3 legs, to the order I put in yesterday for a couple of shields to try out on the Teensy 3.1 board that I will hopefully assemble next week…)

Also would help to know which PS2 you are using? One of the New V3s? I will be getting one of these sometime next week, so hopefully I can debug some issues with them on the Botboarduino and the BB2.

But if you get a Beep when you press the Start button. (Actually I think it should be Three tones on each. First one with frequency going up (Turn On), and 2nd with frequency going down (Turn off), then it sounds like the PS2 is communicating. You are not getting anything happening with the servos?

Is the led on the SSC-32 flashing? Things I would obviously check include: Baud rate, Right IO pins and potentially check to see if the code is using the Binary mode to talk to the SSC-32? If so need to make sure the SSC-32 has a version of the firmware that supports it.

Terminal Monitor: Is only called when the robot is logically turned off (Start button has not been pressed)
SSC-32 forwarding - When turned on - real simple code that echoes everything that is received on the Serial port to the SSC-32 serial port and likewise everything from the SSC-32 back to the Serial port. It exits if it receives a text line of $ Note: The code for this is in a $ifdef, so need to define if you want this code. Also obviously if you define the SSC-32 to use pins 0,1 (Serial object), then this as well as the terminal monitor can not be defined for obvious reasons.

To debug PS2. There are a couple of #ifdefs to include the code:
#ifdef DBGSerial
#ifdef DEBUG_PS2_INPUT

Also it will only ouput if you turn debug on. (D command). Also looks like it will only output when the PS2 is properly into Analog mode. Can always add more debug code to see if it is not in Analog mode. There is code in place to try to automatically get you back into Analog…

As for Code bases? I mainly only support my versions. Tried a pull request a long time ago on the other Botboarduino Hexapod project up on Lynxmotion which never took and we are still seeing the compile error if you turn off SSC-32 binary mode… I know I should try again.

I had cut my own non- symmetrical body plates, with different leg angles. I bought a set of LS plates, rebuilt a set of legs, and put a QS3 together. I’ve since rebuilt the legs a few times, and I think I’ve finally got them mounted correctly (different symmetry then my original). Yeah, get the leg parts! I bought an additional BotBoarduino as well. Nice board!

The LSQadA build is what the LS website links to. I’m comparing files to your gethub set (not finished), seems like only some leg values are different.

I get beeps, as you describe. Sometimes I get PS2 init 0, sometimes 1. I had set the DEBUG_PS2_INPUT flag, but didn’t realize I needed to be in debug mode as well. Now I get the codes just fine. Analog mode is still a little bit uncertain. Nothing happening with the servos.

Reports SSC32-V2.04GP for a “ver” command, and the LED flashes. So OK there. Would be nice to report the ver # upon sign-on. That would verify configuration.

SSC-32 is using pins 10 & 11. I set the forwarding flag, and the SSC-32 responds to the ver command as noted above. “S” turns it on, after you set the compile flag (simple once you know).

A “robot on” and/or “robot off” prompt could be useful. “start to turn on robot” (debug message) would also be useful. But after you get the controls down pat probably wouldn’t be needed.

Haven’t worked out the “B” and “O” yet, a little more reading of the code should help.

Works now. I also replaced the PS2 batteries, they were going down…

I understand that. I’m just trying to sort through all of it. I suspect others might be as well.

Installing the build directories doesn’t make it any easier. On my laptop computer I’ve twice managed to get a recursive directory, that in nearly impossible to remove because the path gets too long.

The more I get into the code, of course, the more I understand. Quite a bit different from the early PowerPod code I converted for a 4620 PIC on my custom hexapod.

Thanks!

Alan KM6VV

Edit: found the clear text for the .md file, I can read it now.

I think one main issue is the version of the SSC-32 firmware(SSC32-V2.04GP) you have on your SSC-32 does not support binary mode. Back when the latest version of the Phoenix code was coming out (2.1 of the Bap28 and later the Botboarduino), the idea was that all new SSC-32’s would be shipped with the EGP version like 2.07egp (lynxmotion.com/images/files/ … GP_A1A.abl).

Two options: One update your ssc-32 to this, or turn off binary mode>. Go into the Hex_Cfh.h file and look for the line:

#define	cSSC_BINARYMODE	1			// Define if your SSC-32 card supports binary mode.

and comment it out and rebuild. Should probably do this by default in the code base. The idea of the binary mode was to increase the speed for downloading the new positions as well as for quicker feedback. But in the case of the Phoenix code base I am not sure if it helps or hurts. That is yes the download of a new position does take less total bytes to be downloaded to the SSC-32, so in theory faster. However with normal walking code, we download the command up to the commit and then wait for the proper time to output the commit. And in text mode the commit is simiply the CR, but in binary mode it is a special byte followed by the two byte move time. So which way works better? Don’t know…

Kurt

Turned off binary mode, and I’ve got leg action! Guess one or both of my SSC-32 boards are not at the latest level. I’ve got a new chip around here somewhere…

Trouble is, it’s with all the legs up! They do seem to look like they want to walk. Servos are HS475HB.

Somewhere I’ve got a jpg of the setup for the 3DOFA leg.

Edit: Phoenix leg adjust? is there a single leg move?

Tried the sequencer, but could not get it to work through the pass-through.

Still really funny why the legs are all pointed up (instead of down) and appear to dance. almost sounds like a Fibia reversal?

Alan KM6VV

See edit above. These legs have been updated.

Not my pix, but I just verified my 'bot against it (again).

WHO HAS BUILT THIS SQ3 QUAD?

Alan KM6VV

Things I remember from when Xan was doing this. Normally when we build a hexapod we build 3 left legs and 3 right legs or with quad 2 of each. But for whatever reason he found that having two left legs and two right legs did not work as well, so he changed where the opposite legs go. Look at your robot and verify the servo horns are on the correct side for each of the servo. You can verify by the picture you showed here and figure 7C of the assembly manual: lynxmotion.com/images/html/sq3u-assembly.htm

So the code was special cased for this one to know which servos needed to be reversed…

Yes, I remember the new leg configuration, I had to change my 'bot to match. Probably makes for more symmetrical leg calculations.

Do you know where the changes are for the new configuration?

hex_cfg.h // Warning I reversed my legs as I put left legs where right should be... ??

I saw 2 invert flags between the hex_cfg.h I have and yours, but they weren’t the 4 tibia servos that might be expected.

I’ve verified my 'bot against the pic. Looks the same!

It seems like you have all the servo horns pointed in the same direction; the walking gait has the legs mirrored about both axes.

Yep - Maybe I misread his post with the pictures, but I read it as the first picture was a picture of his Quad before he updated the legs and he updated the legs to match the lower picture.

If my interpretation of the message is wrong, then yes, the legs are wrong. Note in the lower picture all of the servo horns are pointing to the front and to the rear, where in the first picture you have the left/right mirroring.

Edit: Forgot to mention. Also sometimes I find, that I screw up and plug the servos into the wrong SSC-32 pin. That is one of the good things about the servo offset mode that is part of the Terminal monitor. When you enter the O command (If the appropriate option is configured to include it), it enters the mode that allows you to use the keyboard to play with the servos. As you select different servos, the code wiggles the servo to let you know which one it is, plus it prints out a logical name for the pin like LF Coxa. If this is not the servo you think it is (or nothing moves) then you know there is an issue. Using the + and - keys moves the servos a little. (Note with Arduino Monitor more of a pain, as nothing is sent until CR, but you can enter multiple +s or -s. You can use the * key to change to the next servo. Also I allow you to enter 0-5 to select a leg (in your case 0-3), plus C for Coxa, F for Femur, T for Tibia and not in your case A for Tars.
To exit this mode enter $. It will then prompt if you wish to save your changes, which if so the offsets on the SSC-32 will be updated.

Yes, my brushed aluminum 'bot pix was BEFORE I “fixed” the legs.

Thanks for the ‘O’ command definitions. I hadn’t gotten anything from the command before.
Upon issuing the ‘O’ command, all legs went straight out from the body. Aren’t they supposed to be at right angles at the Tibia? So that’s possibly the problem. I hadn’t realized it when I assembled the servos on the legs. We’ll see!

Sorry about the small pix, I’ll have to re-shoot it.

I haven’t tried to enter the fine servo adjustments (offsets) yet.

I tired going into pass-through and then running the Sequencer, but no success. Maybe the connection gets lost when I change over to Sequencer.

Thanks!

Alan KM6VV

Yes, looks like your tibias are off by 90 degrees as I am sending out a P1500 for each of the servos. (Which is another reasons I did the O command)

It has been awhile since I tried with sequencer, but I did play around earlier with things like lynxterm and the like. Also don’t remember if I had issues, like when the terminal makes connection it reboots the processor? If so I might have to do things to fool it, like with Lynxterm, I could enter the forwarding command. Will try to play with this again.

Kurt

Rotated the Tibia joints down 90 degrees to make a right angle.

Aligned the legs with the “O” command. Nice feature!

Pressed triangle.
Legs look like they move in a coordinated fashion.

First Impressions:
Very poor walking, if any.
Right joystick rotates fairly well, not much forward/reverse motion.
Left joystick appears to try to move forward/reverse, but 'bot is quite low. Doesn’t make much progress.
6V 2800 mA battery, charge OK.

I need to go over the PS2 controls.

I discovered yesterday that the plan calls for HS-645HB servos, not the HS-475HB servos that I had built the previous legs with. Might explain the poor behavior.

Is there a video of the SQ3 walking?

I have a set of four T-Hex 4DOF legs (L-R pairs). Not tars, I think.

lynxmotion.com/p-802-4dof-t-hex-leg-kit-pair-no-servos.aspx

Built with HS-645HB servos (except Coxa, which has HS-475HB servos).

Is there a setup to use these legs on an SQ3? They are the older L-R configuration, but they could be rebuilt to be in the new symmetry (FL-RR) design.

Thoughts?

Alan KM6VV

Edit:

Just reviewed the video on the quad page:

lynxmotion.com/c-26-quadrapods.aspx

And it shows the quad moving much better then mine does. The video doesn’t show too much. Is there a better one?
.

Yes it is hard to get some of the quads to walk overly well. It has been awhile since I played with any quad except the PhantomX. When I tried earlier with the non-round Lynxmotion Quad, it did not walk very well. Again have not tried with the SQ3. My guess is that you need to find the right body height and probably play around with the positions of the legs to find the ideal configuration. My code for the PhantomX Quad (using their Arbotix Commander), I have code in it, that allows me to change the angles of the legs. Is it better to have all of them 90 degrees from each other or maybe 60 degrees on the side. I can adjust that way. Also maybe the legs work better when pulled in closer to the body or maybe farther out. So I also have it setup that I can also adjust while I am running. But again this is up mostly on my Phantom_Phoenix projects which are simple extracts from the main project like the Lynxmotion one, that from time to time, I try to merge all of the changes back into the main Phoenix In Parts project and/or back into the Raspberry Pi project (miss named now as it also supports BBBk/Odroid and to an extent Intel Nuc).

As for configuration for your 4dof legs, Nope and yep. That is obviously there are no cfg files setup to use them with SQ3, unless someone has done so that I have not seen. However I have built T-Hex 4dof legs (more or less). Not sure if all of my parts are exact or not… I used in with the old CHR-3 body of mine. There are CFGs setup for it that I call THR4, which I believe are up github. If not can be or can upload to forum… Actually I have probably done more testing on it over the last year or so on my Raspberry Pi branch. I was playing around with the Beaglebone Black and/or ODroid awhile ago.

Well, this Quad is certainly disappointing!

I’m willing to swap out the 475 servos for the 645 servos specified, but past that, I don’t know.

It looks like the 'bot is weak. I am on a rug, maybe that’s part of the problem.

I hear you. As I said, if I were to play around with it very much, I think I would look at some of the quads that walk reasonably well and then see what I could do to make mine closer to that one. The PhantomX works pretty well as it is a stable platform, and the default code sets up a very low CG and the like.

Stronger servos would help, not being on carpet would help, If it is not already on, turning on Xan’s balance mode may help…

For the SQ3 to walk correctly, the servos need to be very well centered mechanically and then in the code. The battery also needs to be really close to the center of the robot to ensure the center of mass is “dead center”. We don’t have a particular video of the SQ3 walking except in the SES advert:
youtube.com/watch?v=Ubq5fRObKD0 (0:40, 0:47, 0:53, 0:58)
We would certainly suggest using the 645MG in the shoulder (and if possible the elbow as well).

What code is running the 'Quad in Lynxmotion Ses V1.1 Multi-Legged Robots by Chris&Jim ?

Couldn’t see enough of the walk in the SES advertisement either. I could use a lengthy Quad video! Can we get more from Chris&Jim?

I rebuilt 3DOF legs I had, and didn’t realize they had 475 servos, as I mentioned above. My 'Quad looks anemic. I’ll check the battery placement, but it’s up against the 9V battery clamp. I can go over the servo centering again also. Thanks Coleman.

Can you give me a link to your PhantomX code? (using Arbotix Commander?) How close is it to the LM gethub code?

Do you mean “Square Toggle Balance mode”? I will try that. Thanks again Kurt.

Alan KM6VV