Sequence read in and write to Scc32 from main computer loop

Lynxmotion Electronics & Software
, ,
1

I’m trying to find good complete examples (code) of reading a PEP s.s. or sequencer servo motion sequence and writing it out to the SCC32.

Over the last decade or so of playing with hexabots (UAV’s UWVs), this is one topic that seems to remain incomplete. Add to that perhaps my own added confusion swapping in/out different main compute nodes ( Arduino, Odroid, stamps, Raspberry Pi, Arbotix-M, c904, straight up 328’s etc, I still have a rough time formatting a proper regime for sending pre-configured sequences to the 18 servos of my latest bot.

I have a Trossen Hexapod (serial AX18 servos) running the Phoenix code and have had it running oem, Phoenix, and scratch coded executables. I have a highly modified (lots of 3D printed and custom CNC carbon fiber stuff) Freenove ‘Big Hex’ (645 style analog servos) running on a Pi that has it’s own I2C interface to PCA9685 servo drivers. (facial recognition, color tracking/follow on a pan/tilt head all running on the Pi)

What I’m finding is a major lack of software examples of actually reading in a prebuilt sequence and writing it out to an SCC32. Switching between SP1, I2C, softserial, USB is not an issue. I know for remotes, simply basing a redesign on the Phoenix_Input_PS2.h will get me routed remote control wise.

PROBLEM: PEP, the Flowbotics based SCC32 Sequencer and the like, all gen ‘angles’
EG: PhoenixLM01 2 3 4.978 -34.666 -16.745 14.643 -2.678 -0.727 12.345 33.655 25.89 4.978 -34.666 -16.745 14.643 -2.678 -0.727 12.345 33.655 25.89

HOW is this reformated into a string in the format the SCC32 takes
EG: # < ch > P < pw > S < spd > … # < ch > P < pw > S < spd > T < time >

I have never found code that handles this. For me, adding an external EEPROM to an Arduino, or simply files on the Raspberry Pi TF card can be read and dumped to the SCC32 via the TTL serial port the Botduino talks through.

The issue (and needed resolution) is a sequencer R/W that uses any of a number of just as fast as an EEPROM storage media of todays SoCs compared to that of a decade ago when all this was in fashion.

Anyone up to the task of posting a decent RPi file based R/W sequencer that can read the current PEP or SCC32 sequence built files?

tia

ptegler

FNBigHex1pategle
FNBigHex1pategle3264×2448 1.46 MB

3

@zwizardz Welcome to the RobotShop Community. Just to confirm, you are aware that the Phoenix code was first done for the SSC-32, and the code (with PS2 input) can be found here (ex BotBoarduino is Arduino-based):

Regarding running code which is sent directly from a Raspberry Pi to the SSC-32 (using level shifter perhaps, or the USB cable), it seems that would best work in Python, and unfortunately there’s no sample code for this.

You might want to see if @kurte @xan might offer some insight (they are the gurus of hexapods). :grinning:
@mdvorsky is the go-to person for the SSC-32.

1 Like
4

Sorry, it has been a real long time since I did anything with SSC-32 especially with sequences. Probably over a decade ago. Again this is something that maybe only @zenta might be able to answer and that could be a long shot as well.

I am sure you already looked at the PEP page:

http://www.lynxmotion.com/images/html/proj098.htm

Which I believe you could have PEP output a CSV file and import it into the SSC-32 sequencer program, which I don’t think exists anymore, it was sort of replaced by a flobotics version:
http://www.lynxmotion.com/p-895-free-download-ssc-32-servo-sequencer-utility-created-using-flowbotics-studio.aspx

But I don’t remember if it supported this or not…

Details on how to store data to SSC-32 for the GP mode can be found in the document:
http://www.lynxmotion.com/images/html/build137.htm

Sorry, I know this is not much help, but as I mentioned, I never really did anything with this (did have support in the Phoenix Code to use it if desired) but again I never used it except to verify it works, by using the zip files that Zenta posted.

1 Like
5

thanks guys (for the replies) but as anticipated…gets me nowhere. :frowning:
These logistics (no compatibility between the PEP output and sequencer (either version) is precisely why I moved completely away from the Lynxmotion (now robotshop) code bases and hardware. I pulled out my probably decade old orig scc32 and nada… same issues…no sequencer ops The new scc32U did away with the eeprom, which isn’t even mentioned in the description or I would never have bothered with what i thought was an updated version.
I’ve spent the better part of the last 4 decades designing factory robotics and automation (electronics design AND the programming) for the manufacturing and automated testing of military hardware in a production environment. Believe me when I say these little servo boards are some of the simplest ‘toys’ I’ve ever played with. It just burns my heart to see so many people get pulled into a genre of hardware/software that ultimately is a fizzle much past ‘I got it to move’. Synthiam and others are headed down that path now as well.
Best of luck
ptegler

6

If you really enjoy the programming side of hexapods, you might be interested to note that the new SES V2 Hexapod is set be ROS 2 compatible. cmackenzie will be releasing a video update there shortly.

1 Like
7

Likewise, I moved on to other things as well, like moving away from RC servos to using smart servos. In my case mostly Dynamixel servos, but have now played some with the LSS servos. Now days most of my hobby time, I play more at the low level with Micro-controllers by PJRC (Teensy 3.x and 4.x), and not a whole lot of time doing robotics.

And Remember PEP is not or ever was a product. It was a project done about 12+ years by the user zenta, for his own purposes on his(the original) Phoenix and then was written up as a user project. His original Phoenix hexapod was the basis for the later Lynxmotion Phoenix kit.

it was developed to run on a Basic Atom Pro (which is no longer sold) that used a SSC-32 controller (no longer sold), that relied on a updated firmware for the SSC-32 (GP mode). And while the canned sequences were sort of nice for a quick demo to someone. After playing with them when they first came out, I never used them again, except maybe to test that still worked…

I do not believe the replacement board (SSC-32u) supports GP mode. Likewise the EEW/EER commands either don’t exist or work differently…

I believe he relied on using the old Lynxmotion Sequencer program to save or retrieve sequences from the SSC-32… That software has also long ago been retired.

Toward the end of the “Original Lynxmotion” era they were trying to transition most of the software over to a Graphical UI setup FlowStone and the updated sequencer program, which I linked to in previous post. I don’t remember if they had any support for sequences generated by the original sequencer program. Now days I don’t know if the Flowstone system is sold anymore. Their website:
http://www.dsprobotics.com/index.html
Looks like it has not been updated since maybe 2012 and their last blog 2016…

So I would personally not suggest spending a lot of time trying to resurrect the sequences. However if your goal is to get your hexapod up and walking using, an RPI connected up to an SSC-32, that I have done. I have a github project:

But the project is a complete mess. There is probably 4 or 5 different versions of phoenix code up there. Probably the stuff up in the
https://github.com/KurtE/Raspberry_Pi/tree/master/Phoenix_fixed section is the most likely to maybe be made to work… But again a lot of this stuff has not been touched in maybe 8 years now.

There are code bases done by others as well. I have not looked in a long time for how many support SSC-32 and RC servos. Again by that time I mostly had moved to using Dynamixels. But did have a T-HEX setup to work, And like wise a THR round hex with 4dof legs…

Again probably not much help, but good luck.

8

Again, thanks for the replies guys. All point mentioned about the states of the sequencers and etc is of course acknowledged (and already understood) . Yep (KurtE) have multiple edited copies of your GITHUB contributions from eons back. :slight_smile:

I have several serial servo projects under my belt. (these newer hobby style serial servos speaking here )
I have dozens of large scale servo system designs under my belt. from tonnage, down to cleanroom micro positioners with nanometer resolution repeatability.

I Have run at least 6 variations code run on Arbotix-M, C904 (various Arduino based controllers) and software stacks on my PhantomX as a ‘master’ test platform. Have played with the Dynamixel, HiWonder, Lewansoul, Feetech etc.

I currently have an RPi using the I2C buss to drive a pair of PCA9685PWs to control a hex. The Pi handles the facial recognition, color tracking, ROS and SLAM code I ported over from my UAV work. (might even move one of my mid size Lidar units over to the crawler just to play)

In the world of factory robotics repetitive positioning is the norm. So a sequencer for ANY robotic motion control is a worthwhile effort. In the case of the newer RC style servo of serial servos avail today even these little ones can be manually positioned and read back for recordation of a sequence. At least with the Pi you have the compute power for tactile (real world sensory for people/external safety) feedback. PID and other dynamic feedback loops are easily implemented in subsidiary compute nodes.

My earlier comments were I admit, coming from the frustration of ‘dated’ material and mixed messages I understand newbies must run into as well trying to learn from ‘those that have gone before’ when materials are not ‘dated’. Actually that is becoming an issue, internet wide. (no one date codes their info)

ok…fun stuff… this is fully autonomous…except for me interfering trying to change gaits for the video. This was using Mission Planner, with a Pixhawk controller telling the crawler where to go via 915Mhz bi-directional radio link (the planes messed with the radio link) PhamtomX Hexapod running around outdoors - YouTubehexapod autonomous trip around the yard (convoluted path thanks to the planes interfering with gps and telemtry)