First look at OpenRB-150

Just got an OpenRB-150 for beta tests. I was using the Arduino Core 0.1.0 for OpenRB-150 along with two hot-fixes: and

The OpenRB-150 comes with Serial2 set up with the usual UART 4-pin port (near the DXL-VIN jumper), but the user will have to do some soldering work to put a 1x4 PIN Header Socket (Pitch 2mm) before it is usable. Then a BT-210/410 module can be used there as Serial2.

As far as Arduino programming is concerned, there is no longer the need to specify DXL_DIR_PIN (see Line 28 in the sketch below):

The Dynamixel2Arduino library seems to be working OK for me, so far.

The RC100 Library is also working OK for Serial2.

Here I was using the Virtual Controller RC-100 from TASK 2 Tool to verify that Remocon packets were going from the PC (BT-410 dongle) through the BT-410 receiver (Serial2) and then the Arduino sketch OK.

To test out the I2C port, I was using the ToF sensor VL53L5CX from Pololu. This sensor was working OK with the OpenRB-150.

To test out the SPI port, I was using the Pixy2 camera from Charmed Lab which worked OK also.


Hi @roboteer

Thank you very much for your feedback and reporting the issue so that we can fix the bug.
Much appreciated!

Serial3 is by default hooked up to the old D13 and D14 pins (when a DXL MKR Shield was needed) and it is working fine.

Adding Serial4 and Serial5 is also possible using the SERCOM approach shown at this post, using (D0, D1) and (D2, D3).

So, plenty of COM Ports to talk to other Controllers, PCs and SBCs with the OpenRB-150.

Strange behavior of Ping() with Arduino Core V. 0.2.1 for OpenRB-150
Version 0.2.1 incorporates previous hot fixes but Ping() now behaves strangely.

I have a CarBot using 4 XL-320s and when I used scan_dynamixel.ino to check it out, I had found that if I used the usual Broadcast ID of 254, the OpenRB-150 reported that no dynamixel could be detected:

After further testing, 12 seemed to be the feasible upper limit that I could use so that my 4 XL-320s could be pinged properly:

Fortunately, more consequential methods such as setGoalVelocity() are still working normally.

Using OpenMV H7 Plus camera

To make a long story short, this camera can only work properly with the OpenRB-150 when the 5V Pin out of this board’s header is used to power the camera. First, I thought that it would be more proper to use the 3.3V Pin to do this job, but this usage gave me run-time issues with the Serial Monitor (costed me a whole day of work to figure this out!).

From the picture above, for a successful run, this camera could provide tracking data for a single target for about every 47 ms for an image resolution of 1024x768 pixels.

It got more interesting when I used this camera on a MKR ZERO, and I found out that with the MKR ZERO, I could use either 5V Pin or 3.3V Pin to make the H7 Plus work properly. It will be interesting to see/figure out why, when ROBOTIS releases the schematic for the OpenRB-150 in the near future.

Using HuskyLens Camera

I am using this camera in I2C mode and @willson would be glad to know that the Wire Library is working well now.

So far, I have only tested out Color Detection and at first glance, data throughput for HuskyLens seems to be the best as compared to Pixy2 and H7 Plus cameras.

It looks like that the Time Stamp utility has a “resolution” of 46-47 ms? although data from the HuskyLens came through more often than that.

A4WP-H Project

Previously, this A4WP-H robot had been controlled by an RPi0-2W and an OpenCM-904 - please check out this post:

This time, I used the OpenRB-150 + HuskyLens camera and Arduino instead:

  1. Some of the XL-430s are in Timed Position Control mode so that the robot can be programmed to “walk” via SyncWrite. The ones with “wheels” are of course in Velocity Control mode.


  1. The HuskyLens camera tracks the “red” objects very well (in I2C mode) but this process tended to “suppress” the RC-100 packet flow coming from the UART port, so I practically lost Manual Control when I set this robot to Autonomous Tracking mode.

  2. Importantly, I had found that the OpenRB-150 will not work properly when its Voltage Input is over 11.1~11.2 V. So the standard 12V PS that comes with any ROBOTIS kit will not work for this board (although this 12 V PS had been working fine for me with Open904 and even MKR ZERO and DXL MKR Shield). I had to get a Continuously Variable PS so that I could figure out that it needed around 11.1 V. So hopefully this issue only happens for my particular board. May be other Beta Testers can share in if they encountered the same issue?

Mobile Manipulator Project

The Power Conversion circuitry on my OpenRB-150 continued to break down, I could only use ~10.8 V to power my Mobile Manipulator as shown above. Fortunately, at ~10.8 V, the OpenRB-150 was still able to operate the 12 AX-12s + Pixy2 camera + ToF Imager (8x8 zones) adequately enough.

Update 8/12/2022
Found the source of my voltage/current leaks! My OpenRB-150 is back in operations!


It looks like that the OpenRB-150 is finally available for pre-order for $24.90 at ROBOTIS-USA

Interestingly, the MKR ZERO has also gone down in price too at Amazon for $27.43

1 Like

Dual Controller with HuskyLens

This project uses two OpenRB-150 Controllers:

  • Main Controller operates the Wheels & receives Commands from PC (TASK Output Monitor via BT-210). The Main Controller communicates with the Pan-Tilt Controller (Tx and Rx) via Serial3 (Wired UART). There are two modes of operations: Manual RC via PC and Autonomous Target Tracking. When in Manual RC Mode, the operator can move the Pan-Tilt platform from the PC.

  • Pan-Tilt Controller operates the Pan-Tilt Platform to move the HuskyLens camera. The Pan-Tilt Controller communicates with the Main Controller (Tx and Rx) via Serial3 (Wired UART). It does the Image Processing required for Autonomous Target Tracking. When in Autonomous Target Tracking mode, the Pan-Tilt Controller also controls the Wheels on the Main Controller.


All these projects and more will be described in my forthcoming book by the end of 2022.