Source code for R++ Manager CM9.04 sketch? about opencm9.04 HOT 11 CLOSED

Just an FYI - I have been playing around with my own sketch which is not done, but some parts are limping along...

If anyone is interested, it is up at: https://github.com/KurtE/Open_CM904/tree/master/OpenCM_Servo_Controller

The R++ manager connects to it, as Protocol 1. Note: The code is hopefully setup that it will talk to device 200 with either protocol 1 or protocol 2.

Also while working while looking at it with R+ Manager, it now appears like there are a few more logical registers that are not shown in E-manual

11 - Bootloader Version (Not sure what this is for)
16 - Dynamixel Channel - Actuall this is what I mentioned wanting... above so will add to my program next ...

Still lots more to do.

from opencm9.04.

Hi, @KurtE

I do not understand your words well.
Could you explain something in more details (and simply)?

from opencm9.04.

Hi, @OpusK and @ROBOTIS-Will ,

It is a coincidence, that the same things was asked for over on the Robotis Forum, the next day:
http://en.robotis.com/service/forum_view.php?bbs_no=2406938&id_memory=1

Where today(yesterday) Will answered, that the Firmware sources are part of the Robotis Mini project and are not open source. What is confusing about this, is the Control table and the like are all described in the OpenCM9.04 E-Manual

What I was asking for, is there an Arduino sketch available for this firmware? In much the same way as the firmware for the OpenCR board ships with the OpenCR installs where you can program it using maybe a pre-built binary OR you can load up the sketch into the Arduino IDE and program it that way...

If you don't wish to release it, I understand and when I need it, I will probably write my own version, which will be a sub/super set of the default firmware. I might start from one of the earlier ones I did for a Teensy. Example: https://github.com/KurtE/Teensy_Arbotix_Pro was a version a version I did to use a Teensy 3.x board to emulate the Trossen Robotics Arbotix-Pro board, which emulated the CM730?
I have a version that minimized some of the control table... No Gyro...

Here are some of the steps, I expect to take:
a) USB->Dynamixel communications - Echo stuff both ways. Like example c_Serial_Serial2_Converter, except Serial1 and/or Serial3... Done that earlier...

b) Start to Interpret the communications - That is understand Protocol1 and/or 2 protocol messages coming from USB. Setup using state table, to understand start of packets... to End of packets. With this assign my self a Servo ID (200).

If the packet is not meant for me forward it on out to servo chain. If it is for me, don't forward and if appropriate generate response packet to send back.

c) Also understand format of return packets on the DXL Bus. Again forward all of the Serial data we receive on the bus and after we receive an end of packet, here is where I would probably try to force the system to do a Serial.flush() to get the response as quickly back to host.

d) in b) probably had real rudimentary control table, would expand out to handle most/all of the entries shown in the E-Manual. If the message was Protocol 1 only the first part of the table (<255)

Add EEPROM support for saving away changes in the appropriate part of the table, and restore these values when we boot.

If the requested operation was a write - then when we get the completed message update any necessary hardware updates. Like turn on/off LEDS.

If the request is a read, then maybe need to read hardware state before this...

