PDA

View Full Version : Hexapod broken?



MadBot
06-01-2017, 12:42 AM
I've got my hexapod running, it's walking, crawling, controlled by the remote.

Lately however, it'd barely crawl a step and then it stops in its track.

Running the test program:

System Voltage: -0.10 volts.
Voltage levels below 10v, please charge battery.

Despite being plugged to the wall, and of course all servos have been IDed since at one point it was crawling around.

Occasionally it succeeds, but then some servos will fail to read, but not others. But that's rare, it usually fails at voltage check already before it ever gets that far.

Also I have to plug the power supply directly to the board only then will it occasionally succeed. I haven't seen it succeed plugged to the power hub.

KurtEck
06-01-2017, 07:44 AM
I assume when you are saying hexapod, it is a Trossen PhantomX hexapod.

From your description, my assumption is: that at least one of the servos reset their ID to #1, there are many posts up on the forum about this happening. I have had it many times....

How to fix? Depends on which software you are running. Like are you on the Arduino 1.0.x versions with the official libraries. One step would be to go through their setup steps again.

What I would do is run my test program: https://github.com/KurtE/AX12_Test/tree/Arduino1.0.6-version
It is nothing special, but it does allow you to manipulate the different servos.

Note: the test program defaults to using an option (#define SERVO1_SPECIAL) I put in my version of the Phoenix code base, which renumbers servo #1 to servo #19. You can turn that off (#ifdef I think). The reason I did that (suggestion from another member), was because of this problem of servos being reset to #1. So the Phoenix code when it starts up tries to find all of it's servos, if it finds one missing and it finds that servo #1 exists it assumes that we have this issue and it automatically resets the servo #1 to the servo # it thinks it is supposed to be.

Back to test program. It is pretty simplistic and just thrown together, but assuming configured for hexapod, you can then
do a command like: 4 <cr>
And it will do a query of all of the servos it expects and print out their current position.... If you see one that shows something like retry and fail...

Another way I try this, is have the hexapod on some form of stand. (I use an empty NUT container from Costco). Try doing a command 1<cr> Do all of the servos go out to their proper center location or are some of them limp...

Or to verify that more than one servo is now #1, try using the move command like: 2 1 400<cr>
Do multiple servos move? If this happens, you need to renumber the invalid #1 to what it is supposed to be.... There is a command in the test program that will do this: 8 1 9
Will renumber all #1s to #9... So you only want one #1 plugged in. So you need to unplug all of the other #1s... do the 8 command for the one, plug other servos back in...

More info about this in the Readme on github... If you are running a version of Arduino from this decade with more up to date libraries, I have the same test program but in the master (default) branch up on github...

Hope that helps. If not can try some other things... Or you might email Trossen support to see if they have any other suggestions

MadBot
06-01-2017, 09:31 AM
Kurt,

Thanks for responding. Yes it's the Trossen phantom 3.

Why would it switch to servo 1 and then back to the correct ID though? Occasionally, after leaving the robot alone for hours something seems to reset. And it'll be good for a few seconds, then it's back to the low voltage warning. Nothing changed. So it's not failing consistently, more like 95% of the time it's failing. There's the random odd times when the test will succeed.

I'd like to repro and paste the success logs here, but I'm having a hard time getting it to run successfully. I'll post the success logs the next time I see it.

In the mean time, could I be having a bad board/servo? ie. what's the most suspect part when seeing this symptoms?

KurtEck
06-01-2017, 10:02 AM
The why servos reset to servo #1... There have been lots of speculation. I think the two leading candidate reasons are:

a) Power issue: maybe the power went low momentarily and the servo then hiccups.
b) A packet gets munged and the servo screws up...

Probably lots of other ideas on why... But I can for sure say that this happens often enough to suggest this as the first thing to check and to add code to system to hopefully recover.

When there are multiple servos with the same id and you do a query, it is likely they will both try to respond and the data is screwed up.
For example if they want to display the current voltage, they often ask servo #1 for it's voltage, which will likely fail here...

