Using RPi5 with ROBOTIS systems and GStreamer+OpenCV

I got my RPi5 4 GB yesterday and had been checking it out. I’ll be using this post to document my progress with interfacing the RPi5 to ROBOTIS hardware and software:

  1. Powering: The RPi5 has a so-called ON/OFF button which can be used to shutdown the board, but Power is still maintained at the USB-C connector. Surprisingly, those USB-C cables with Power Switch (that I had been using for my RPi4Bs) did not work with the new 27 W RPi Power Supply. So, at present, I am using this type of outlet switch for the RPi5 to help preserve the integrity of the USB-C connector for long-term usage.

  2. This link was a good starting point for me: Raspberry Pi Documentation - Computers

  3. I used the RPi Imager software V.1.8.1 to prepare my SD OS card which had a new OS customization feature:


which I used to pre-configure the Username and Password, my home wireless LAN Password, enable SSH service, etc… It worked very well.

  1. The SD booted the RPi5 into the Desktop at first trial.

  2. Next, I set up the VNC Server for potential Headless Remote Access from my Windows 11 PC using this link

Raspberry Pi Documentation - Remote access.

This site recommended to use TigerVNC Viewer on the PC side, but I had found that RealVNC Viewer worked as well. For my eyes, the text character rendering is slightly better with RealVNC Viewer.


I did not have to use the HDMI Virtual Display dongle anymore, like I did for the RPi4B.

Unfortunately, this VNC Server does not offer (at least not yet) an FTP feature, so I’ll be using either USB drive or Secure Copy
(Raspberry Pi Documentation - Remote access) to get my C++ codes between my PC and RPi5.

  1. I also have another favorite Remote Access tool which is NoMachine but they are not finished with their work porting their tool to the RPi5 yet, see this link

  2. The RPi5 comes with THONNY for Python Programming but I had found that I could not install the Dynamixel SDK 3.7.31 (currently offered at


  1. No luck with OpenCV-Python either:


So I will try Visual Studio Code and Python 3 next to work with DXL SDK and OpenCV-Python.

  1. The various Serial Communications modules from ROBOTIS were recognized as ttyUSBx devices (via dmesg): USB2Dynamixel, LN-101, BT-410 USB Dongle, U2D2. The “2021-experimental” RPi DXL-HAT was mapped to ttyS0/Serial0.


  1. Code::Blocks installed OK.


So my next post will be about C++ Programming with Code::Blocks and Dynamixel SDK and ZigBee SDK.


Today’s test setup is shown below:


Essentially RPi5 is hooked up to U2D2 via ttyUSB0. the 2 2XL-430s are hooked up to U2D2 via the Power Hub board at 12 V.

I installed the latest DXL SDK for C and C++ via the steps described in this “revised” post:

The RPi5 OS is new, so you can skip the steps regarding installing git, gcc, and build-essentials. The remaining steps applied OK, except:

  • Remember to add the flag -fcommon to the MakeFile as needed as shown in the previously mentioned post.

  • I also took care of preparing for ttyUSB0 to work with only 1 ms Latency Timer Delay.

For Code::Blocks, I used the old Project files created for my Amazon book on the Engineer systems:

And fortunately only a small change was needed to update the paths to various source codes and libraries because the user does not have to use the default pi username anymore with RPi5.

And so far the current DXL SDK worked real well with the RPi5 in C and C++ - see screen capture below for a test on SyncReadWrite. Compiling and run-time performances are much better as compared to RPi4B.


In conclusion, it was definitely worthwhile for me to upgrade to RPi5.

On the next post, I plan to report on how well Python works with the DXL SDK on RPi5.


I installed the latest DXL SDK for Python as per this post

And this process went fine for the RPi5.

After adjusting for 1 ms for the USB Latency Timer, and adjusting the pyserial functions to use 1 Mbps, I had tried on the Terminal and inside Visual Studio Code and this code worked fine for both situations with occasional loss of packet status (this issue did not happen when using compiled C/C++ code).

One strange thing with using THONNY though. Although it recognized that the DXL SDK had been installed:


It found issues with termios?


While the Python3 interpreter had no problem executing by itself or via Visual Studio Code.

My next project was to check that my OpenCV codes for RPi4 in my previous books for the Engineer system would still be working in RPi5 with BOOKWORM OS and LIBCAMERA libraries.

Not too surprisingly, the OS backend to OpenCV changed quite a bit. So using an integer for camera ID no longer works - for example

	int cam_id = 0;  // first camera from OS backend
	VideoCapture vid_cam(cam_id);

The user now has to prepare a GStreamer pipeline, and the software chain is quite complicated - more details are listed in the RPi Forum at

If you are familiar with this process already, I am enclosing the pertinent screenshots

Preparation of the “pipeline” string


Start Video Capture instance


Then the rest of the code is pretty standard OpenCV codes as shown in the examples of my Engineer books.


BTW, in case you have not noticed, using PiCamera V2 with RPi5 allowed the user to capture 640x480 pixels at 200 fps, and 1536x864 pixels at 120 fps on the PiCamera V3.

Some more screenshots




In case you wondered what if both cameras were activated at the same time? I have tried that option, and both cameras would work for a few seconds, then this program would freeze up :frowning_face:



In case that the user needs to stay with an RPi4B, I can confirm that the same “long” procedure will work for an RPi4B on Bookworm OS. But because of the lower hardware performance of the RPi4B vs the RPi5, I had to simplify the pipeline used.


But ones can still get 200 fps out of a PiCamera V2



These procedures worked out in a similar way on a RPi0-2W, but a much slower rate due the limited memory and computing power of the RPi0-2W. So with a PiCamera V2, the highest frame rate is 100 fps at 640x480 (vs 200 fps on the RPi5).


While the PiCam V3 can be set to 1536x864 and 120 fps, but the actual performance was really much less.