View Full Version : [Question(s)] Has anyone ported Arbotix Pro firmware to OpenCM9.04?

08-04-2016, 02:58 PM
I'm thinking through various architectures for my next hexapod build. I have two OpenCM9.04s already so one idea is to run a RPi3 along with an OpenCM9.04.

RPi3 for OpenCV, navigation, etc, and the OpenCM9.04 to do the gait, trajectory, IK, sensor processing, etc. The issue I have is that I'm unsure of a good data communication protocol to use over a serial link between them. The Arbotix Pro emulates a Robotic servo which seems like a reasonable solution. If I could port the firmware from the Arbotix to the CM9.04, I'd be set.

Has anyone done this or have tips on how I might go about it? Does it seem like a sensible idea?


08-04-2016, 04:12 PM
Not me :lol:

I have ported most of the stuff over to run on Teensy board. I have my own version of a big hat that can plug into RPI or Odroid or UP (If/when it ever ships)...

I screwed up soldering my first attempt to build the hat, will try again soon. I ordered a new set of boards that should arrive tomorrow...

MY WIP sketch is up on github (https://github.com/KurtE/Teensy_Arbotix_Pro)

Note: there are issues that I am not sure yet how I wish to address. In particular the Arbotix Pro has Gyro/Accel, which have specific psudo registers assigned to them. My board(s) are setup to optionally have an BNO055 IMU on it. Do I neuter the functionality of the board and emulate the Arbotix Pro which emulates the CMxxx board (although some of the registers don't quite work the same), Or do I instead use some other method...

Also on my Hat, I have jumpers setup that can let the HOST talk to the BNO055 over SPI or let the Teensy talk to it... I have tested a couple of the Odroids are able to talk to the BNO055 over SPI, but at least up to RPI2s, there are hardware issues with RPIS to talk to the BNO055 as it relies on SPI clock stretching which at least was not working (not sure of RPI3...) so there is an option to jumper BNO055 to run over UART, which I allowed, but then that does not allow me to use the UART on the expansion connector to talk to Teensy, so would then need to plug it into USB...

So the question is What of the Arbotix Pro are you wanting? If you are wanting to use it in a HROS1/5 using the current code then the Accell/Gyro code is assuming that these registers are part of your controller. If instead you are simply wanting to use it to control the servos, then lots of options.


08-04-2016, 04:27 PM
I think when porting to the Arbotix Pro code to a board (Teensy or OpenCM904) that doesn't have the peripheral (gyro/accel) that the Arbotix Pro has, then that register address should just be N/A or maybe just return an error value as data or something. If you add a peripheral to the Teensy/OpenCM, then you have to add it to the register table accordingly. So it'd be the Dynamixel register map scheme, but the register map would have to be somewhat tailored to the hardware that is actually there.

Connecting the OpenCM to the Pi via USB is probably easiest, eh? Although serial would be a little smaller/cleaner. Both the RPi and the OpenCM have 3.3V I/O which is nice.

Or maybe there is a simpler way to simply pass data back and forth. I've never made up my own protocol before.

08-04-2016, 07:01 PM
As I mentioned in the first response, the sketch I have (again for Teensy running Arduino), so not sure how much would need to change to run with OpenCM904... Is setup the same way that Arbotix Pro or USB2AX or ... currently work and that is they receive messages over USB that are in the same format and the like that get sent out over the AX buss. They check to see if the message is meant for them and if so act on it, else forward it over the AXBUss...

With my current code I am setup to allow you to configure which Serial port to use to talk to the host. It may be the USB (/dev/tty/ACM0) (Serial on Teensy) or it may be to the USART on the Expansion connector (name depends on which board...) So far I have tried up to 2mbs.

Yes USB is easiest in certain ways, but mainly in cabling... On Linux side again it is simply which /dev/tty... device you talk to. Note, there are differences in drivers, like FTDI devices act differently than some of the others. Again I don't know the OpenCM hardware, but on Teensy there are some differences on capabilities of some of the Uarts. That is Serial1 and Serial2 use a different clock (which probably goes faster than Serial3. Likewise they have a hardware fifo queue which again Serial3 does not... So again not sure of how many Serial ports you have and their capabilities.

But again this is only one approach.

I have been wondering about maybe trying SPI interface. That is maybe the hexapod wishes to send out desired positions for all of the servos maybe 100 times per second. Could send that out over SPI. The Teensy (or other processor) may be actively monitoring data from all of the servos, maybe timing it in between when it expects an SPI request from host, where it caches things like position, temp, voltage... and can directly transfer the data back to host...

But I was concerned about what about random requests, where we wish to ask a random servo for something. Do I hold up SPI buss until response comes back? Maybe, or maybe setup like some of the Other SPI devices Example (RFM95LoRa Radio), where when it has new data for the host, it uses another IO pin to signal (interrupt pin) the host, who can then ask for the data...

08-04-2016, 09:28 PM
I have two versions based on the original DARwIn-OP code. Code in here: https://github.com/vehemens/baby_overlord

08-05-2016, 12:21 PM
I have two versions based on the original DARwIn-OP code. Code in here: https://github.com/vehemens/baby_overlord

Ah, perfect, thanks.

I'm starting to lean against running a subprocessor, at least for now, but this might be a good option. Lot's to think about.