View Full Version : Robotis OpenCM9.04

01-25-2014, 06:42 PM
Hello all,

I have a couple OpenCM9.04s in and have begun to dig in.

Here's a link to the manual and IDE downloads:

The documentation is a bit lacking overall. I was curious to see what APIs the Robotis OpenCM IDE provided for the dynamixels for example. I found libraries in here 'ROBOTIS-v1.0.1\hardware\robotis\cores\robotis' and with some digging you can see what you can do beyond the standard Arduino stuff.

So far I have most of my older Arbotix code transferred over. I'm using the Robotis built in Dynamixel APIs instead of the Bioloid stuff and its working well. I'm syncwriting the servos as in the "SyncWrite2" example sketch which just stuffs bytes onto the bus and doesn't appear to do any error checking.. the comments say its "new" so here's to hoping.

I have the Arbotix Commander libraries copied over and compiling, but i'm slightly confused by the USART setup on this thing. the documentation is poor and the various charts and schematics all seem to disagree. What i can gather is that UART1 is dedicated to the Dynamixel connectors which is good. UART2 is connected to the four pin Robotis sensor connector, and UART3 runs through an RS485 converter. So to wire up my Xbee i'm pretty sure i need to use UART2. I'll give that a shot tomorrow and see if it works.

01-25-2014, 07:22 PM
The CM-900 (ES and v1.01) has on-board RS-485, but the OpenCM-904 only has upgraded TTL and requires a shield to add RS-485. The AVR and most arduino stuff begin numbering comms interfaces with 0, but STM always starts numbering their stuff from 1 and the schematic might not be too consistent.
USART1 is DXL_TTL and accessible as 'Serial1' (HardwareSerial object) and as a Dxl object.
USART2 is Zigbee and accessible as 'Serial2' (HardwareSerial object).
USART3 is exposed on the headers and accessible as 'Serial3' (HardwareSerial object).
The micro USB port is accessible as 'SerialUSB'.

The 'examples/Communication/Serial_HelloWorld' has the basics of using the zigbee port with print functions as the 'Serial2' HardwareSerial object. To write an individual byte you use Serial2.write(), and to read you use Serial2.available() to get the number of bytes available then use Serial2.read() to grab a single byte.

If you want to access USART2 at low-level, the 'libraries/RC100/utility' files describe everything you should need to connect and use an XBee instead of the ZIG/BT-110.

01-25-2014, 09:02 PM
I see, thanks. Do you think the schematic linked is of the 900 then?

It shows an RS485 network, but it conflicts with other schematics i've seen for the 9.04 such as the one in the hardware section of the manual.

So is USART3 also free to use? It'd probably be easier for me to wire to the header than plug into that 4pin connector.

01-25-2014, 09:36 PM
That is an odd file. I suspect it adds in the RS-485 shield since no version of the CM-904 possesses a barrel connector for power. USART3 should be available even if you did have the RS-485 transceiver since USART3 is still exposed on the headers as D24/PB10 and D25/PB11 for TX3 and RX3, respectively. I am pretty sure USART2 is also exposed on the headers as D4/A4/PA2 and D5/A5/PA3 for TX2 and RX2, respectively with a warning in the proper CM-904 schematic not to use A4 and A5 with the zigbee port.

01-26-2014, 12:51 AM
They have all the signals needed to add a RS-485 transciever broken out to the "D, X, L" pads that you can see on the silkscreen.
This includes the transmit/receive mux.
It's probably easiest to just use those, and the existing DXL library, and wire it to an existing RS-485 driver chip.

Btw: The SerialUSB is really flaky. At a minimum, you have to make sure to return from the "loop" function often, and you have to make sure to not send too much in each "go" or it will just lock up and stop working right. I also don't think it buffers anything, IIRC, so multiple send commands in the same single "loop" call might even trip it up (I seem to recall chasing that down, but don't recall the specifics now -- that could have been a false lead.)

Not all the problems are Robotis' fault, though, as some of the support code that came from Maple is also iffy -- the ring buffer is not interrupt safe, for example...

01-26-2014, 11:24 AM
Ah, having the shield in the schematic would explain it. Are shields available for the 9.04 yet?, i don't foresee using RS485, so i'm going to use USART3 for my Xbee and leave USART2 available for using the 4pin connector so i can potentially use Robotis sensors.

I've been using SerialUSB a lot for outputting debugging text and haven't crashed yet. It's just simple lines, though and i often put a short delay after them. Good to know though, thanks.

Thanks all. I'll post up my Commander code and Dynamixel code when i get it all working for reference.

01-26-2014, 01:38 PM
Well that was straight forward. I wired TX3/RX3 (pins 24/25) on the CM9.04 to the Xbee's DIN/DOUT using a sparkfun Xbee breakout board.

Then i copied the Commander libraries over to the Robotis IDE from an Arbotix Arduino install. All i changed was all the Serial object instances to Serial3 in Commander.cpp.

And voila, it works. I see the Commander values as up to 125 so i believe i'm using Kurt's improved version of the Commander libraries. Or maybe that was only for Commander Controller itself? I can't remember anymore.

01-27-2014, 02:09 PM
I sure wish this thing used a Coretex M4 with FPU instead of the M3. Now that i've signed up my hex as a group class project, it needs to be able to handle whatever we throw at it as far as FK/IK/trajectory/gaits. Ideally we'd use a matrix math library to keep things clear in relation to the matlab simulations which probably means inefficient. If the hardware fails to work, it could mean three of our grades! But at least i have the raspberry pi as backup i guess. Or slicker tricks like fixed point math or look up tables if it comes down to it, but that's a hassle I was hoping to avoid in 2013 and later.

It'd just be so perfect if it was the M4!

01-27-2014, 08:03 PM
I sure wish this thing used a Coretex M4 with FPU instead of the M3. Now that i've signed up my hex as a group class project, it needs to be able to handle whatever we throw at it as far as FK/IK/trajectory/gaits.

There is some good news. The full two-bone IK and gait engine for my 3DOF quad runs in floating point in about a millisecond and a half end-to-end. Do twenty times as much math, and you're still looking at 30 milliseconds, which isn't too shabby. (Of course, do three hundred times as much math, and life is sad. So, simplify the algebraic expressions in matlab before implementing them on the controller!)

Second, I learned the other week that not all M4s have the FPU -- some of them just have the integer vector unit (similar to MMX in idea); the FPU is an "optional" part of the M4 spec :-( But M4 with FPU would be great, I agree :-)

01-28-2014, 09:26 AM
I have all my Raspberry Pi code ported over to the CM9.04 and all systems are go. Basically the peripherals are just the Commander controller via Xbee and the Dynamixel AX-12s.

Right now it executes my IK/trajectory/gait code in about 3ms including the serial print statement. I'm using a 20ms servo refresh period so so far so good.

I love that i can actually fit the battery back inside the chassis again! Nice and clean.