Control Servo (XL320) with Raspberry Pi

Projects and Learning
1

Hi,
I’ve been working on a project for a while now where I would like to have more control over the Robotis Mini robot.

My plan is to control the XL320 servo’s using a Raspberry Pi.
I have tried using the OpenCM9.04 as a bridge between the pi and the servos but is was not really a streamlined solution.
The easiest way would be to buy a U2D2 and the power hub board but it’s more expensive and takes a lot of space.

I have all necessary hardware to control the half duplex servos using a full duplex serial connection of the Pi (using a driver buffer IC 74LS241 as shown here Arduino Dynamixel Library – Savage Electronics Blog and a level shifter for the 3.3v logic of the Pi).

My question: Is there a way in the Dynamixel SDK to configure the data direction pin? To make the setup work with the IC, I need to be able to control the direction the data is going to and from the servos. While I have a vague memory of seeing this functionality somewhere, I don’t remember if it was in the Dynamixel SDK (if been working slowly on this project over the pas 2 years…).

I hope someone can help me further with this.

Kind regards,
Benoît

1 Like
2

Sorry I know this is something that someone from Robotis should answer and maybe they have in a different place, like the Robotis Forum…

I have not played around with the having Linux try to directly control the servos for a long time (years) and have not done much with Dynamixels for awhile as well.

But if it was me, here are a few thoughts:

a) When I was doing stuff with SBC boards, like RPI or Up, or Odroid, I typically used some form of Microcontroller to drive the servos. Often times I did stuff with Teensy boards (PJRC), other times I used a product like USB2AX(Xevel), now days more like U2D2…

But for quick and dirty things, I would probably just use an OpenCM board…

b) If I wanted to control this directly with DynamixelSDK and run off of the RPI, I believe it would requires some changes to the SDK Sources. That is you would probably need to update the source file: port)handler_linux.cpp to include some of the stuff like is in port_handler_arduino.cpp

That is in the areas like:

int PortHandlerLinux::readPort(uint8_t *packet, int length)
{
  return read(socket_fd_, packet, length);
}

int PortHandlerLinux::writePort(uint8_t *packet, int length)
{
  return write(socket_fd_, packet, length);
}

If you look at the Arduino version of WritePort:

int PortHandlerArduino::writePort(uint8_t *packet, int length)
{
  int length_written;

  setTxEnable();

#if defined(__OPENCR__)
  length_written = DYNAMIXEL_SERIAL.write(packet, length);
#elif defined(__OPENCM904__)
  length_written = p_dxl_serial->write(packet, length);
#endif

  setTxDisable();

  return length_written;
}

So they have two function to enable/disable TX… Which in the Arduino on OpenCM and OpenCR boards is setup to set/clear the Write Enable IO pin… You need to add that type code.

Question is then how to do that on RPI… There are libraries that allow you to set/clear IO pins. A long time ago I was doing some of that using the WiringPi library… Not sure if that still is the best library for this now or not.

Again I have not played with that in a long time, so maybe there are other approaches to this, that others will suggest.

Good luck

2 Likes
3

Hi @Benoit_Lagasse

As Kurt mentioned in the above reply, in order to implement the data direction pin, the best way would be modifying the readPort and writePort for your system.

Some time early this year, we had a closed beta test for Raspberry Pi Hat for DYNAMIXEL and not sure if our marketing team still have some samples in their stock.
The hat didn’t require a direction control, so simply creating the portHandler using an assigned serial port was good enough.
You may contact at contactus2@robotis.com and ask for the availability of RPi Hat sample.

Thank you.

2 Likes
4

@ROBOTIS-Will was there any software or schematics published for this board? I’d be very interested to have a look

1 Like
5

@rosterloh

I don’t think there is any public data for the closed beta sample.
But the sample PCB required the DYNAMIXEL SDK just like when running DYNAMIXEL example via U2D2(Youtube Video), but with a different serial port such as /dev/ttyAMA0 instead of /dev/ttyUSB0
You may also contact ROBOTIS US branch at cs@robotis.com for any remaining samples.

If I may, can I ask what you are developing with Raspberry Pi and DYNAMIXEL?
I’m curious about how developers interface DYNAMIXEL to their Raspberry Pi.

