I have a CH3-R hexapod with Mini-ABB and SSC-32. I can control it very well from the PS2 remote control but for my project (robotic mapping) I want to substitute the mini-abb with something more powerful (an fpga board) and keep the rest of the platform (hexapod and ssc-32). My problem is the folowing:
I conected the mini-abb’s serial link (the yellow/black pair of wires that link the two boards) to the pc trough a ttl-to-rs232 converter and now i can see all the data (commands) that mini-abb is sending to the ssc-32;
after that i recorded this data in a text file and i playback (send them serialy to the ssc-32’s Rx pin) them with a simple python script; the “initialization” code works fine (exactly as it was when the two boards were connected directly); i introduced a 0.3s delay between commands, obtained expermentaly;
the problem appears when i try to record and playback the commands for moving one step forward for example (or in any other direction); the movements are radically different from the ones made when it was connected directly;
i recorded twice the commands that it sends for moving fwd and if i compare them that are diffrences;
What could be the problem? I saw that in the Basic code that i uploaded on the mini-abb (the one obtained with PowerPod) there are a lot of kinematics calculations. But are they necessary ? Wouldn’t be possible to record (hardcode) the commands for each elementary movement (forward, backward, left, right, etc…) and play it back ?
How do you recomand me to solve the problem? I’m not proficent in reading Basic Does anybody have the equivalent in other programing language (C, Java, Pyhton) ?
In my humble opinion you are barking up the wrong tree so to speak. PowerPod allows you to create a program to control the hexapod via serial commands. So you retain the ability to command the robot on-the-fly rather than relying on canned sequences. What you are trying to do is overly complicating the project.
I don’t understand exactly what you are speaking about (where can i find more info about that ? do i have to calculate the positions of all the motors for each kind of movement ?), but that reminded me to look closer to the powerPod options and i found a “Serial Port Control option” that produces a Basic source code that i uploaded onto the mini-abb and after that i ran the Serial Port Control Panel application found in the Tools subfolder of the PowerPod instalation folder an the Serial_H3.exe from the ./Tools/C++ Demo folder. The second one allows to move fwd and backward and i have there the source code too. I saw that is sending an array of 7 bytes (56bits) and there is some kind of variability produced by the position of the slider component.
Now my question is simpler … i think
How do I compose the 7 bytes “packet” that is sent from the application and what is the meaning of this bytes?
Remember form my previous post that i want to be able the move the robot in the four directions and that is all for the moment, so i would need the four “packets” to be sent for this elementary movements.
You got it brother! That’s exactly what I was talking about.
I am not sure where that information is, but I will ask Laurent to post here with some help. It will be later today. One possible hint is to look at the basic program on the bot. In the comments within the program there should be a list of which buttons do what. The 7 bytes I think are the same as what the PS2 controller generates for each button pressed.
the 7 bytes are explained in the source code,
see the “invite.cpp” file
then search the “void __fastcall TInviteUnit::ComPort1RxChar(TObject *Sender, int Count)” function.
the second to the seventh bytes simulates PS2 buttons (2 bytes) and the PS2 sticks positions (4 bytes),
the first byte is a checksum of the 6 bytes (exclusive or (XOR) of the 6 bytes)
It’s the program in the Basic Atom which decide when you have to send data to him :
when the BA is ready to receive data (the 7 bytes) it sends 2 bytes “Rd”
then you have a very short time to answer and send the 7 bytes
this issue is due to the fact that the serial port on the BA is not buffered.
so if you send data while the BA is not reading => datas are lost,
the BA can’t stay in the reading mode because it must loop to handle the IK and gait.
about your first attempt, each command is a big line terminated with “T210” or something similar then a carriage return,
to play it again, send each line with a carriage return (ASCII 13) then wait 0.210 seconds.
only wait 0.210 seconds when a line is ending with T210, else send it as is
some version are using another value