Month: January 2017

It was not easy but I can finally compile and download sketches to the board! To do that I use a modified version of this python script https://github.com/tician/opencm-1.5/blob/master/hardware/tools/opencm.py. The reason I can’t download sketches using the openCM IDE is that the replies from the board during the download process are corrupted. For each command sent by the PC over the USB the board replies with a corresponding response. For example, at the beginning of the download of a new sketch the PC sends “AT” and expects to receive “OK”. However, using the python script and some tests on ipython I figured out that the board is not responding correctly. For “AT” is replies “-\nOK\r\n-“, with randomly missing characters. What is the reason? Some guys from the trossen forum guess that it is a faulty bootloader on the board. The bootloader is like the operating system of the board, and it seems that it cannot be written with the PC over the USB (needs to write on special memory region) but with an special hardware. I am not sure, it could also be some problem of the USB connection.

Anyway, I can now compile sketches using the OpenCM IDE and send the generated .bin file using the modified python (I will upload it soon to github).

Next, write a sketch to read commands from the PC and send the state of the motors back.

Once I could connect my USB to the mini USB of the OpenCM board I wanted to try my first program on the Arduino-like board. I installed the OpenCM library for Linux and took one of the included examples, compiled it and tried to download it to the board (download means copying from the PC to the board). ERROR! The download failed. Good start!

I searched for information and I found that you can force the download by pressing a tiny button on the controller when connecting the USB to the PC. I did so, a LED stayed green as it should, I tried to download and… ERROR again!

Then I decided to just check the other functions to see if the “rest” was working. I connected with the app and tried to move the robot, but it was not reacting. So now I have a 300€ brick, great…

No other solution that to switch to windows. On windows I expect to have more luck because I can use 3 pieces of software from Robotis that are not available for Linux: R+ Motion, R+ Task (to program motions and sequence of motions, called tasks) and RPlus. First, I tried to download a program using the OpenCM library on windows. Again, error. Then I tried to connect R+ motion or task to the robot: again error. It seems to be a problem of the USB communication.

Ok, let’s clean the mess. Next step: reset the board to its initial state using RPlus. But to reset the board I need to connect with the USB, and this seems to not work… Finally, I could reset the board using RPlus by using a different USB port on my computer. I repeated and tested different configurations, to be sure: it looks like only one USB works, and not always.

Finally, and just to be sure I still have the cool demo moves, I reinstalled the original motions that come with the robot. When resetting the board they had got deleted. I downloaded the motion file and wanted to send it with R+ motion, but the connection was impossible. I need to connect over the bluetooth.

The bluetooth connection was not working because I needed to change the settings of the bluetooth service so that new devices could be added. Once I figure out that, adding the device and connecting to it was easy. Then, loading the old moves was also easy. Now, everything is like at the beginning.

From now on, I know what to do if I program the OpenCM board and I want to go back to the initial state: go to windows, plug the board to the first USB (closest to the screen) while pressing the button on the board, reset to initial state using RPlus, connect via bluetooth with R+ motion and load the old motion file.

Next time, first steps on an on-board program to read commands from the USB, send them to the motors and output motor information over the USB.

The first thing I did was to play around with the Android app. Yes, I know it’s lame to play like a kid at my age but it was a lot of fun watching the robot dancing and falling down so many times…

The next thing was to sit down and think if the current hardware (the “CPU”) is enough for what I want to do, even if I don’t have yet a very clear idea of what I want to do. The options are:

1. Replace the OpenCM controller by something more powerful and generic. Here the best options are:
   1. Arduino
   2. BeagleBone (I have some experience because we use it in my lab to control the air flow to the soft hands we build)
   3. Raspberry PI
2. Keep working with the OpenCM, even if it is so limited in terms of computational power and memory space.

While digging into the code examples for the OpenCM I found a piece of code that allows to send commands and receive feedback from the USB connector of the board. Voilá! I made a decision! I will keep for now the OpenCM, program it to receive commands and send feedback over the USB and use my computer to carry the heavy load. In this way I could even mount on the robot a “real” camera (the color sensor that is available for the robot is rather a joke) and connect it to my computer, too. Another reason to keep the OpenCM is that the other options would imply to get to know how to program and control the motors using a different board, which is not what I want to focus on.

Once I decided on this, my next step was to connect with the OpenCM board using a mini USB. To do that I needed to cut a hole on the front part of the robot torso because the mini USB connector is hidden there.

In the next post I will report on the first steps programming Kuroki.