Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 23

Thread: Interest in a powerful, small size USB to Dynamixel ?

  1. Re: Interest in a powerful, small size USB to Dynamixel ?

    Here are some files to test latency : usb2ax_latency_test.zip
    You need Python 2.x (I use 2.7) and PySerial.
    Modify latency_test.py to set your serial port name and the ID of the servo it will ping. The servo is supposed to be communicating at 1Mbaud, but you can change that too if needed, in the same file.

    On my Windows 7 64 bits box I get these results (time in seconds, 10 samples) :

    Code:
    0.00100016593933
    0.000999927520752
    0.00100016593933
    0.000999927520752
    0.000999927520752
    0.000999927520752
    0.000999927520752
    0.000999927520752
    0.000999927520752
    0.000999927520752
    servo ID: 17
        mean 0.000999975204468
        max  0.00100016593933
    Sometimes it will show 0.0s for a sample, and that must be why I thought at some point that the latency could be less than 1ms (at the time I only showed the mean time). I have to track this error, but it most likely comes from my python code written during one of many febrile sleepless nights.

    Also, unfortunately I don't have my Xachi at hand, and no other Linux board or box in working condition to provide any worthy data for Linux right now. But one thing my experimentation have been consistent about: on a standard Ubuntu, the latency will be much higher than that.

    I would be very grateful if you could test it and help me find a solution to decrease said latency without resorting to a real-time kernel.

    And by the way, if you may ask: my experience with set_serial is that it does not recognize this virtual serial port as a serial port, and consequently does not allow the use of the low_latency setting.
    ---
    Personal blog: http://xevel.org
    USB2AX documentation: http://xevelabs.com

  2. Re: Interest in a powerful, small size USB to Dynamixel ?

    I just tested the same script on Xachi (Beagleboard-xM runnning @800MHz, Ubuntu ARM 10.10 headless, Linux omap 2.6.39.1-x2, Python 2.6.6, Pyserial 2.3-1)... and it does not look like what I remembered at all.

    With the code previously posted:
    Code:
    0.00207495689392
    0.00192284584045
    0.00216698646545
    0.0018618106842
    0.0019838809967
    0.00338697433472
    0.0021059513092
    0.00204491615295
    0.00216698646545
    0.00213599205017
    servo ID: 23
            mean 0.00218513011932
            max  0.00338697433472
    What has changed between my first tests where I had >7ms latency and now
    - upgraded kernel from 2.6.37-x2 to 2.6.39-x2
    - updated PySerial, but I don't remember the previous version
    - but mostly, my python code was written in an extremely inefficient way I learned. Now it's just intermediately inefficient. With a little modification I got to 1.5ms, and I guess the last 0.5ms could also be shaved off to get to the theoretical minimum of 1ms.



    So as I understand it, the minimum round trip delay at application level is 1 USB frame (1ms), non negotiable.
    ---
    Personal blog: http://xevel.org
    USB2AX documentation: http://xevelabs.com

  3. #13

    Re: Interest in a powerful, small size USB to Dynamixel ?

    Here is what I have found so far:

    First worked on Windows 7 ( i7 desktop, Windows 7 64 bit). Using Python 2.7.2.

    Servo baud is 1000000, servo return delay = 0, servo ID = 1

    The USB2AX code is running on a Minimus AVR USB 32. Also using standard USB2Dynamixel(latency = 1) as reference.

    When I first started using your python code I got results similar to yours, but was concerned about the zero values. Clearly two sequential calls to time.time() should not return the same value. It does appear that the updating of the value returned by time.time is only about every millisecond, this gives the zero values and the apparent 1ms quantisation. I don't know a fix for this, so I changed the latancy test to loop 1000 times and measured the time for the entire loop. This gave more consistent results though it would still be useful to have individual values to see if any quantisation still exists, and also to know the maximum value.

    With the updated python code, I consistently got values of between 700 and 750 microseconds for the python loop of the ping. From the USB analyser I see the time from the start of the OUT transfer to the end of the IN transfer, to be between 500 and 600 microseconds depending on whether the returned data is split over two packets. The IN endpoint is being polled around every 20 microseconds.

    I did try two alternative forwarding schemes in the USB2AX to see if any significant improvement was made. The first was to ensure all packets were full and starts a 64 us timer on the first character received and resets timer on each received char, sending when timer expires. This did result in full packets, but did not significantly improve latency. The second was just to send any characters available without waiting. This gave more smaller packets but again did not substancially change latency. I thought smaller packet may be worse for the OS to handle, but they actually may be better since the parse routine then gains some parallel action to the serial reception.

    Overall I would say that the 700-750 microsecond performance on the PC is very good. A lower spec. PC and heavier load will obviously make a difference.

    The USB2Dynamixel by comparision gave results in the range 1000 to 1500 microseconds, most likely due to the 1ms latency setting.

    I also tested with a C# program using the Dynamixel library from Scott Ferguson and got similar results.

    Have now moved over to Linux notebook (Pentium 4 1.8GHz) Ubuntu 11.04 Kernel 2.6.38-11. Python 2.7.1

    Testing the USB2AX I do get about 3 timeouts per 1000 pings and an average response of 4 milliseconds. With the USB2Dynamixel, no timeouts, but also around 4 milliseconds. USB analyser shows the USB transaction being as fast under Linux as Windows, so all the rest is in linux kernel, drivers, or application. The timeout appears to be caused by linux, the USB2AX responded correctly within 500 us, but the next ping was not until 200 millisec later.

    I will investigate further and can test your new Python code if you like.
    Last edited by iBot; 09-03-2011 at 06:37 AM.

  4. Re: Interest in a powerful, small size USB to Dynamixel ?

    Very interesting, thanks!

    On the resolution of time.time(): from http://mail.python.org/pipermail/pyt...y/1121263.html
    Under windows time() counts in 1ms steps wheras it usually counts in 1us steps under linux.
    This explains that. Thanks for pointing it out.
    Even though it has better accuracy, using time.clock() is not really an alternative to time.time() since it does not count the actual time passed between two event, only the processing time. So I guess your fix is as good as it gets on windows.
    Also, I don't intend to pursue the use of my python Dynamixel library, so I don't think we need to bother optimizing it now.



    On the alternative forwarding schemes: while it does not seem to provide any interesting optimization in this particular case where only a handful of bytes are sent back, maybe the question of having better forwarding schemes will resurface with the improvements I have in mind for the firmware.



    The problem I want to solve is as follows: I have 19 dynamixel servos I want to send positions to, and get back their actual position. How fast can this be done without touching the firmware of the servos (so this rules out the alternative firmware made by the guys at Actuatedcharacter and the work of RicardoMarinheiro) and without changing the dynamixel protocol?


    Sending many positions at once is not hard: sync_write, or alternatively write all the positions one by one with the return level set to "reply only on read".

    But currently, to get data back, the control software running on the PC has to send a command, and wait for the answer before sending anything else. If properly multithreaded, the delay can be put to profit for other calculations by the CPU, but if you look at it from the point of view of the Dynamixel bus, it's very inefficient. Only 1 command passes on the bus every once in a while, when many more could have been sent and answered.

    The first improvement that we can imagine (and that I used in my Xachi) is to send a command, wait a little, send another one, wait a little... until you have sent all the commands you wanted, and then only start reading the answers, which have piled up in a receive buffer somewhere in the low layers of the your OS. The "wait a little" part is crucial: it lets time to the servo to answer. Hence, the total delay (time.sleep() + all the delay induced by the various layers of communication) has to be at least as long as the time needed for the Dynamixel device to answer.
    This allowed me to make some significant improvements to the overall latency I experienced in the beginning (which I still don't know exactly WHY it disappeared ><), yet it is still not the fastest that can be done, and creates conflicts sometimes when unplanned latency arises at any step of the communication. Overall, a dirty trick.

    What I think would be the best thing possible without changing the protocol (meaning I don't allow the computer to send command intended to be interpreted by the controller) would be to implement a form of message queue in the controller.
    The USB2AX would receive bytes and parse the messages succinctly, just enough to know two things: the boundaries of each command, and maybe the type of command. it would then be able to make a queue of commands that need sending, and would process them one by one. Knowing the type of command would be used to determine if an answer is awaited.
    This poses a few potential problems, to which I propose the following answers:

    • Servos can be configured to answer every command, only the read and ping, or only the ping (Status Return Level)
      • We could expect all the servos to be configured the same, in a predefined way possibly tweakable in the firmware source code.
      • if having all servos configured the same is not a satisfying option, we can imagine the controller keeping a (possibly dynamic) record of the servos it knows are on the line, and the first time it talks to them would ask them their verbose level. In addition, the controller would monitor any write command to the corresponding registry and update the information in its internal database too. But it's a little too complex and maybe could have side effects...

    • Servos can be configured to wait a little before answering.
      • Just remove this damned delay already ><

    • What happens if a servo does not answer?
      • Standard timeout.


    My current feeling is that the overhead would be more than offset by the improvements made by having the controller pass to the next command immediately after the previous one has been answered. Plus their shouldn't be any risk of bus contention.


    The next upgrade would be to have the controller be a Dynamixel device too. I only glanced at it, but isn't it how the CM-730 works?
    This way, we could simply configure the details of communication.
    We could also have a simple means to run the bootloader, allowing easy upgrade of the firmware without the need to press small and scarily costly buttons. I'll try to get back on the problem of flashing the firmware in a post to come, it has physical implications I would like to discuss.

    An alternative would be to have a second endoint (another COM port?) for configuration, but having two com ports would be confusing.


    So, what do you think would be the features of an adequate firmware for the retail version of the USB2AX?
    - simple virtual com port?
    - version with queued messages?
    - no way to manage the controller itself?
    - addressable as a dynamixel device?

    I think the version with queued messages and a dynamixel device has the best potential. By default, the queued command system would not be active, and you could configure it by changing a few registries just like any other dynamixel device.

    I'm interested in whatever you may think of it!
    Last edited by Xevel; 09-04-2011 at 02:17 PM.
    ---
    Personal blog: http://xevel.org
    USB2AX documentation: http://xevelabs.com

  5. Re: Interest in a powerful, small size USB to Dynamixel ?

    Just an update to the latency test. Please replace this file in the previous archive (for Linux only since it relies on time.time): serial_dynamixel.zip
    ---
    Personal blog: http://xevel.org
    USB2AX documentation: http://xevelabs.com

  6. #16

    Re: Interest in a powerful, small size USB to Dynamixel ?

    Sorry for the dlay to reply.

    I tried the new test, but still have latency around 4 ms under Linux on my aold laptop, compared to less than 1ms under WIndows. I need to try some other Linux devices and kernels.


    On the alternative forwarding schemes topic. I still prefer the addition of sync read to the controller. Since the sync read from Mike Ferguson is simple and supported by his ROS Dynamixel software, I propose this.

    Although the ATMega32U4 has a high proportion of space spare, it is not really enough to hold poses, so I think it is not possible to add the interpolation from Mike too.

    An alternative might be to add an interpolated sync write command. It would add time and steps parameters to make an new sync write command. Interpolation would be from previous sync write. Only slightly tricky part is to mix the controller generated sync writes with other bus transactions coming down the USB.

  7. Re: Interest in a powerful, small size USB to Dynamixel ?

    Quote Originally Posted by iBot View Post
    Sorry for the dlay to reply.
    Please don't worry about this

    Quote Originally Posted by iBot View Post
    I tried the new test, but still have latency around 4 ms under Linux on my aold laptop, compared to less than 1ms under WIndows. I need to try some other Linux devices and kernels.
    Ok, thanks
    On my beagleboard, this modification allowed to decrease the latency to around 1.1ms (from 2.1ms).

    Quote Originally Posted by iBot View Post
    On the alternative forwarding schemes topic. I still prefer the addition of sync read to the controller. Since the sync read from Mike Ferguson is simple and supported by his ROS Dynamixel software, I propose this.

    Although the ATMega32U4 has a high proportion of space spare, it is not really enough to hold poses, so I think it is not possible to add the interpolation from Mike too.

    An alternative might be to add an interpolated sync write command. It would add time and steps parameters to make an new sync write command. Interpolation would be from previous sync write. Only slightly tricky part is to mix the controller generated sync writes with other bus transactions coming down the USB.
    Ok, I will look into it Mike Ferguson's work. Even though I'm not a fan of custom protocol extensions, it seems like a good idea to be compatible with what is already in use instead of going my own way.

    About the way to flash the firmware:
    Buttons on the board would have to be extremely small, which would make them expensive and not very easily accessible. That was the route I took for the first prototype and the buttons I found cost roughly 30% of the price of the board and are not easy to press, sometimes it is even impossible when the USB2AX is plugged besides other USB devices.
    I'm strongly thinking about adding an auto-update feature, a way to enter bootloader mode by sending a particular string to the USB2AX, without having to physically touch it.
    It should have the following properties:
    - don't make the code too much more complex
    - no risk being triggered by mistake
    - no significant slowdown of the communication

    First, the detection could be limited to a predefined baudrate, a slow one that people would not normally use to communicate with Dynamixels (9600bauds for example). The overhead would then be low compared to the time it takes to send a byte on the serial port.
    At any other baudrate, the code would not even check if the trigger pattern is transmitted.
    It would use a trigger pattern that has very low probability of being transmitted, and a timeout for good measure.

    However, I still have to find is how to perform a reset after FLIP has programmed the MCU...

    More interesting firmwares are definitely something I (and/or probably other persons) will work on, but I won't include them in the final product until they are well-tested.
    ---
    Personal blog: http://xevel.org
    USB2AX documentation: http://xevelabs.com

  8. Re: Interest in a powerful, small size USB to Dynamixel ?

    Here is some progress on the hardware.

    Thanks to help from iBot, we finally added protection devices: ESD protection on the USB lines and TX/RX lines plus 47ohm resistors on the TX/RX lines, just like in the original USB2Dynamixel
    The Hardware Boot and Reset pins are now broke out on the side of the board, through a standard 0.1" header.
    Decoupling capacitors are applied according to the recommendations of AVR042 and the ATmega32u2 datasheet.

    The current length of the USB2AX is slightly above 33mm (including the giganormous USB Type-A male plug), for a board where all the SMD components are soldered on the top side. Depending on the cost of manufacturing, we may change to put SMD components on both sides, and shorten the board a little more.

    Schematics:
    Click image for larger version. 

Name:	usb2ax_v3_schematics.jpg 
Views:	1128 
Size:	69.1 KB 
ID:	3484

    Eagle files (also available from the git repository): USB2AX_v3_20110917.zip

    This is the version I intend to have a few prototypes made, if no critical flaw is found.
    (EDIT: the USB footprint needs some fixing )

    Feedback very welcome! Thanks!
    Last edited by Xevel; 09-18-2011 at 12:40 AM.
    ---
    Personal blog: http://xevel.org
    USB2AX documentation: http://xevelabs.com

  9. #19

    Re: Interest in a powerful, small size USB to Dynamixel ?

    I made a version of the USB2AX firmware to include the SYNC READ capability from Mike Ferguson.

    Because I am still struggling with latency on my linux laptop, this makes a big difference in performance from using the sync read.

    USing Python for a read of 4 bytes (speed, position) from 18 AX12:
    Windows 7 READ 20ms
    Windows 7 SYNC READ 8.5ms

    Linux READ 72ms
    Linux SYNC READ 9.4ms

    Will try it out with the Vanadium Labs software. Should work with URBI too with id change.

    I will send you the source, so you can try it.

  10. Re: Interest in a powerful, small size USB to Dynamixel ?

    Awesome!

    I should be able to finalize the v3.0a board design this week (the silkscreen is still missing, mostly), and have the prototypes boards manufactured directly after that (8 days turnaround). I will assemble between 6 and a dozen boards (I will have access to a manual pick and place and a reflow oven \o/ ) and get them to beta testers immediatly after that.

    Stay tuned!
    Last edited by Xevel; 09-20-2011 at 10:41 AM.
    ---
    Personal blog: http://xevel.org
    USB2AX documentation: http://xevelabs.com

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. Contest Entry Small tracked robot with super strong arm (for its size)
    By phwillys in forum Project Showcase
    Replies: 4
    Last Post: 01-01-2011, 03:28 PM
  2. New camera find, and interest must be building...
    By Robot Dude in forum Mech Warfare
    Replies: 17
    Last Post: 02-24-2010, 05:44 PM
  3. Calculate Motor and Wheel Size
    By metaform3d in forum Mechanics / Construction
    Replies: 14
    Last Post: 04-17-2009, 04:24 PM
  4. Full size robotic leg???
    By Jman26 in forum Humanoids, Walkers & Crawlers
    Replies: 36
    Last Post: 12-08-2008, 07:58 AM
  5. Interesting life size Scopedog
    By crabfu in forum Off Topic
    Replies: 2
    Last Post: 08-03-2008, 07:04 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •