Gumstix FTDI USB driver latency issues

[limor]

we have successfully been using Jon's usb addapter board to connect with a verdex gumstix.
However, the latency using the default FTDI driver is quite high - an order of 20 write-reads / sec.

Has anyone played with the "user mode FTDI interface" ( http://www.intra2net.com/de/produkte/opensource/ftdi/ ) and if so any reported results and example code ?

[Bullit]

Limor, I use this on my Gumstix Verdex and it works excellent. I passed this link along to Jon Hylands just recently as I was faced with latency issues also. I talked with the folks at ftdi and they said to expect 200-300ms latency on their vcp driver. The d2xx driver has low latecy but is not open source so source is not avalable so it can't be built for the gumstix. The ftdilib you cited not only allows very low latency ~2ms it also allows you to reprogram the serial eeprom and to bit bang the other bits on the ftdi chip device. It was also very easy to build in the ftdilib. It uses libusb which is already included in the current gumstix build.

The ftdilib also will automatically unload the existing ftdi vcp driver if installed. I'm very pleased with its performance.

Cheers.

[limor]

Sounds encouraging!

So how many read-writes/sec were you able to achieve ?
any working source code ?
sorry but i don't quite get where the serial eeprom fits in the story and how/where do i use this.

[Bullit]

With comms to dynamixels at 1 mega baud I'm getting 8-10ms round trip for either a ping or get motor position. I haven't put a scope to it yet to figure out why its not faster but it may be the delay in the dynamixels ATMega8. I generally update dynamixel goal position about every 5ms with a sync_write to all 25 dynamixels. Then I only periodically request data from the dynamixels. I think to really test the ftdi latency I'd have to set it up to loop back and I haven't done that yet. I'm more concerned with dynamixel response. In my system I've cranked the jiffies as high as they will go and built the kernel with the CONFIG_PREEMPT=y so I can properly run posix threads and timers in user mode to the limits of jiffy resolution.

Actually I'm not exactly sure what the serial eeprom does. I think it carries the unit id so if your building your own boards you need to program it with the proper codes so ftdilib and ftdi vcp would recognize the device. I've been using dlp design boards with all the basic electronics already on the board. Eventually when I build my own I'll have to tackle that.

As far as source goes, I think the ftdilib site you posted above has some good examples of how to use it. I could prob. post some init code dynamixel comms if you need it. It was pretty easy to replace my ftdi vcp interface with the ftdilib reads and writes.

[limor]

there were reports here on the forum of 70 write-reads per second using the CM5. and i think i get similar or better results in the past.
so the problem is not the atmega8 on the servos.

so i guess i'll have to try out the software usb ftdi library and see if it beats the standard ftdi serial emulation driver.

this CONFIG_PREEMPT is configured where ? (part of the menuconfig ?)

[JonHylands]

I can get 50 cycles per second in Windows XP, doing a WRITE_DATA (and processing the response) followed by a READ_DATA, on a single servo.

That's running through my USB board, using the virtual com port.

The thing might run faster, but its probably constrained by my Smalltalk GUI update rate. I will write a non-GUI version that does the same thing, and see what the timing ends up being...

- Jon

[JonHylands]

Okay, turns out I already had the code written. Doing just straight READ_DATA commands of addresses 36-43, 1000 times, it took between 3.0 and 3.3 seconds each time, which is about 3.3 ms per cycle.

Adding a WRITE_DATA, where I set both speed and position, upped the total time to 6.1 seconds, which is consistent.

So, doing a WRITE followed by a READ on a single servo, I'm getting somewhere a little more than 150 Hz.

- Jon

[JonHylands]

Okay, so I ran my servo tester GUI against BrainBot. Doing a WRITE_DATA followed by a READ_DATA, I'm getting about 45 ms per cycle.

Keep in mind this is timing:
- sending a bioloid command over wifi socket from PC to the gumstix
- gumstix forwards the command to the bus over the FT232
- gumstix gets a response back from the bus
- gumstix forwards the response back to the PC over wifi socket
- PC gets response

So, 45ms is for two commands, so each command is about 23 ms round trip. Both my PC and the gumstix are wireless, and I'm getting about 8 ms ping time between the two, so wireless latency contributes significantly to that.

Discounting the wireless latency, we're probably looking at something closer to 15 ms round trip latency on the gumstix VCP.

I'll make up a test this afternoon that runs on the gumstix, and report here.

- Jon

[Bullit]

Just for grins I went back to my CM-2 and tested the latency there down to a single dx-117. I was able to do a get current position position (both bytes) Tx/Rx in 0.26ms on average. Thats 3894 cycles per second. FTDI states thier best latency with thier d2xx driver is ~2ms so that would correspond to what Jon's getting with windows. I've heard that the windows vcp is more optimized then the linux one.

I switched to the ftdilib because I periodically saw latencies much higher then 8 or 10ms. ftdilib seems at least consistent.

So to your point Limor the dynamixel AtMega8 is not a significant part of the latency issue.

Fortunately I don't need to read back from the dynamixels that often. I do recall occasionaly having problems reading back goal or current position even in the cm-2 when the servo was in motion. It could be that the ATMega 8 is more busy when its actually doing things.

[limor]

Some throughput measurements have been discussed here: http://robosavvy.com/forum/viewtopic.php?t=990&start=45

[Bullit]

I've optimized my Gumstix code using the ftdilib as much as I think I can and I get a solid 8ms latency for any one message. From my measurements and what I read here I'd say we are at the limits of usb latency getting 8ms with this chip. To get lower latency you have to get closer to the metal like the CM-2 or CM-5 as stated above, very low latency.

[JonHylands]

I don't think so - I use the chip from Windows, and get 2-3 ms latency round trip.

One thing we discussed doing to get around this is implement SYNC_READ on an ATmega128, hooked to the gumstix through one UART, and hooked to the bus on the other. So we would send two messages over the FT232 interface per cycle - one SYNC_WRITE, and one (custom) SYNC_READ.

SYNC_READ basically is set up beforehand, and it caches the values received from each device in a special table. When you send a SYNC_READ, it responds with the cached values, and then you have to leave it alone for (x) amount of time so it can poll each device, and update the cache with new values.

- Jon

[limor]

I don't think so - I use the chip from Windows, and get 2-3 ms latency round trip.

One thing we discussed doing to get around this is implement SYNC_READ on an ATmega128, hooked to the gumstix through one UART, and hooked to the bus on the other. So we would send two messages over the FT232 interface per cycle - one SYNC_WRITE, and one (custom) SYNC_READ.

SYNC_READ basically is set up beforehand, and it caches the values received from each device in a special table. When you send a SYNC_READ, it responds with the cached values, and then you have to leave it alone for (x) amount of time so it can poll each device, and update the cache with new values.

- Jon

so you are talking about letting go of the USB interface and using a serial port on the gumstix to communicate with an Atmega128 UART1 at 900kbps while the other Atmega128 UART2 will communicate at 1mbps with the Bioloid bus ?
it would be quite simple to compress the data in a closed-loop control scenario.

[Bullit]

I think 2ms is still a ways from the 260us I measured at the CM-2. Fortunately for me I don't need to read back data from the servos at any greater rate. I'm not sure there's much value in reading back at 260us rate as the AtMega8 may not be updating the values this often anyway and if I was reading from an IMU on the rs485 bus its update rate wouldn't likely be over 100hz anyway. I do know that I see a noticable impact of not updating the goal position at least at 100hz. I've done a number of experiments and measurements that indicate for my purposes that I need to update goal position at 100-200hz. In this case, largely one way traffic, the latency at 8ms isn't a problem. For me thus far I put the IMU on the I2C bus and keep it separate form the sevos.

[JonHylands]

so you are talking about letting go of the USB interface and using a serial port on the gumstix to communicate with an Atmega128 UART1 at 900kbps while the other Atmega128 UART2 will communicate at 1mbps with the Bioloid bus ?
it would be quite simple to compress the data in a closed-loop control scenario.

No, I was planning on keeping the USB chip, and talking to the ATmega128 at 1.0 Mbps (but with both Rx and Tx separate). The ATmega128 can talk all day at 1.0 Mbps with a 16 MHz crystal, because it is an exact baud rate. You need a funky crystal to talk at 921 kbps, and then you can't talk at 1.0 Mbps on the other UART.

- Jon