top of page

ROBOTIS Evolving DYNAMIXEL Concept
By C. N. Thai (updated 4/9/2022)

     For anyone using or reviewing ROBOTIS products for the first time, you probably ran across the “DYNAMIXEL” concept.  If my memory serves me right, ROBOTIS was awarded a patent for “DYNAMIXEL” back in 2003, so the concept has been around for a long time.  Essentially, a DYNAMIXEL is a Smart Actuator, as besides its main component being a DC motor, it also has an embedded controller (Atmel AVR in the early days, but an ARM chip from STM in recent years) which can access sensors such as position encoder and temperature transducer, and it can also “act” on its motor to operate it in continuous turn or position control modes.  Furthermore, it can communicate with a main controller such as the CM-5XX series, so in a limited way a DYNAMIXEL can be classified as a “robot” too, according to the "Sense-Think-Act" paradigm.

​

     I have used ROBOTIS hardware and software products since 2007, and admittedly, the DYNAMIXEL concept had not been critical to my learning and using the RoboPlus software suite (which was the only tool available when I started on my ROBOTIS journey with the CM-5).  But nowadays, users of ROBOTIS systems have many hardware and software options to choose from, thus my motivation for writing this article was to help current users and potential adopters to have a more discerning view of the ROBOTIS "Dynamixel Network Design”.

​

     As I had never been an employee of ROBOTIS, i.e., I have no access to their “real” technical knowledge, all technical errors that readers may find in this article are my own!  Also, as a consequence of this, I am going to take the point of view of an end-user and use the official timeline of product releases by ROBOTIS as a story line.

​

     Starting out in 2007, I was using the BIOLOID COMPREHENSIVE and EXPERT kits which came with the CM-5 and the BIOLOID suite: “Behavior Control Programmer” and “Motion Editor”, and an Embedded C library of functions which was the precursor of the current Dynamixel SDK, available in many versions from Arduino to Matlab.  The RoboPlus suite (V.1) came out next in Spring 2009, with the release of the BIOLOID PREMIUM and the CM-510 (which was replaced by the CM-530 in 2011).  The figure below shows the Functions Menu of TASK V.1.0.1 (dated 4-28-2009).

Category Menu in TASK V.1.0.0

      The key items to notice were:

  • Under the “Controller” tab, there was only the “Motion” item which was of course related to Motion Pages created by the Motion tool.

  • Under the “Dynamixel” tab, the “Custom” item was for adjusting parameters that were not nicely provided as an “iconized” parameter such as “Goal Position”.  For example, to adjust the Punch parameter of your Dynamixel, users (to this day) still have to use the “Custom” function and consult with the Control Table of the actuator being considered to find the correct address for the function “Punch” to use.  For example, the Control Table for the AX-12 series can be viewed here, showing that Address 48 should be used.

​

   Essentially for TASK from V.1.0.1 through V.1.0.15, users had only to be concerned with Actuators and Sensors being DYNAMIXELs which used individual IDs from 1 to 255.

​

      When RoboPlus V.1.0.16 came around in Spring 2010, I noticed an additional item "Custom" under the Controller tab as shown below.

Category Menu in TASK V.1.0.16

    “Reading between the lines”, I understood that the Controller was now considered as a DYNAMIXEL with a reserved ID of 200, but where was the Control Table for the Controller (i.e. CM-5/510/700 at the time)?  Actually, to this day this information is not published anywhere on the ROBOTIS e-Manual web site, and it was only in late Fall 2016 that this kind of information was available to end-users, but in “unadvertised” ways (I will get back to this in a later section).

​

     A few more upgrades later, TASK V.1.0.31 got released in July 2013 and the picture below shows that obsolete sensors got “retired” and newer sensors and actuators were now supported.  But still no public support for DYNAMIXEL ID 200.

Category Menu in TASK V.1.0.31

     Task V.1.1.0 came out in December 2013, and I noticed another interesting item, “Remote Device”, which had numerous new functions obviously related to mobile phones (please see figure below).  This coincided with the first release of the SMART system which was only released for the Korean-speaking community at that time (2013).  At present, Spring 2022, the SMART system had gone through 2 enhancements and is now SMART III, but still, it is only available to the Korean and Chinese (since 2015) speaking users. 

Category Menu in TASK V.1.1.0

      The previous picture also shows that the “Remote Device” has a reserved ID of 100.  Needless to say, I was very frustrated by the lack of information about features that were obviously very interesting to ROBOTIS users worldwide.

​

     Then in December 2016, the PLAY700 kit (with CM-50) was released for the USA market and it came with 2 new software tools: “R+m.PLAY700™” as a mobile app (Android™ and iOS™ versions) allowing a TASK program running on the CM-50 to access multimedia services from mobile phones and tablets; and “R+SCRATCH™” allowing the interfacing of the MIT SCRATCH™ 2 software (running on a PC) to ROBOTIS controllers such as the CM-50.  The PLAY700 kit also came with a TASK program (in English) showing me for the first time how to use the SMART DEVICE functions from inside TASK.  I also was trying to understand how the R+SCRATCH program worked, and I stumbled upon a treasure trove of information on the Control Tables of ALL existing ROBOTIS Controllers, Firmware 1.0 and 2.0 alike, in English, Korean and Chinese - at that time (see pictures below).

