The Complete H3/H3-R Tutorial v3.0 beta

Let's Make Robots Project Ideas
1

This guide applies to the Bot Board II.

The purpose of this guide is to calibrate the servos and store the values on the SSC-32. Then install a version of the Phoenix Hexapod program onto a Basic Atom Pro 28, for PS2 remote control. Other control options such as serial are possible.
(not sure weather to abandon Laurents code altogether, or to try and illustrate both Laurents code and Xans)
(ditching Laurents code in this version)

Note, we used the round hexapod for the images in the tutorial, however, everything still applies to the inline hexapod.

Note, the PS2 control programs have been verified to work with the Madcatz, Pelican, Hiteck and Lynxmotion wireless controllers. However, we cannot guarantee that future versions of the non-Lynxmotion controllers will work.

Hardware:

  • SSC-32 / Bot Board II
  • BASIC Atom 28 -OR- BASIC Atom Pro 28
  • PS2 Cable / PS2 Wireless Controller -OR- RC-Style Stick Radio
  • Hexapod 3 / 3-R

Step 1.
(screen cap of program and instructions)
(have Devon make a FlowStone application to adjust the offsets for the legs and store them into the registers)
(in process)

Step 2.
Connect the serial data cable to the PC’s serial port. This can be recognized by having 9 pins that stick out. Note, if your PC has no serial port you can also use an FTDI USB-to-Serial adaptor /LINK/. The Virtual Com Port (VCP) driver /LINK/ for the FTDI cable has a property called Latency that when adjusted to it’s minimum will provide a fast serial port.

Please consult the serial troubleshooting guide /LINK/ if you have difficulties with this.

Step 3.
Set the robot up on a stand such as a CD spindle. Connect the DB9 or USB-to-serial cable to your PC and to the SSC-32. Power up the robot. Verify that the green LED on the SSC-32 lights up. Note, this is NOT a power indicator. Its purpose is to light up, indicating that the SSC-32 is functioning properly. It will remain lit until it receives serial data. After that, it will blink when receiving data. The servos may jump but will not hold position yet.

http://www.lynxmotion.com/images/assembly/h3r/new/hex02a.jpghttp://www.lynxmotion.com/images/assembly/h3r/new/hex02b.jpg

Step 4.
(this is where we guide the use of Devons new Hexapod leg servo calibration program)
(random notes) We need the default gait to be the tripod an these guys.

2

Hi Jim (and others)
I do think it would be a great idea to get most if not all of the people especially new ones migrated over to Phoenix code base instead of Powerpod. However I also imagine it might take some time. So I do think there are some baby steps we could/should take to get there.

  1. Make the defaults for powerpod work for the robots being bought today… So it should default to Basic Atom Pro (Studio) and Bot Board 2… I believe I have some hacked up configuration files for Powerpod, which I included below.

  2. Get away from using offsets - Could have new program to do this like you mentioned. I think Devon may have the start of this. We can obviously start off with using Lynxterm, as that is what the tutorials for Phoenix use. Still think the Flowstone versions need to have same system capabilities, like being able to know what comm ports are on a machine… My guess is that is now doable with flowstone 2 as it sounded like you have access to system apis…

  3. Need to work on having configuration files for each of the different body styles and leg configurations. This part may be a pain as the number of combinations is reasonably high, especially if we wish to pre-build zip files especially if we then you combine it with the possibility of different Input Methods…

  4. Input methods:
    a) PS2 - We have
    b) Serial - I put a version up earlier that is compatible with the test program for Powerpod
    c) Autonomous - Need to create a sample one…
    D) DIY - XBee, RC… These can be seperate…

So do we pre-create something like 4(xHR, Inline, Phoenix, T-Hex)*6(leg style?)*2(Bap, Arc32))*3(PS2, Serial, Auto) or approximately 150 combinations… So may want to figure out a way to make it easier…

Kurt
Powerpod files updated.zip (11.2 KB)

3

Hi Kurt,

Thanks for your input! It is very welcomed.

Yes I agree this is a must do…

The new Flowstone no longer has a com limit of 10. Devon’s program will not do anything with code, but it will be feature rich. It will replace LynxTerm in the Phoenix and T-Hex tutorials as well.

Yeah that’s not what I had in mind at all. lol

