Page 1 of 4 1234 LastLast
Results 1 to 10 of 39

Thread: Servos resetting IDs?

  1. Servos resetting IDs?

    I have seen a few scattered references to this problem, but haven't found a resolution.

    During a run, at unexpected times, our PhantomX will suddenly have Servo_XX reset its id to Servo_YY (Usually Servo1).

    We then have to stop testing, upload new firmware, and reset the IDs by hand back to what they should be.

    Does anybody know why this is happening, and what we can do to fix it? Thanks

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

    Re: Servos resetting IDs?

    There is always the option of using the lock byte before starting the motion engine. Setting register 47 (0x2F) to 1 will prevent all of the addresses in the 'EEPROM' range of the control table from being modified. Once set, the servo must be powered off to change the ID, baudrate, CW/CCW Angle Limits, and Maximum Torque (among others). You could occasionally check that register to see if it is still set to one to determine if the servo has managed to reset itself (always changes to 0 at poweroff).

    Not sure if it is a brown-out causing problems (low voltage on servo causing odd behavior), or if it is interference on the data line causing erroneous but valid packets (I think there are two different reset commands), or if there is an occasional conflict with the ax12 library, or if there is just a problem with the firmware on the servos. Just occurred, but when power is first applied to the servo its bootloader waits briefly for a special command to update its firmware. It may be possible that when it receives (part of) a dynamixel packet instead of the correct serial packet it freaks out and resets. I should probably test that hypothesis later today, if I have time. Already wasted enough time re-reading all 25 pages of the hexapod thread thinking there was a solution discussed in there (the failure to use unsigned was related to the commander and not the dynamixel bus).
    Please pardon the pedantry... and the profanity... and the convoluted speech pattern...
    "You have failed me, Brain!"
    bleh
    more bleh

  3. #3

    Re: Servos resetting IDs?

    I was running into this several times with the PhantomX hex robot.

    So I got to the point, where I added code to my PhantomX test program, that one of the commands would be to print out the current position of each of the servos. When one or more servos would end up with the same ID, they would fail on the query and also the query of the duplicate would most often fail as well. From this I could deduce which servo was wrong and I had another command that change the id of X to Y, where I would first unplug the valid X one...

    I think my test program is posted somewhere in my thread: http://forums.trossenrobotics.com/sh...rent-Hex-robot... But probably should add it to my Github stuff...

    What I found was with the earlier AX12 library there was an issue with packet responses were getting corrupted. I traced this down to the issue that the library was switching the USART to read mode while the write was still active. I changed my copy of the library to wait until the transmitter is empty (like the change to Arduino 1.0.2 flush function), before I enabled the receiver. This made my reception of responses much cleaner and the number of times I ran into this issue appears to have been reduced. I believe that Fergy also tried to address this issue by detecting multiple 0xff values at the start of the packet. So first thing I would do is to make sure you have the latest library. I think I posted my version of the library earlier, but if wanted can post again.

    Kurt

  4. Re: Servos resetting IDs?

    tician,
    You might be on to something I hadn't thought about. Instead of just a bad packet (somehow) causing the motors to reset, maybe they are restarting first (low voltage?), and then receiving a bad/unexpected packet.

    Kurt,
    I have your latest code but havent run the test program. Hopefully Fergy found the problem, I will pull the latest arbotix source and see what happens.

    If the problem persists, it seems like a patch in the ax12 or arbotix library is a good place to start to fix the issue. Having the phantomx suddenly go wonky during a run is a scary prospect to me. I am willing to work on such a patch, and any more input of where to start (and what people have already looked at) would save lots of time.

    Thanks to both
    Last edited by phil0stine; 12-14-2012 at 02:02 PM.

  5. #5
    Join Date
    Jun 2011
    Location
    USA
    Posts
    547
    Images
    107
    Rep Power
    42

    Re: Servos resetting IDs?

    If you have an easy to repeat setup for getting the AX-12s to reset their IDs, it might possible to catch the back packets with PyDyPackets. Then again, it might not, as I'm not sure what happens when the servos send response packets (since PyDyPackets is very much a work in progress). Specifically, it should be possible to splice in an FTDI adapter to the Dynamixel bus while the PhantomX walks around, and log the packets with PyDyLogger.py.

  6. #6
    Join Date
    May 2008
    Posts
    2,228
    Images
    155
    Rep Power
    127

    Re: Servos resetting IDs?

    The latest release (0015) addresses the bad packets by adjusting some timing, but more importantly by enabling the pull up resistor on the RX line which was previously left floating.

    I really think Tician is on to something here though: the only time I've really seen this reported is on large hexapods and really overloaded bipeds. phil0stine, what sort of flooring are you running the robot on? I wonder if you are getting more resistance to movement than we are used to seeing.

    I talked to Andrew, and I plan to run a test over the weekend to see if I can force a servo reset under voltage dropout conditions.

    -Fergs

  7. Re: Servos resetting IDs?

    I agree with Fergs. Since there are plenty of other projects with arbotix/AX12 that dont have these issues, it makes sense to look at how the phantomx is different.

    In particular, our group chose it due to its relatively large payload (even with AX12s). We haven't added any extra weight yet, but we have certainly been testing higher speeds, and so far the testing has been on a flat carpet. We have a tile floor we can test on for a comparison.

    If it is low voltage condition, I don't see a clean way of avoiding dropouts altogether, especially with a larger payload, other than going with a more powerful battery. If the system can recover from dropout, that would be fantastic.

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

    Re: Servos resetting IDs?

    I know that in the past we have had problems with intermittent shorts in cables causing comms problems in Gerwalks, but I don't think any of them ever reset the control table. Unfortunately, I do not know which wires in those cables went bad (the faults being intermittent and found by process of elimination). This happened using original AX-12+ gerwalks with CM-5's running Robotis' controller firmware (8S ~9.6V NiMH batteries).

    I must admit that I do have the nagging feeling that I had found the ID reset once or twice on a gerwalk, but that may just be from the occasions where RoboPlus Motion failed because the AX-12 were in wheel mode instead of servo mode. I really don't think it has ever happened to any of the CM-5/510 humanoids/bipeds, but they have had surprisingly little use and never much of a payload. There was a former comprehensive humanoid that had a pan or tilt servo for the 'expert' wireless camera and the four bipeds have pan-tilt for HaViMo2 modules (two with humanoid legs and two stock Bipedwalk design from Robotis).
    Last edited by tician; 12-14-2012 at 09:46 PM.
    Please pardon the pedantry... and the profanity... and the convoluted speech pattern...
    "You have failed me, Brain!"
    bleh
    more bleh

  9. #9
    Join Date
    May 2008
    Posts
    2,228
    Images
    155
    Rep Power
    127

    Re: Servos resetting IDs?

    Quote Originally Posted by phil0stine View Post
    If it is low voltage condition, I don't see a clean way of avoiding dropouts altogether, especially with a larger payload, other than going with a more powerful battery. If the system can recover from dropout, that would be fantastic.
    There isn't a lot of bulk capacitance on an individual AX-12. One potential fix to ride out the low voltage dips is to put a fairly large capacitor at the end of each leg chain, as well as possibly some more bulk capacitance near the ArbotiX and/or Battery. Of course, this could turn into a mess at power up if you add too much bulk capacitance and the inrush is out of control....

    -Fergs

  10. Re: Servos resetting IDs?

    To update:
    We recently experienced a definite (very brief) low-voltage situation across multiple servos, as a result of somewhat unrelated testing.
    As a result, 3 servos immediately reset their IDs, which is the most I have ever seen at one time before. It's not hard proof, but leads me to believe that voltage dropout is indeed the root cause of the issue.

Thread Information

Users Browsing this Thread

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

Similar Threads

  1. Servos
    By byi in forum Mech Warfare
    Replies: 8
    Last Post: 07-15-2010, 11:51 PM
  2. Question(s) what servos
    By Grand Robot Master in forum DYNAMIXEL & Robot Actuators
    Replies: 21
    Last Post: 06-10-2009, 08:48 AM
  3. Hot Servos
    By Grand Robot Master in forum DYNAMIXEL & Robot Actuators
    Replies: 1
    Last Post: 04-17-2009, 12:06 PM
  4. Question(s) best servos for the job??
    By Bug57 in forum Robotics General Discussion
    Replies: 37
    Last Post: 12-16-2008, 07:21 PM
  5. HITEC Servos: Can the OEM RN-1 Servos handle 7.4V?
    By MYKL in forum DYNAMIXEL & Robot Actuators
    Replies: 10
    Last Post: 06-23-2008, 04:39 PM

Tags for this Thread

Posting Permissions

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