I am currently running Arduino IDE to program nucleo64 - f446RE board to control dynamixel xm430 over dynamixel shield
Control Environment
windows 11, arduino ide, nucleo64 - f446RE board, dynamixel shield, simple power supply
Software Description
I am simply trying to call #include <DynamixelShield.h> library on arduino ide in the library example code called velocity-mode.ino
My board is nucleo64 - f446RE
Issue Description
when I compile the code, the error is pages long about pin definitions etc. See the attached screenshot
Additional Information/Attachments
I am assuming this is about pin mapping or something like that within the dynamixel library file. Because I can program the board without this library for simple blink example. And I can run the dynamixel library with arduino board. What I cant do is to call dynamixel control library over arduino IDE by using my current board.
And although I do not have a physical board Nucleo64 board, I can confirm that I got the same compile errors list as you got. It turns out that the ROBOTIS Dynamixel2Arduino library uses a parameter named LED_GREEN in their core files actuator.h, actuator.cpp and Dynamixel2Arduino.cpp. Unfortunately the same parameter LED_GREEN is also used in the STM32 core definitions also, but representing something different (see inserted block below):
C:\Users\User1\AppData\Local\Arduino15\packages\STMicroelectronics\hardware\stm32\2.5.0\variants\STM32F4xx\F446R(C-E)T/variant_NUCLEO_F446RE.h:128:33: note: in expansion of macro ‘PA5’
128 | #define LED_GREEN PA5
| ^~~
C:\Users\User1\Documents\Arduino\libraries\Dynamixel2Arduino\src/actuator.h:296:5: note: in expansion of macro ‘LED_GREEN’
296 | LED_GREEN,
| ^~~~~~~~~
So it looks like that these two libraries are currently incompatible with each other. I am letting @Jonathon be aware of this issue. In the mean time, I think that you may have to try a different Arduino Controller compatible with the Dynamixel2Arduino library.
This incompatibility is a known issue regarding Nucleo boards. Resolving this is a difficult issue, as it would involve implementing breaking changes/major rewrites for significant portions of the library.
For now, you can continue to use the library if you undefine the macro in either the board definition or in the DXL library, depending on which one you need access to the least.
