serial servo control through labview

[aeroAggie]

Hi everyone,

I'm running an experiment to measure the loads on a wing. Until recently, the wing was actuated by a simple RC motor (see here), but now I want to run the experiment with a Dynamixel AX-12 "smart" servo for finer control and more feedback.  However, I'm not quite sure what the best method is for controlling the Dynamixel AX-12.

The AX-12 uses asynchronous TTL serial to communicate back/forth with a controlling device. I can control the servo with an Arbotix-M microcontroller, and I can program the microcontroller through the Arduino IDE. However, after reading this NI example, it looks like I can control the servo directly through my PC--no microcontroller necessary. I'm guessing the white paper uses this USB dongle, but before I chase serial control through a dongle+low-level serial commands, I wanted to see if NI has more "elegant" solutions to this problem.

Specifically, are there any serial add-ons or toolboxes that I can use with CDAQ devices for high-level smart servo control? Something like Linx for servos. Or do I have to "manually" parse serial commands to transfer data to/from front panel to data packets? 

Thanks

[ahillinaustin]

Hi aeroAggie, 

Thanks for posting in the NI Discussion forums to get an answer with your servo control question! I totally agree that you can control your servo directly through your PC with LabVIEW- no microcontroller required. You could actually contorl up to 254 of them, it looks like. Additionally, it doesn't look like you'll need the USB dongle you referenced. You should be able to connect directly through a COM port in your computer, unless of course you'd prefer to use your USB port for the commumications. 

As far as a more elegant solution to the problem, what functionality are you looking for? I know there isn't a cDAQ module for Serial communications, but there is a cRIO option if that interests you (the cRIO 9870) whic, if you wanted to do closed loop control on your servos, may be a valuable option. 

Otherwise, the example provides the option to queue up multiple commands for multiple Dynamixels. It stands to reason that you could input multiple commands for one Dynamixle and faux-automate the movements of the servos. Or, you could implement some timing mechanism for the larger outer while loop that would send a command to the servo, wait until you are ready to move on, and then send the next command you've queued up.

Let me know if this information helps or if you have any other questions!

[aeroAggie]

Austin,

I apologize for the radio silence, and thank you for the response.

Last week, a friend helped me realize that the $50 "USB2Dynamixel" cable was nothing more than a plain FTDI cable with the RX/TX lines going to/from the USB device connected together*, so I just used bought a FTDI cable from Sparkfun and used that to control my servo. Now I just need to program a "read" function to the VI provided in NI's Dynamixel white paper so I can get "actual" position feedback.

*Detailed explanation for forum posterity: Dynamixel's servos use an asynchronous serial protocol to communicate (read this primer for more info). Essentially, this means that the servos send and receive comm signals on the same line. Therefore, all you have to do to communicate with a servo using a FTDI cable is connect the servo's "signal" port to the FTDI's TX and RX line. That way, your PC will receive Dynamixel's signals on the RX line and the servo will receive PC commands from the TX line.

[ahillinaustin]

Hey aeroAggie,

No worries on the response time. Glad to hear that you have a good hardware solution to the FTDI cabling. As far as the "read" function you're programming, do you feel like you have a good handle on what that would look like, as well as how you might program that with NI VISA commands? Are you still sending bytes serially on the Tx and Rx lines asynchronously?

[aeroAggie]

Austin,

Thanks for the follow up. I didn't have a good handle, but experimentation has led to a better handle, and now I'm very close to solving my problem.

I've created a program (feedback_control.vi) that does 2 things:

1. Send a write command to move the servo +/- 90 degrees from its midpoint (150 degrees)
2. Send a read command to the servo to get its current position

Note, I define "command" as a packet written to the servo using Visa Write.

I've tested part 1 through a couple angles, and it works well. I even deactivated part 2 and ran part 1 inside a while loop, and again I got the response I expected. Ultimately, I want to run feedback_control inside a while loop, so this is good. However, I'm stuck on how to implement serial reading.

In a separate program (50_deg_write_then_read), I successfully wrote a 50 degree command to the servo followed by a read command, but I had to wait 1 second before Visa Read would output the servo's response to the read command. Furthermore, VISA Read's output also included the 50-degree write command, the read command, the servo's status response to the 50-degree write command, and the servo's response to the read command---when I only want the response to the read command. I've pasted the response into a comment in 50_deg_write_then_read.vi, so see that if this sentence didn't make sense.

My questions for you:

1. Can I configure VISA Read to only give me the response of the read command?
   I thought asking VISA to read all of the bytes available at the input port would give me this response, but it does not. Neither does flushing the buffer after the degree-write command (I thought I could just ignore the read command when parsing Visa Read's output). Essentially, my question is: how do I use Visa Read?
2. How can I read faster?
   I have a 1 second delay before I use Visa Read. Anything below this yields zero output from Visa Read. In feedback_control, I ultimately want to run a while loop at 100 Hz (hence the disabled 10 ms delay in feedback_control) that outputs the servo's present position to a chart, so a 1 second delay is unacceptable.

I'd appreciate any and all help. Also, this has morphed into more of Serial-related post, so feel free to move it to that forum (if you have the permission). If not, can I just post a link to this thread in that subforum?

Attached:

1. 50_deg_write_then_read.vi - test vi that sends static commands and reads from the servo
2. angle_to_command.vi ** - subvi necessary for feedback_control* that does a bunch of conversion
3. clear_visa_buffer.vi - nuke vi for debugging
4. feedback_control.vi * - primary vi that sends dynamically calculated commands and reads from the servo
5. hex_int_str_2_hex_str.vi - another subvi necessary for angle_to_command** that converts hex integer strings to hex strings
6. stuff for proj file
7. stuff for proj file
8. stuff for proj file

Edit: In case you need it, here is the servo's manual.

• Control table for the registers is on page 12/13 of the document/PDF
• Example instruction packets are on page 19/20
• Servo uses half-duplex UART with a 160 microsecond delay between instruction packet reception and status packet send-off (page 30/31).

[ahillinaustin]

Hey aeroAggie,

At first glance, I'm thinking this may be an issue of the status packets being read along with the actual data you're looking for. On page 19/20 of the manual, it describes the write functionality, and then says, "Because it was transmitted with a Broadcast ID (0XFE), no status packets are returned." I think because you're writing to ID 1 (presumably your first drive) each write command returns a status packet, along with the read command with a status packet. This is why you see all 3 commands coming back when you read every byte at port. Try either implementing a read after every write (to read the statuses of each write), or sending everything via broadcast ID. 

As far as the timing you're seeing, there's nothing apparant to me that would slow down your communications. I would recommend using NI IO Trace to record what data is being sent serially and observing the timestamps to see how fast LabVIEW and your device are sending data across the serial port (see http://digital.ni.com/public.nsf/allkb/282C5D41E2BA04F2862574BA007803B9)

Because this still relates directly to your servo control, we can leave it in the Motion board for now 🙂

Try these two suggestions out and see if that helps!