The code simply needs to work for the following.
Bot Board II / Atom Pro 28 <— This will change to Botboarduino ASAP
SSC-32
PS2 controller
Config files limited to only what is sold, not every possible combination. I suppose it would make sense to incorporate the T-Hex and Phoenix into this new guide as well.

4

Flowstone 2 - Lynxterm: I am hoping that if you are going to have a flowstone version to replace the current one, that the new one be as feature rich as the current one… Things like the ability to resize the window. I may want a very different size window on a 25 inch desktop than I want on a 9" portable… But this is a different conversation. Likewise My impression at looking at what they were adding, was the ability to get to system APIs… So hopefully the comm port code can detect which ports are actually on a machine and only populate the list with those that are actually on the machine.

But now back to conversion from Powerpod to Phoenix code and more things to think about.

a) The new Phoenix code only outputs Binary data to the SSC-32. This implies that if the user does not update the firmware on their SSC-32, their robot will not do anything, which will probably cause more support calls/posts… Too bad the SSC-32 that is shipped today does not come with this firmware installed and maybe only ship the SSC-32 with the other firmware on 2DOF hex robots… Alternatively add support back in to the SSC-32 file that if we do not detect that the SSC-32 is an EGP type, we use ASCII commands. Yes more code, but… Could add in an ifdef to optionally remove this extra code if the user knows what they are doing. Yes I know Xan does not like ifdefs :laughing:, but I personally am not sure how many people are going to dig this deep into the SSC-32 file…

b) Powerpod version has some built-in behaviors for some instant gratification, like Attack Mode, Try to fly… These are great for new users to demonstrate their robot to their friends… What to do with Phoenix code version? Options are:

  1. punt
  2. add these in to the code - Extra code to maintain for limited use, plus not sure we have extra free buttons on PS2 that we are not using…
  3. Convert these to GP sequences and have a simple step for the user to install them on their SSC-32…

c) If I hack up an Autonomous control file, I will probably punt on b) above and have it do the simple stuff. Not sure if we should do like powerpod where the code did not do anything, or if we should have some example code in it, that maybe reads a sensor (or 2) and does some simple behavior… Or if this should be a sample that then gets posted…

All for now
Kurt

5

Ahh ok, I will talk to Devon about it when he gets in. Sounds interesting.

Ughh! You’re right I forgot about that. Well there is one good thing in that these new tutorials will co-exist with their older counterparts, so we can keep them separate. I now think combining *H3 with Phoenix, T-Hex, and soon A-Pod, is just not a good idea. They all have their own idiosyncrasies.

We can change what firmware is installed during testing, but it will take time for them to make their way through the system. Would a fall back to ascii mode be a reasonable solution? The speed increase binary mode provides isn’t really required for these walkers.

You sure do know the right questions! I know what you mean about the attack and fly routines. The baby steps mentioned above should get that tutorial more up to date for now.

I have got to get a handle on this stuff. We periodically have to come back and redo everything on these walkers. It’s time that could be better spent on new products. I am trying to deal with this myself so I do not interfere with the A-Pod progress. Soon I am pulling Devon in to help me with integrating the BotBoarduino into all BotBoard/Atom Pro based tutorials. I know we are swamped, but I tend to think screwed more accurately describes the situation. lol

6

Personally I hope we can continue to have the Phoenix code base support all of the 3-4DOF Hex robots. A-Pod may be a challange, but…

Adding back in Ascii support would not be difficult. Personally I am not sure in how many cases we gain anything by using the binary mode. We still gain the 3 times speedup from being able to run the SSC-32 at 115200 instead of 38400, so the question is, when will we see a difference with sending about half the data. The answer is only when the step has no pausing, that is with most steps in the gait, it says move the servos from here to there in time X and then it computes the next location (and time) and outputs it to the ssc-32 without committing it and then WAITS for the previous move time to expire and then commits the next move. The commit for the text version is simply the CR, for binary mode it is a 3 byte output (Indicator and 2 bytes time). So in this case binary is slower. So the question is what percentage of the time did our steps in the gait have 0 wait time… My guess not often…

Kurt

7

Ok so this sounds like due to the faster baud rate ascii can be used without a performance hit. The binary firmware really lends itself to fast polling of the SSC-32. I’m ok with this!

The goal of having all pods using the same Phoenix code base will take some time to coordinate.