Note: I personally don't like this approach to getting the current voltage. Wish the Arbotix-m board would have something like a voltage divider from the main power to one of the analog pins, so you can get it directly. So again on my board I have wired up simple divider from Power to ground to one of the analog pins... Not hard and again Phoenix code base has options in there to use this... Without this, I personally would disable the check in the code as asking the servos again is not always reliable... Or at a minimum I would change to checking a different servo for voltage.

So again I would suggest checking for this on your robot.

MadBot
06-08-2017, 04:09 AM
All servos IDed correctly. Passed the wiggle test (hexapod test). Had to remove all servo cables from hub and board 1 by 1, and reseat them, but that was it.

So I loaded it with the commander script. It stood on its legs. I switched the RC on and pushed the joystick forward. The bot took 2 steps forward and froze. I flipped the power switch on the bot and turned it back on. Nothing. Repeat 2-3x and again nothing. I left it alone for 15 mins and turn it back on. It stood up. I pushed the forward stick and 3 legs moved and then froze. Again.

I ran console debugger, some funny characters were printing:

„ç!aˆÞËþÄçÞa†±Ëþ„çÞaˆÞËþ„çÞ sbÏ.„Þaˆ¾ËþÄçÞaˆ±Ëþ„çÞaˆÞËþ çÞa€±ËþäçÞa„±Ëþ„ç!aˆÞËþ„çÞa ˆžËþýçÞaˆ±Ëþ

Whatever is the problem, it's intermittent. I can't repro it consistently like I should if a servo ID resetted (unless it has a habit of correcting itself randomly). Starting to suspect a hardware problem?

Any thought what to look for, next?

Thanks!

MadBot
06-08-2017, 04:24 AM
Strange it started working after I forcefully moved the hind 2 legs because I noticed they were limping, esp the right one.

KurtEck
06-08-2017, 07:27 AM
With something like the above, I would look for wires that are being pinched or bent in a strange way. This can lead to breaks in the wiring or shorts.

Strange characters? How are you hooked up? That is if you are using an Arbotix-m board, the processor on it only has two usarts (Serial ports). One is used for the Servos. The other is used by either the XBEE or the FTDI. That is why you can not program the board when you have the XBEE installed.

And the XBees talk using a binary packet format, so they would show up strange on the console... Also typically this communication is only one direction. That is the XBee (Commander) sends packets and the robots xbee only receives...

I have taken advantage of this in the past, by setting up debug messages, and then running a VB program on my PC, where I connect the commander to my PC, as well as the XBEE from the commander... And then the VB forwards all packets from commander to robot and all messages from robot are displayed by vb app... But I am guessing you are not doing this...

Secondary possible reason for garbage displayed (if different setup), is your debug terminal is not configured for the same baud rate your program on the Arbotix-M is configured to output. You can fix this by looking at the source code of the program you are running and look for the line that looks like: Serial.begin(38400);
The number is often one of: 9600, 38400, 115200.

Then make sure the baud rate in the terminal monitor window matches.

MadBot
06-08-2017, 02:21 PM
Thanks Kurt, I'll give it a try - I think your assessment is correct. Some of the cables are a tiny bit short...

The characters as you said it's probably encoded for XBee somehow since the commander program was running. I'll try the different bout rate.

Time to order some cables and retest.

MadBot
06-10-2017, 10:41 AM
Well... it was wiring.

Went on the servos 1 by 1. The ones with bad wiring seems to have low power. The servos can be pushed to move with power running. The good ones are really firm and require a bit amount of force to overpower (which I didn't do). Did this a couple of times and replaced the wires.

Apparently 1/3rd of the cables were bad. I know this is experimentation kit, but 1/3rd is really pushing it. Trossen should keep a better eye on their supplier.

KurtEck
06-10-2017, 11:36 AM
If you have not already done so, you should email them at: trsupport@trossenrobotics.com
As I am not sure how often any of them monitor the forum.

It might be good to know which way the wires were damaged? Did they have an intermittent connection internal? If so could the wire have been under tension which caused it to break or was simply bad to begin with. Or is it the connectors were such that they were not making good contact or?

MadBot
06-15-2017, 06:16 PM
Kurt, I can do all of the above. But I'm just happy for now that the pod is working :) There're a ton of things to do and the possibilities are endless - so I'll probably just stay put. Thanks again! I'll probably post updates on the progress as I make them.