Control Tables for Firmware 1.0 Controllers
Control Tables for Firmware 2.0 Controllers

     All this new information triggered my checking back with the OLLOBOT SDK which was released in August 2016 for an entirely different group of users who would be familiar with Smartphone App Programming.  The OLLOBOT SDK essentially allows a smartphone to directly control any Firmware 2.0 controllers from ROBOTIS, while retaining the use of existing communications and multimedia services on the mobile device.  And to make a long story short, I finally could solve the puzzle that was presented to me since December 2013.  All these investigations resulted in the materials for Chapters 9, 11 and 12 of my 2nd Edition Springer book.

​

     For me, the “Big Picture” that emerged from all these sources of information and from my own experimentations was as follow:

  1. Robotics Programming with ROBOTIS systems can be viewed as Network Programming with various DYNAMIXELs communicating with each other, sometimes working on their own, and at other times working in concert.

  2. Communication packets are of two types of protocols (1.0 and 2.0).  Mixing protocols is permitted but must be done with care.

  3. Communication packets can be of the INSTRUCTION type (with up to 11 different purposes from Read/Write to Bulk Read/Write) or of the STATUS/RETURN type (with only 1 purpose, returning some kind of information).

  4. There is an hierarchy among DYNAMIXELs:

    • Sensor and Actuator types of DYNAMIXEL are at the bottom of the “Control Pyramid”, and they can only receive INSTRUCTION packets and send back STATUS packets.

    • Hardware Controller type of DYNAMIXEL (such as the CM and OpenCM series) can send INSTRUCTION packets to Sensors and Actuators and receive back STATUS packets from them.  At present, only 1 Controller DYNAMIXEL is allowed in this network and it has the reserved ID=200.  Normally, a Controller DYNAMIXEL uses the ROBOTIS proprietary Firmware so that it can execute TASK code and MOTION data.  In this configuration, it can additionally send INSTRUCTION packets to the Remote/Smart Device (ID=100) and receive STATUS/RETURN packets from the Remote/Smart Device (for example, this is how a CM-50 CarBot can use a Phone Camera to follow a red line, with the TASK code running on the CM-50 and with the R+m.PLAY700 app running on the Remote Device). 

    • It is also possible for a Controller DYNAMIXEL to receive an INSTRUCTION packet from the Remote Device, but it will immediately and permanently end its TASK functionalities (i.e., the TASK code would be suspended, but not erased from memory, also TASK and MOTION functionalities will be restored after a power reset).  However, at this time, the ROBOTIS proprietary firmware would still be functional on the robot, therefore INSTRUCTION packets sent from the Remote Device should adhere to the protocol (only 2.0 at this time when using the OLLOBOT SDK) governing this particular Controller and also should follow the needed parameter’s type, size and address as published in the Controller’s Control Table.  See this video for an example of this process using the OLLOBOT SDK and an OpenCM-904/C based robot.  This situation also happens when using the SCRATCH 2 IDE on the PC to control a CM-50 based robot via the R+SCRATCH helper app (see this video for a demonstration) – this is why all the Controller Control Tables were published inside the R+SCRATCH folders within the standard “Windows Program Files” folder!  The author believes that the previous approach is also used for the mobile App R+BLOCK (c. 2020)

    • The Remote/Smart Device (ID=100) has the highest hierarchy in this DYNAMIXEL network, thus it can handle all INSTRUCTION and RETURN packets with no handicap.  The R+m.PLAY700 mobile app does not come with source codes so end-users can only learn how to use the SMART functions inside TASK with it (see enclosed PDF).  The OLLOBOT SDK does provide source codes that end-users can modify for their specific needs (these foundation knowledge and programming practice are provided in Chapter 12 of my Springer book).

    • Finally, it is possible to use the OpenCM IDE on the robot’s Controller and the R+m.PLAY700 or OLLOBOT SDK Apps on the Remote Device, but the programmer needs to recognize that the ROBOTIS proprietary firmware would no longer be available, and thus equivalent functionalities would have to be hand coded inside the resulting Arduino Sketch code (see the example INO code for the Mobile Manipulator using the Phone Camera by way of R+m.PLAY700 in Chapter 9 of my Springer book).​   However, this also means that "everything" is under the end-user's control in this configuration.  Since 2017, the OpenCM IDE had been replaced by the Standard ARDUINO IDE and the Dynamixel2Arduino library.

Hardware Controller as Main Controller
Remote Device as Main Controller
Remote Device and Hardware Controller as Co-Controllers

I'm a paragraph. Click here to add your own text and edit me. It's easy.

     In 2021, when I was working on my ENGINEER books, I had found that the ROBOTIS Dynamixel Network Design approach, when combined with the ROBOTIS Remocon Packet protocol, can provide Independent Dynamixel Networks whereas different parts of the same Physical Robot can be controlled by Independent or Collaborative Controllers which can be PCs, or Single Board Computers (such as RPi, Jetson Nano, Arduino), or other ROBOTIS CM Controllers.

     This Independent Dynamixel Network Concept and its applications are described in the following videos:

​

     This article could be rather advanced to some readers, but I hope that at least all readers got a clearer view of the ROBOTIS ecosystem of hardware devices and software tools and became more familiar with the DYNAMIXEL concept and with what ROBOTIS hardware and software systems can or cannot do for their needs.

​

bottom of page