Results 1 to 3 of 3

Thread: SYNC_READ and BULK_READ behaviors during failure

  1. #1
    Join Date
    Sep 2010
    Location
    ಠ_ಠ
    Posts
    2,313
    Images
    27
    Rep Power
    278

    SYNC_READ and BULK_READ behaviors during failure

    So, I'm attempting to expand my dynamixel library (originally for YETIS) to include dynamixel device functionality (plain device and pass-through device), but I've run into a bit of a gap in my knowledge and don't have the parts to close it myself.

    Do MX servos continue to produce the response packet to a SYNC_READ or BULK_READ if the previously scheduled servo did not fill in its part of the response packet? e.g. Send SYNC_READ to servos 1, 2, and 3, but 2 does not exist. Does servo 3 still try to fill in the packet and compute the checksum? How about if servo 1 does not exist, but servos 2 and 3 do?

    I'm working on psuedo SYNC_READ+BULK_READ packet handling for a pass-through device, but don't really want to do an exhaustive search for servos on each dxl interface to build a lookup table for that interface containing the servo type of all responsive servos (AX, RX, MX, XL, etc.). This got me thinking of maybe directly passing the original AX_SYNC/BULK_READ packet as a dynamixel-compliant SYNC/BULK_READ packet (change INST type and recompute checksum) then sending individual READ packets to each servo that does not respond inside the collective response packet. Probably slower than just issuing a READ to every servo if not many MX servos on the buss, but could split into two new INST types: AX_SYNC/BULK_READ (always use READ) and MIXED_SYNC/BULK_READ (use SYNC/BULK_READ, then READ). If they don't complete the collective response packet, then could add an infrequently used ID (0, 252, etc.) to separate the first group of servos in the packet that can respond to SYNC/BULK_READ and second group that requires new READ packets.


    Current thinking is to have the 'pass-through device' / 'intermediate controller' always use DXL2.0 protocol in its communications with the main controller (PC) then translate to DXL1.0 if necessary. The Teensy 3.1/3.2 shield I've gotten close to ordering has hardware for independent TTL(Serial1) and RS-485(Serial2) dynamixel interfaces, so could mix and match servos (XL-320 on DXL2.0-TTL and MX/RX/EX on DXL1.0-RS-485; AX/MX on DXL1.0-TTL and Dynamixel Pro on DXL2.0-RS-485; etc.). Serial3 is available for use with an adjacent TXEN pin, but no dynamixel hardware on the shield. The CAN interface on the shield can be reclaimed if the LSM9DS(0,1) interrupt (data-ready) pins are not to be used. Was planning to get a breakout board before ordering the shield, so routed a version using the LSM9DS1 instead of the LSM9DS0 because Sparkfun retired their LSM9DS0 breakout board and I forgot that Adafruit still sells LSM9DS0 breakout boards. Still not sure which to try; LSM9DS0 was simpler routing of the interrupt (data-ready) pins to available Teensy pins, but LSM9DS1 is newer and cheaper (even if X-axis of accel and gyro are 'left hand rule' instead of 'right hand rule'; simple multiply by -1.0 to fix).
    Please pardon the pedantry... and the profanity... and the convoluted speech pattern...
    "You have failed me, Brain!"
    [git][mech][hack]
    gives free advice only on public threads

  2. #2

    Re: SYNC_READ and BULK_READ behaviors during failure

    Hi Tician,

    I have been watching to see if there were any responses here as, I have been playing around with my Teensy code base to act like a controller and started to play around some with SYNC_READ code and I am trying to decide how I want to handle some similar issues.

    I only have one MX servo (MX 12w), so I can not answer anything about bulk reads,

    But with Sync-Read, trying to decide what form of timeouts should the code do. For example I am adding code to my Raspberry Pi project (actually running on ODroid xU4) where my AX test program has another command that tries to use SYNC_READ to read in all of the current positions of the servos. I am finding I need to update my copy of the BIOLOID library to allow the SYNC_READ to get through the validation code.

    My current testing of some of this only has one servo (ID 1), so when I ask it to do a sync read on all of the HROS1 servos, all but ID 1 will fail...

    So when Teensy receives the command, it starts a Register read on #1, which looking at logic trace the AX read took about: .1ms from the time it completed the request until it has the complete response, at which time it issued a request on servo #2, which then timed out after maybe 4ms, before it tried #3, which again timed out after 4ms... On the ODroid side the whole command maybe timed out long before the Teensy side gave up.

    I know I need to update Odroid side to set the timeout depending on how many servos we are requesting data from, probably also by how much data per servo. But not sure what a reasonable value should be yet. For example it may depend on what the servo response delay is set to on each of the servos. But secondary to this, what should the Teensy (or Arbotix or USB2AX) do with these requests and possible servos not there and timeouts. Suppose I calculate that the ODroid will wait for 10ms for a response and on the Teensy side I have a couple of timeouts and lets say I am up to 8.5ms from start of command. Should I continue asking the other servos for information, knowing that I may timeout again and no data will be sent back in time? Or should I internally timeout and send back partial data. Note: the Teensy side (like Arbotiix pro) currently sends back all 0xff values for those servos who did not respond.

    Again sorry if I am slightly off of your topic.

  3. #3
    Join Date
    Sep 2010
    Location
    ಠ_ಠ
    Posts
    2,313
    Images
    27
    Rep Power
    278

    Re: SYNC_READ and BULK_READ behaviors during failure

    Definitely on-topic.

    For the arduino-compatible controller (library takes HardwareSerial* and pin_txen as inputs), I'm using a default 500[us] timeout for receiving a full packet then extending it by the received packet's length times some number of [us] (dependent on baudrate: (1000000*12)/baud) if it actually did begin to receive at least the header data prior to the default timeout count being reached.

    Haven't really worked much on the PC side, but it is going to be ROS from the start so longer timeouts are not a problem as long as the node actually gets the full response from the Teensy before attempting another packet that would (maybe) restart the entire process (Teensy may continue working on old packet and not immediately restart process with new packet after it is received from PC, which borks PC timeout again). I'm trying to go for completeness over of very high update rate, since just getting the same few servos every time at a high rate is not very useful. Will probably default to a 16[ms] timeout and add on 2[ms] per device on the PC side, although I won't get my teensy-3.2 until at least monday.
    Please pardon the pedantry... and the profanity... and the convoluted speech pattern...
    "You have failed me, Brain!"
    [git][mech][hack]
    gives free advice only on public threads

Thread Information

Users Browsing this Thread

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

Similar Threads

  1. Question(s) USB2AX SYNC_READ example code?
    By TXBDan in forum DYNAMIXEL & Robot Actuators
    Replies: 11
    Last Post: 06-26-2015, 02:45 PM
  2. Question(s) Nuke 15 Tool Frame Redraw Failure
    By Griffin2003 in forum Arbotix, Microcontrollers, Arduino
    Replies: 3
    Last Post: 03-31-2015, 03:22 PM
  3. Question(s) Reading position data from multiple MX-64T quickly (sync_read)?
    By blooop in forum DYNAMIXEL & Robot Actuators
    Replies: 12
    Last Post: 12-12-2014, 06:39 AM
  4. Question(s) PhantomX Reactor Robot Arm servo failure?
    By Jship07 in forum Interbotix Robotic Arms
    Replies: 7
    Last Post: 12-08-2014, 10:35 AM
  5. Blowing N-channel MOSFETs: verifying the failure mode?
    By jwatte in forum Arbotix, Microcontrollers, Arduino
    Replies: 0
    Last Post: 03-30-2013, 11:45 PM

Posting Permissions

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