e) Maybe later add in some of the other extensions that was in Teensy code. Like for Protocol 1, add support for SyncReads - Others have done this as well like USB2AX. Where the board intercepts the GROUP Read request (either to it's ID or to broadcast), and then emulates this by sending out individual Read requests over the Dynamixel Chain and getting the servo responses... Then it packs up the data and sends it back to host as one logical packet.... Which can really help to minimize USB latency...

Sorry for the long winded response. The short question, is. Is there an Arduino sketch, which we can download, which implements the firmware that is described in the E-Manual?

from opencm9.04.

@KurtE,

What you want is: Firmware containing the control table can also be made available via Arduino sketch, and finally accessing the control table of the firmware downloaded from the sketch file through DXL protocol.

Did I really understand what you want?

You can refer to the following references with regard to putting control table function in OpenCM9.04 firmware.

• XelNetwork_SensorXel

OpenCM9.04 Arduino's official support for these features (or examples) is an issue that needs to be discussed internally.

from opencm9.04.

@OpusK and @ROBOTIS-Will and @chcbaram

Thanks,

I think your simple answer to this, is that the sources for this firmware is currently public, which is a perfectly valid answer and could easily simply close this issue out. Which would be fine.

Why I asked and what I might want over a longer period of time...
Warning sorry in advance for rambling on here :lol:

I asked partially out of curiosity. I wondered how some of the code worked. Example when you receive something over USB, do you immediately forward it to Serial3? Or do you interpret it first to see if the packet is supposed to be handled locally first and only after you have looked at the first N bytes (FF FF FD 0 ID) and find that the ID is not yours do you forward it over the DXL chain... Or how are you handling the data going back to host over USB? Are you waiting on the USB timer which was 5ms?

Partially asked for clarification on what to tell other users. Example suppose a user buys one of the newer Trossen Robotic Arms, like: https://www.trossenrobotics.com/pincherx-100-robot-arm.aspx
Which currently they don't have any released software for... And suppose the user experiments some with writing some simple program for the OpenCM9.04 board that ships with the arm... Then later someone releases some PC based software for controlling the arm and assumes original firmware for forwarding USB commands to the servos... How should these end users restore some firmware that works? Current answer is they need to install R+ Manager 2.0, and when they load it up, they are met with a dialog that says this only supports the following products... Their Arm is not listed... Neither is the OpenCM9.04 board nor XL/XM servos...

NOTE: I do not work for nor speak for Trossen Robotics, I am just a long time customer and some of the stuff I have done on their robots (mainly hexapod) is used by many of their customers. Like the Phoenix code base example: https://github.com/KurtE/Phantom_Phoenix

Also versions that run on SBC computers like RPI: https://github.com/KurtE/Raspberry_Pi (Which I really need to cleanup...)

As for myself (I enjoy tinkering ;) ) and maybe I should state, that for my own usages, I personally don't need 100% compatibility with the shipped firmware. That is I really don't need all of the extended registers for the different sensors that you might use on the OpenCM board (registers >= 360), although it would not hurt either. Again mainly wanting the OpenCM board to be a Servo controller board, which I cold plug into PC or SBC like RPI3, ODroid, UP, ..

Example usage: Suppose I have a Hexapod robot, like: https://www.trossenrobotics.com/phantomx-ax-hexapod.aspx it shipped with their own controller board (Arbotix-m), which is an AVR Atmega644p (8 bit 16mhz 2 uart) board... And suppose they wish to replace this board with a standard supported board like the 904C boards (openCR would be great as well). I have a WIP verson of the Hexapod code base that runs on the OpenCM9.04 board up on github as well

But at some point I will want to try it out again with RPC board driving it? So again wonder what firmware to run on the 904 board. Which is what this question is/was about.

The problem is I may not want to use the default firmware as is? Why? well suppose I don't wish to use the OpenCM485 board, but instead use the Servo connectors on the 904C board and simply connect one of these connectors to a powered DXL servo HUB, like ones Trossen sells. Problem is I believe the firmware is probably hard coded to Serial3? So I might want to make a version which has another register in the EEPROM region, where I can select which Serial port. Actually I might want two registers, one as Default Serial port, which is stored in EEPROM and another Current Serial port, as maybe I want to support both? Although maybe not as likely...

But the question is, do I develop my own code base for this or do I Fork some code base, make my own changes like this, and then if appropriate, issue Pull Requests to allow you to maybe incorporate these types of changes into the official code base.

Again sorry for my ramblings above. Hopefully some of it makes some sense.

And again feel free to close this issue.

from opencm9.04.

@KurtE,

Unfortunately, R+ Manager is closed source for company policy and can not be modified by users.
You can create custom control tables through the repositories I've given you, but you can not change the tables in the Manager.

Our open project related to the repository I linked to is underway. The document is being written, and the link is as follows.

• XelNetwork

I think this project has two points of connection with your issue.
First, CONTROL TABLE.
Each Xel has a control table and communicates through the DXL protocol.
And since it is open source, you can modify it or reference it. Like you now!

Second, GUI MANAGER using DXL protocol.
We are Implementing a GUI Manager that allows users to easily access and read/write these control tables.
Of course, this is not the OpenSouce version of R+ Manager!
It is just a program for accessing the control table of XelNetwork Xels.
However, because it is open source, you will be able to control the custom control table of your controller if you make a few modifications.
We are also planning to download the firmware to this Manager.

Sorry for not helping with R+ Manager.
But, I hope news I mentioned helps you.

from opencm9.04.

Thanks, @OpusK understood.

As I mentioned, It just would be nice if there was a simple alternative like the ones you mentioned, that ships with the IDE, which gives the user simple Servo controller support CommXel controller.

My semi quick and dirty app is starting to work... Still debugging. Anyway having fun, which is the main part.

Besides It is also an interesting thing to see what communications happens... I am outputting in all of the data bytes received by the USB port to Serial2, which I print out... Plus some of my responses.