1 Like
6

Hi @ROBOTIS-Will

I tried sending a request to the contactus2 address as you recommended before but have not received a response yet so I’ve forwarded my mail to the cs address now too.

The product I am building is a remote phenotyping platform for the AgriTech space. Do you know if the Dynamixel hat just has a SAMD21 on the PCB with your firmware on it or is actually using the Pi’s serial port (ttyAMA0) to communicate with the Dynamixels?

7

Hi @rosterloh

I’m sorry about the delayed response from the HQ.
I think they are trying to find any available samples in their hands, but when the dev team told me that all the samples were shipped out during the beta test.
Your request is being discussed in the other cs@robotis email thread and we’ll get back to you soon.
I think further discussion can be followed in the email thread as we could provide more direct support for you.

The DYNAMIXEL RPi Hat is designed to use the RPi’s serial port in order to minimize the delay in communication and reduce the complexity of the hardware.

8

Thank you @ROBOTIS-Will. I’m busy laying out a PCB for this project as we speak so I’d love to just put down the components myself if I could get a schematic.

9

FWIW - a several years ago I played around some of my own RPI (or ODroid) hats, that controlled Dynamixel servos. Note at the time I was doing everything with AX12 servos.

I used a Micro-controller to drive this. In my case Teensy processors, first one I experimented with was using a Teensy 3.2 But could be most different processors. For me preferably one with at least two hardware Serial ports. One to talk to the RPI and one to talk to servos. I believe my first ones simply used the direct output of the Teensy 3.2 which has 3.2v signals to drive the servos. Later I added in some level shifter circuitry. On the RPI side again since Teensy boards output and input at 3.2v can connect directly to the RPI Serial TX/RX pins. If you use a 5v processor than probably need to level shift down…

Again this part was not overly complicated. My problem is I usually built the kitchen sink.
Like: here is sort of 3d look at one for 3.2:
image

Again I just play around for my own fun, so usually my boards have issues, which I never worry about fully fixing… I just go on and play with the next one, but to give you an idea of what some of the stuff is on this board:
image

It has the T3.2 connected up to the RPI. I made the connections to the RPI TX/RX pins optional by a usign breakout pins and connect with jumpers(Shunts)., which simply connect it up to one of the T3.2 UARTS…

On The DXL side, I use another UART, decided to level shift, so I use two chips near the right hand side of schematic to level shift both RX/TX pins, and I use an IO pin to set the direction. With some other setups, I could simply use a BSS138 and 2 resistor like level shifter used in Adafruit/Sparfun boards setup, connected up to the teensy TX pin of a Uart and configure for half duplex… Can go into more details if desired, but more specific to Teensy.

Also controlling the servos, this board allows me to turn on/off the power going to the servos. This was based off of the then Trossen Robotics Arbotix Pro which was based off of Robotis OpenCM 530?. Board also has plug in to supply the voltage tot he servos, and DC/DC converter to convert the Lipo 3S power down to 5v…

Other side note: At the time I am not sure how much the using the RPI RX/TX pins helped with throughput. This was in the time that RPI3 just came out, and if I remember correctly RPI only really had one hardware UART, that by default was used by Bluetooth, so the UART for RX/TX pins was sort of emulated? Again been awhile. So often times I would use the board conneted to RPI also through USB, and use the USB connection instead of those two IO pins.

To make this easier to switch either way, I had my software not talk directly to ttyACM0 or the ttyAMA0 devices, instead it would first look for ttyDXL object, which I setup typically using UDEV rules. After that the code for the most part did not care how connected. One exception was if it rerouted to a ttyUSBx port which implies FTDI, to minimize delays, the code called tcdrain, which logically on the Arduino something like Serial.flush()… In the Linux code a call to tcdrain. Which helps a lot with minimizing delays. But needed to be careful as calling tcdrain on other board types like ttyACM0 inserted long delays…

Again not sure if the above helps or not, but thought I would mention some of this stuff on the off chance it might.

2 Likes
10

@Benoit_Lagasse
Have you seen this recent post from another Robotis Community

11

yes I did, I’m going to try this out this weekend, thanks!