First Look at Arduino UNO R4 and Dynamixel2Arduino

roboteer · April 2, 2024, 9:16pm

Arduino released UNO R4 back in July 2023, and I got interested in it, because finally the UNO R4 has a separate hardware UART for Serial Monitor (now as Serial()) and another hardware UART for DXL Control (now as Serial1() still via D0 and D1). So in theory it should be compatible with the DXL Shield (which was designed for UNO R3 and earlier).

I got my UNO R4 WiFi yesterday and I just got through my first tests with it and some 2XL-430 (see my setup below).

I got COMPILE errors due to Variable Naming conflicts between the RENESAS Library and the Dynamixel2Arduino library regarding Control Items LED_RED, LED_BLUE, and LED_GREEN - which were easily fixed as LED-REDD, LED_BLUEE, and LED_D_GREENN.
Next test with simple Position Control using position_mode.ino modified for UNO R4, i.e.

#include <Dynamixel2Arduino.h>

#define DXL_SERIAL Serial1  // for UNO R4 Wifi
#define DEBUG_SERIAL Serial
const int DXL_DIR_PIN = 2; // DYNAMIXEL Shield DIR PIN
 
const uint8_t DXL_ID = 1;
const float DXL_PROTOCOL_VERSION = 2.0;

Dynamixel2Arduino dxl(DXL_SERIAL, DXL_DIR_PIN);

It compiled and downloaded OK, but no response from the ID=1 servo at all at run time:

Next I tried Velocity Control mode with velocity_mode.ino. Compiled and downloaded OK. But still no response at run time

imagstrong texte

Lastly, I tried my favorite test using SyncWriteRead to 4 DXLs, 2 set up in Position Control and 2 set up in Velocity Control. And unexpectedly, it “kind of” worked: all 4 DXLs seemed to be doing their “randomized” motions during run time (but their motions were not as “crisp” as if I were using an OpenRB-150). Present Positions were coming in “slower” (as compared to OpenRB-150), and very strangely NO PRESENT VELOCITY packets were received!

This is a video clip of the SyncWriteRead test:

In conclusion, Serial() and Serial1() do work independently on the UNO R4 Wifi, but some updating, hardware and software wise, are still needed from ROBOTIS, so I would not recommend folks to rush out and buy the UNO R4 right now, if your main objective is to use DXLs.

roboteer · April 4, 2024, 3:00am

UPDATE 4/3/2024

I picked up an UNO R4 Minima today and ran it through the previous tests as for the WiFi, and the results were same as I reported in the previous post.

roboteer · April 5, 2024, 3:34am

UPDATE 4/4/2024

Just found this report on ROBOTIS GITHUB since July 2023

github.com/ROBOTIS-GIT/Dynamixel2Arduino

UNO R4 - Library(libraries) - will not build on new Arduino boards... And may not work at all.

opened 12:38PM - 24 Jul 23 UTC

KurtE

Recently I started playing with the new Arduino UNO R4 boards (MINIMA and WIFI) …- and yesterday I thought I would try it So I pulled out my Dynamixel Servo Shield and plugged it into the Minima. I made sure my libraries were up to date. Loaded the scan_dynamixel.ino example sketch and tried to compile it which failed. More details in the forum thread: https://forum.arduino.cc/t/robotis-dynamixel-shield-code-does-not-compile/1150975 Found the issue was that Arduino defined: LED_RED and LED_BLUE ``` C:\Users\kurte\AppData\Local\Arduino15\packages\arduino\hardware\renesas_uno\1.0.2\variants\MINIMA\includes\ra_cfg\fsp_cfg\bsp\bsp_pin_cfg.h: 10 #define A1 (BSP_IO_PORT_00_PIN_01) 11 #define A2 (BSP_IO_PORT_00_PIN_02) 12: #define LED_RED (BSP_IO_PORT_00_PIN_11) 13 #define TX_LED (BSP_IO_PORT_00_PIN_12) 14 #define LED_BLUE (BSP_IO_PORT_00_PIN_13) C:\Users\kurte\AppData\Local\Arduino15\packages\arduino\hardware\renesas_uno\1.0.2\variants\UNOWIFIR4\includes\ra_cfg\fsp_cfg\bsp\bsp_pin_cfg.h: 10 #define A1 (BSP_IO_PORT_00_PIN_01) 11 #define A2 (BSP_IO_PORT_00_PIN_02) 12: #define LED_RED (BSP_IO_PORT_00_PIN_11) 13 #define TX_LED (BSP_IO_PORT_00_PIN_12) 14 #define LED_BLUE (BSP_IO_PORT_00_PIN_13) 2 matches across 2 files ``` Which completely screws up anyone else who use these words in any way, including yours which should be safe, as yours are contained in an enum, which is in a namespace, which is nice and clean. I created an issue yesterday: https://github.com/arduino/ArduinoCore-renesas/issues/64 Which they blew off and closed it with the response: `I suggest you open an issue with the Dynamixel library, we are likely going to keep those defines.` So here it is. Not sure how many libraries, documents, examples, and the like this might impact. Nor if there are any other now new magic words, which may show up with additional testing. Edit: If it were me, my fix for this would be to add something like this in your header file: ``` #ifdef LED_RED #undef LED_RED #undef LED_BLUE #endif ``` Note: currently even if you "fix" this, their serial subsystem has lots of issues, including Serial1.flush() does not work, and as such the direction pin will change state before it should, and the packets are corrupted. For example I had 18 servos and it only found 5... Some of this could be wiring connection issues, but mostly issues with their subsystems. I have experimented with some updates to their serial code base (https://github.com/arduino/ArduinoCore-renesas/pull/59), but this has not gained any traction, so not expecting that any of these issues will be fixed anytime soon.

So it looks like that ROBOTIS is aware of this issue, but nobody is working on it!

@willson It looks like that there is an issue with the timing of the switching for TX & RX when sending/receiving DXL packets. Because SyncWriteRead did work sometimes, but regular setGoalPosition(0 and getPresentPosition() don’t work. Can you suggest the “coding areas” where I can try to adjust?