I am seeing the normal like data, like:

FF FF BE 2 1 3E
FF FF BF 2 1 3D
FF FF C0 2 1 3C
FF FF C1 2 1 3B
FF FF C2 2 1 3A
FF FF C3 2 1 39
FF FF C4 2 1 38
FF FF C5 2 1 37
FF FF C6 2 1 36
FF FF C7 2 1 35
FF FF C8 2 1 34

But once the normal stuff is output, I then start to see a lot of not normal messages:

FF FF C8 4 2 0 3 2E
sendProtocol1StatusPacket err:0 Count: 3  90 01 13

FF FF C8 4 2 0 7 2A
sendProtocol1StatusPacket err:0 Count: 7  90 01 13 c8 03 00 13

D
D
68
65
78
D
D
D
68
65
78
D
D
D

The hex one character per USB output keeps repeating.
Looks like something is outputting;
68(h) 65(e) 78(x) cr cr cr

Also the data that I am forwarding from USB to Serial1 or Serial3 does not look correct.
I need to look to see how I am buffering this and if the TX direction IO pin works correctly...
More debugging tomorrow...

from opencm9.04.

@OpusK, @chcbaram and @ROBOTIS-Will and others:

I have been playing with this some more, as part of my testing of #36
Work and I think I have more parts working now.

I now have it working with R+Manager 2 recognizes my Sketch:
https://github.com/KurtE/Open_CM904/tree/master/OpenCM_Servo_Controller

Still lots more to do, to flesh out more things, like changing the baud rates on the fly and more of the control table to make work and understand...

I do have some support in now that turns on/off the LED. Not sure if it should be Aux or Motion. Can figure out by using default firmware...

Some of the things I can receive include: Button, Random number, Port 1/4 IR, Port Ports1/4 DMS. Ports 1/-4 touch (not tested as R+ manager does not show touch values). Don't have the other OLLO sensors to try out here...

There are several registers in the control table that I am not sure what they do... Any input of some of them would be appreciated, but I also understand if you don't wish to document some of them as they may be R++ proprietary. Items like:

21 Mode Number
68 Motion Play Status
73 128ms Timer value
74 1ms Timer value
230 Adjust offset ID 0

386-387 Port 2 User Device Value? Assuming digital? Analog?  
388-389| Port 3 User Device Value 

I am thinking of extending some of this. Maybe fill in some holes.
Example when used with OpenCM485 board. Maybe something like:

(Maybe this is Motion LED? 82)LED1
(maybe 83) LED2
(maybe 84) LED3

(maybe 27) Button 1
(maybe 28) Button 2

Why not Port 1 and Port 4 user values?

Also wondering about having the ability to change the Dynamixel Channel? That is have register 16, be the default Boot channel (EEPROM), and maybe have Another non EEPROM register (20?) as
Current Dynamixel Channel. and maybe 22 current Baud? This may be overkill, but maybe could see setup where user has some XL320 on Channel 0 and XL430... on Channel 1?

Thoughts? Suggestions?

Thanks
Kurt

from opencm9.04.

Probably time to go ahead and close. And the initial question was answered.

Unfortunately, R+ Manager is closed source for company policy and can not be modified by users.

from opencm9.04.

Hi, @KurtE.

I am sorry that my answer is too late. I went to ROScon2018 and now I came to Korea.

As you said, the control tables for each product are different for each series, and even within the series.
But let's move on because this is not what we can do, and R+Manager is also unable to modify the code.
So, I suggest XEL Manager which can modify the code instead of R+Manager.
Although it is not cleaned up, now we are creating and controlling Custom Control tables. (CommXEL, SensorXEL, PowerXEL)

The current source code is only available in the develop branch.

from opencm9.04.

Thanks @OpusK,

As I mentioned I thought I might as well close this issue as the primary thing was resolved (That is, is the sources for the firmware that ships on the board available) And the answer was no...

As for some of the intentions for asking. There may be in the future follow on questions or maybe Pull Requests.

Example: Assume I put in PR for Serial.getBaudRate returns: LineCoding.bitrate,
Then maybe add an example program that does simple Servo forwarding...

I will have two versions.

1. Simply works like the Serial to Serial2 example program, that is, it is not it's own node.
2. A version closer to default firmware. Where all of the defined registers in the manual that make sense without the Roboplus stuff are supported. Things like setting which buss, LEDS, Buttons,

For now these programs as well as some other test programs are up in my github project:
https://github.com/KurtE/Open_CM904

from opencm9.04.