PDA

View Full Version : [Question(s)] ScorpionX MX-64T Robot Turret



Max L
02-12-2013, 12:27 PM
Hi guys!

I’m quite new to the robotics stuff, hope someone can shed some light. I’ve decided to write here instead of support, maybe it will be useful for other newbies like me. Any help appreciated, thanks in advance.


Preface and what I’m trying to achieve:
All I need is a stationary platform with 2 DOF (turret) to orient a small piece of spatial pointing hardware (laser). Yes, simple as that. My typical laser weights are between 200-1200g (less than 10x2x2cm), I need to be able to re-orient one with frequency of about 50-60Hz, with frame-to-frame angular speed not greater than 30-40 rpm, while maintaining overall positioning error not greater than 4cm on target distance of 5m.

Following some recommendations, I’ve decided to stick to the Trossen’s robot turret kit. Given my specs/demands, the updated ScorpionX with its powerful yet precise MX-64 motor seemed to be an excellent choice. Unfortunately, there’s quite small info available.


User experience:
As said above, it’s quite short, but for now I can surely say to all newcomers like me:
1. YES, it’s very powerful, don’t be confused with the servo size. I’ve nearly damaged my equipment when I first started it.
2. Get some knowledge about firmware and controls right away. Methods for getting/setting data packets, especially for limiting angles and operation speeds/torques. For now, I’m just starting to learn this. BTW, the “Interbotix Robot Turret Manual & Protocol” which resides in the “Documentation” @ ScorpionX page IS NOT RELEVANT for ScorpionX *. This is sad (and it was the reason why I’ve learned #1 in a hard way).
*as for Feb, 12, 2013:
- goal positions are 0..4095 (not 0..1023 like in previous models), so be careful with appropriate lo/hi values;
- in commander ext protocol 'pan' and 'tilt' should be swapped with each other if you want to use "1" and "2" notation defined by default/
3. If you want to pan-tilt something relatively heavy and/or with large dimensions (don’t forget your common sense and tech specs!), you should really consider rebuilding your turret: cutting the metal frame parts and placing your servos in a way that each one would only “rotate” (that is, taking load only in perpendicular plane to its rotation axis).


Questions:
I’m tracing with the following code (for now I’ll just go for the TILT servo, no load is applied, 12V-5A from the AC adapter):


#include <ax12.h>
...
#define MAX_TILT 4095
#define MAX_TORQUE 1023
#define ERR_LVL 32 // 00100000 = overload
...
#define IsMoving(id) (ax12GetRegister (id, AX_MOVING, 1))
#define GetSpeed(id) (ax12GetRegister (id, AX_PRESENT_SPEED_L, 2))
#define GetTorque(id) (ax12GetRegister (id, AX_PRESENT_LOAD_L, 2))
#define GetCurrent(id) (ax12GetRegister (id, 68, 2))
...
void setup()
{
...
// set max torque
ax12SetRegister2(TILT, AX_MAX_TORQUE_L, MAX_TORQUE); delay(50);
...
//set alarm
ax12SetRegister(TILT, AX_ALARM_LED, ERR_LVL); delay(50);
ax12SetRegister(TILT, AX_ALARM_SHUTDOWN,ERR_LVL); delay(50);
...
}

void loop()
{
if (Serial.available() > 0) {
SetPosition(TILT, MAX_TILT);
}

if (IsMoving(TILT) > 0) {
Serial.print("pos = "); Serial.print(GetPosition(TILT));
Serial.print(" \t speed = "); Serial.print(GetSpeed(TILT));
Serial.print(" \t torque = "); Serial.print(GetTorque(TILT));
Serial.print(" \t current = "); Serial.print(0.0045*(float(GetCurrent(TILT))-2048));

delay(10);
}
}


My general question is about the speed-torque balance and avoiding the alarm shutdowns. Given my goals, I generally want to re-position my turret as fast as possible while feeding it with desired positions. The tilt-pan order doesn’t matter (and no need for interpolation): only correct positions. I would be glad to hear any comments / suggestions / hints.


What is the reasonable frequency (frames-per-second) that I should use? I assume it’s more likely an Arbotix question. And as far as I googled this should be around 50Hz.
How to estimate optimal limits for the rotation speed and/or torque? According to the Link#5 below it can be estimated experimentally, and according to the #6 there is a “rule of thumb”. BUT:
How the alarm shutdown works and how it’s triggered? In the example above:

when I try to make a full circle with Tilt servo (no load), it actually move to the desired position while showing about 500-520 of avg speed (according to manual 520*0.114rpm ~ 59.3 rpm). But after that it flashes both (pan and tilt) LEDs and restarts. I make guess that it was ‘overload’, so
now I set ERR_LVL to “0”, burn it again, repeat the above movement and… it flashes both LEDs and restarts! How is that possible? Am I getting something wrong?

How to catch the error code?
According to robotis, USB2Dynamixel can help to debug the servo, but I don’t have it..


Info:
After digging this forum and robosavvy’s and some googling, I’ve come to rely on the following:

http://support.robotis.com/en/product/dynamixel/mx_series/mx-64.htm - specs and info from servo manufacturer
http://support.robotis.com/en/product/dynamixel/dxl_communication.htm - their description of the communication protocols
http://www.shervinemami.info/dynamixels.html - some thoughts about dynamixels, covering torque etc.
https://www.ce.utwente.nl/aigaion/attachments/single/335 – modeling of the dynamixel
https://sites.google.com/site/robotsaustralia/ax-12dynamixelinformation – another thoughts about dynamixels and measuring its effective torque
http://forums.trossenrobotics.com/showthread.php?4195-AX12-how-to-turn-off-overload-detection // self explanatory

#3 solved by changing the power supply, my original one seems to be defective. Thanks to tician and Tyberius.

tician
02-12-2013, 04:40 PM
The arbotix interpolation engine runs at about 30Hz, but the DARwIn-OP motion engine updates at 125Hz. Anything in between works just as well. Doesn't really apply to your application, but the AX/RX servos use a 16MHz ATmega88 so are a bit more limited in position control and update rate. The MX servos use a 72MHz ARM Cortex-M3 running full PID control with a 12-bit magnetic encoder, so are capable of significantly better performance and response than the older models.

Do you have a spare FTDI dongle or Arduino? You can hook up the RXD pin of the FTDI to the dynamixel bus and record all communications using your pc. PyDyPackets is a useful tool, although I don't recall how well it handles error/status packets.

When you say the LED flashes and then restarts, do you mean that 1) the LED flashes once and you notice that the servo has restarted, or 2) the LED flashes continuously and you have to restart the servo? If it flashes once and you just notice that the servo has rebooted, it may be that your power supply is inadequate. There were problems earlier with some phantomx quads and hexes getting their servo IDs reset to ID==1 because the voltage at the servo would drop too low during high loading or high speed movements. Decreasing the "Torque Limit" (i.e. maximum PWM value it will use to drive the H-bridge) might help prevent brownout resets, but I don't have much experience with the bigger MX servos. The MX-64 does have actual current sense capabilities, but it reports that in a different register from the "Present Load"/PWM value.

jwatte
02-12-2013, 05:06 PM
This is what I've learned when experimenting with the MX-64T myself. It's not something I've read in official manuals, so I may be wrong.

I think that "overload" itself is not necessarily bad. It's when the "overload" turns into "overheat" or into "cracking the gearbox" that you're in trouble. Temporary overload at the edge of movement arcs may be totally normal AFAICT.
I set the shutdown alarm to shut down on overheat, and not shutdown directly on overload. Instead, I make sure I'm not asking for the impossible from the point of view of the controller. I also poll the status register and keep an eye on the bits set/not set in that in the control software. I'm not sure "standard" controllers can do this; I wrote my own.

Also, you can lower the "P" gain and raise the "I" and "D" gains a little bit to get a smoother force response when you just set a target position. Else the servo will immediately say "hey, I can't get to THERE right NOW, so I'm in OVERLOAD!!1!eleven!." I've been meaning to play around with this, but not actually gotten to it, so if you do, please report results!

tician
02-12-2013, 06:11 PM
IIRC, overload alarm is basically saying the PWM value driving the H-bridge is at, or attempting to exceed, the "Torque Limit" value. It is very common on AX-12 when using low "Torque Limit" values and does not cause the servo to go into overload shutdown until the limit has been met/exceeded for a fixed amount of time. This is both good and bad. A short wait period prevents spurious torque off conditions, but if the wait time is too long and the servo does not actually have current sensing (AX-12/18 and RX/MX-28), it can burn out the motor and/or H-bridge.

Max L
02-13-2013, 10:00 AM
tician, jwatte, thank you all for your quick replies.

Refresh rates. tician, I got your point and this is something I truly expected from the MX-series. As soon as I’ll get a complete understanding of my overload issue, I’ll try to experiment with those and report practical results here.

FTDI. I only have this http://www.trossenrobotics.com/store/p/6406-FTDI-Cable-5V.aspx and this http://www.trossenrobotics.com/p/arbotix-robot-controller.aspx, as it ships with the turret kit. Could you please tell in more detail what can I do with it?

About restarts. Yes, it is exactly (1). For example: I add to my previous code for setup() something like
Serial.println(“Turret says HI!”)
then burn, connect to the port , issue my tilt command (0..4095), without any speed/torque limitations and without any load to servos - it rotates to the desired position, and after stopping immediately flashes servos LEDs and 1-2 seconds after I can see my welcome message again in the Serial monitor. So I guess full restart occurs...

And about the ID reset – it’s very interesting observation. For now I’ve only checked IDs on startup (and they seemed to be ok). I’ll try to monitor it during the run and report the results. What I saw before is actually strange: sometimes BOTH servos flash their LEDs even if I “overloaded” only one of them.

Considering power and current issues. I use AC Adapter that came with the kit (12V, 5A). According to the MX-64 specs its stall torque is 6 Nm at 12V, 4.1A and no-load RPM is 60 at 12V also, so I guess that my adapter is suitable. Actually, I’ve tried to monitor the voltage (not present in my code above) and current of each servo converted to mA, and yes, the current low-byte is 0x44 which is absent in the previous models.

It shows 12.4V and something like 0.1-0.4A during movement (again, without any load), and 0A while being idle. I’ve also tried to play with PUNCH, setting it to 20-25 to match its standby current of 100mA, but no change (anything significantly greater than that caused very strange sound to appear in the servo, so I shut it down immediately and never used those high settings again).

What I’ve recently noted. When I limit the maximum speed (not touching the torque limit), say to half (250 ~ 250*0.114rpm ~ 28.5rpm – about 50% of no-load rpm), the current averages around 0.3-0.4A.
But when I clear the limitation I get the 0.5-0.6A spike in the beginning and a fast drop to 0.1-0.2A which persists almost until the movement ends while fading to 0A (and after that - LED flash, restart etc). I guess it is something overload should look like. As far as I know, torque is proportional to the current, so alarm shutdown theoretically should set the current to 0.

jwatte, playing with alarm led/shutdown is exactly what I was intended to do. I agree that adequate knowledge of what exactly you are going mount to the turret head, while keeping in mind MX-64 specs, everything should go fine. But as I wrote above, when I set
ax12SetRegister(TILT, AX_ALARM_LED, 0)
ax12SetRegister(TILT, AX_ALARM_SHUTDOWN, 0)
it still flashes and resets.. Why?..

And by the way, how do you catch those error bits? I assume it should be in those return packets. How can I get them? I’ve tried to modify the default ax12SetRegister() from the “ax12.cpp” and use ax12GetLastError(). But no success. Maybe I’m having some error reporting and/or error level setting issue (my servos return lvl is set to AX_RETURN_ALL).

About the PID control properties – yes it keeps intriguing me since start (in fact, control systems is one my of math interests). I’ll definitely going to dig it, and of course I’ll report on something interesting.

Temporary solution. Considering your comments and my tests, for now I tend to use this:
· Limit the torque (0x22) to something like 900-950, leaving max torque (0x14) at its default maximum of 1023.
· Limit the moving speed (0x20) to something like 420-450 (48-51 rpm)

But the question/issue persists…

Upgrayd
02-13-2013, 11:54 AM
You have far too many changes and variables floating around here to really tell what is going on.

What I would do:
- Disassemble your turret and work with just a single servo connected to the controller.
- Issue a reset command to that servo to get all registers back to the factory defaults.
- Write a basic program that simply commands the servo to move between two preset positions with a small delay.
- Let us know the results.

jwatte
02-13-2013, 12:48 PM
it still flashes and resets

Ah! Your problem is not with the servo; your problem is with the controller that you upload your code to.

Try to figure out why that controller would re-set. It could be many reasons -- maybe it's trying to talk to a servo that's not answering, and getting upset. Maybe it's stuck in an infinite loop, and a watchdog timer resets it. Maybe there's a voltage spike when the servo stops moving, and that spike is enough to cause the controller to reset. Maybe it's something different.

To start with, I would remove the delay(50) after your various set commands. I would also increse the delay(10) to a delay(50) in the "if moving" test inside loop, as 10 milliseconds may not be enough to drain all the text you print while it's moving out of the serial port.

Also, your code is going to want to move to the target all the time, because you just check "is serial available" and don't read anything. This means serial will always be available, and it will always keep sending that command. That might, conceivably, be the problem, so fix that!

tician
02-13-2013, 12:52 PM
Your arbotix is resetting, so for your application, the power supply is obviously not sufficient and/or the servo/power cables are too long. Try setting the "Torque Limit" register to a smaller value so that it does not try to use full PWM/power/current immediately. When under little load, the motor will move very quickly - perhaps faster and farther than the control algorithm can react - which could cause it to rapidly switch from full speed in one direction to full speed in the other consuming large amounts of power and dropping the voltage at the servo/arbotix.


Punch is the number of encoder ticks from the goal position at which the H-bridge will shut-off/not-care. Too big, and the motor will be jittery with a lot of give/backlash because it does not power the h-bridge until it is too far from its goal position. Too small, and the motor will be jittery because of noise in the encoder output and slight changes in position.


Since you have only one FTDI dongle, and it is required by the arbotix, you're in a bit of a bad place. Assuming you are using MX-64T, you will need to get another cheap FTDI dongle, an Arduino, or a USB2Dynamixel. Once you have that, connect its RX pin to the dynamixel communication pin (a ~1k series resistor would probably not be a bad idea to help protect it) and one of its ground pins to the ground pin of the dynamixel bus. If you are using MX-64R, you need a USB2Dynamixel.

Max L
02-14-2013, 08:37 AM
Your arbotix is resetting, so for your application, the power supply is obviously not sufficient and/or the servo/power cables are too long.
Ok, maybe that stock AC isn't good enough, i'll try to find equivalent one. Cables are stock (came with the kit), so it's a question to trossens what cables should be...


Try setting the "Torque Limit" register to a smaller value
I got your point. This is exactly what I did (my previous message). So it doesn't reset and flash LEDs, but the movement speed becomes lower either. So for my applications I don't see the difference between lowering the max speed or limiting the torque (and both are chosen experimentally).


Punch is the number of encoder ticks from the goal position at which the H-bridge will shut-off/not-care.
Your description differs from robotis's one. But anyway I can't say its critical to me.


Since you have only one FTDI dongle, and it is required by the arbotix, you're in a bit of a bad place. Assuming you are using MX-64T, you will need to get another cheap FTDI dongle, an Arduino, or a USB2Dynamixel. Once you have that, connect its RX pin to the dynamixel communication pin (a ~1k series resistor would probably not be a bad idea to help protect it) and one of its ground pins to the ground pin of the dynamixel bus. If you are using MX-64R, you need a USB2Dynamixel.
I'm using MX-64T. Ordering USB2Dynamixel is not an option (for now), since I can't wait for long shipment time. So I guess I will have to use only what I have now.


Ah! Your problem is not with the servo; your problem is with the controller that you upload your code to.Try to figure out why that controller would re-set. It could be many reasons -- maybe it's trying to talk to a servo that's not answering, and getting upset. Maybe it's stuck in an infinite loop, and a watchdog timer resets it. Maybe there's a voltage spike when the servo stops moving, and that spike is enough to cause the controller to reset. Maybe it's something different.
Any hints how can I check my arbotix controller?


To start with, I would remove the delay(50) after your various set commands.
I've inserted those "Set*" delays intentionally, since when the delay is absent it sometimes cant set next values correctly (verified experimentally via respective "Get*"). But I don't know if it is normal...


I would also increse the delay(10) to a delay(50) in the "if moving" test inside loop, as 10 milliseconds may not be enough to drain all the text you print while it's moving out of the serial port.
Actually, it is, and I usually use even bigger skips. This was just a sample.


Also, your code is going to want to move to the target all the time, because you just check "is serial available" and don't read anything. This means serial will always be available, and it will always keep sending that command. That might, conceivably, be the problem, so fix that!
Ok. I've set it to parse instructions via Commander(), like in trossens sample app, but no change.



What I would do:
- Disassemble your turret and work with just a single servo connected to the controller.
- Issue a reset command to that servo to get all registers back to the factory defaults.
Seems to be fair enough.
- I've detached my TILT servo from the PAN servo, unplugged my PAN servo from the arbotix board bioloid#1 port, plugged my TILT into bioloid#1 port of the arbotix.
- Issued reset packet as follows:

#include <ax12.h>

#define PAN 1
#define TILT 2

void ax12Reset(int id)
{
int checksum = ~((id + 2 + AX_RESET) % 256);

setTX(id);

ax12writeB(0xFF);
ax12writeB(0xFF);
ax12writeB(id);
ax12writeB(2);
ax12writeB(AX_RESET);
ax12writeB(checksum);

setRX(id);
}


void setup()
{
Serial.begin(38400);
delay(4000);
ax12Reset(TILT);
delay(4000);

// test blink led of #1 servo
ax12SetRegister(1, AX_LED, 1);
delay(1000);
ax12SetRegister(1, AX_LED, 0);
}


void loop()
{


}
And.. no reaction at all. Tried some Get*() commands and they all return "-1". ID=1 - should be after reset according to the manual.
Any suggestions how to get back that servo to life? Arbotix reset?..

DresnerRobotics
02-14-2013, 12:34 PM
It's possible your AC adapter is defective, the MX-64T turret unit we have in-house functions fine without resetting.

Max L
02-14-2013, 12:47 PM
Ok, thank you. Just glad to hear response from the Trossen team. I've found 11.1 LiPo and will give it a try.
As soon as I can start my servo again... Could you please advise what I did wrong? Why the above reset function made impossible to run my servo?
And for future usage - what is a proper way to reset dynamixels via arbotix?

tician
02-14-2013, 09:51 PM
Issuing a RESET to the MX-64T causes its ID to reset to 1 and its baud rate to most likely return to 57600 bps instead of 1 Mbps. Change the baud rate in your arbotix code to 57600 instead of 1000000, and you should be able to access the MX-64T again and change the baudrate back to '1' and change the ID to whatever you want.

Max L
02-15-2013, 12:19 PM
Thank you, tician. Changing the baud rates solved the problem.

tician, Tyberius your diagnose is right, thank you very much. I've plugged my PC's PSU (@ 12V-15A) and everything works like a charm. So yes, it turns out that my AC adapter is a defective one (however there is no external damage, LED is always on). Guess my questions were a noob ones and could cost me a couple of weeks (and $$) without your help guys.
4524
Thanks everyone for the discussion. I'll continue running my tests and report if something interesting pops up.

tician
02-16-2013, 01:11 PM
It may not be that the PSU is necessarily "defective" so much that the ratings are a bit of wishful thinking (much like the dynamixel torque ratings - temporary stall, not continuous).

Case in point: attempts to use one of the really nice 12V-5A SMPS from Robotis to power an infrared light source rated at 12V and ~4A_max would send the SMPS into immediate overload shutdown until the light source was disconnected (LED would turn off because it was a maintained load. If sufficiently short term, like a motor H-bridge switching closed then defaulting to open when power cuts out, the LED might not even perceptibly blink out). Next time we need to use that light source, I intend to donate/sacrifice my old 550W ATX PSU so that we do not run into the same problems we did with the 12V Pb-Acid batteries (We wound up with vast dissimilarities in the overall intensity in percent transmittance curves as the charge depleted. The changes in total intensity and output spectrum of the light source were sufficient to mostly nullify the compensation/source-indifference that percent transmittance with a reference material is supposed to accomplish).

jwatte
02-16-2013, 10:37 PM
When using lead acid batteries, a boost-buck dc dc converter is great for stabilizing the voltage. Or use a higher voltage battery and a buck converter.

tician
02-17-2013, 01:03 AM
It's more that the lead acid batteries were too small and old for the sustained current drain the light source put on them (up to 30~40 minutes of actual spectroscopy during each session, plus ~10 minutes prior to sensing for the light to stabilize). <irony?>The reasoning given for using the lead acid batteries instead of a switching power supply was the hope to avoid any noise/instability in the light output from voltage conversion and/or mains hum.</irony?> meh. live and learn.

jwatte
02-17-2013, 01:13 AM
You may have learned this already: You can usually deal with the ripple out of a switching mode power converter in a number of ways.

First, that ripple will typically be in the megahertz range these days, and even old controllers had it in the 40 kHz and up range. It may not even matter.

Second, you can put a LC filter on it with a series inductor and a parallel capacitor.

Third, you can get a switching converter for 15V, but use a linear regulator to burn it down to 12V, letting the regulator ripple rejection (typically 80 dB or better) do the job.

Fourth, you can just get a linear power supply in the first place :-)

Th232
02-17-2013, 01:59 AM
<irony?>The reasoning given for using the lead acid batteries instead of a switching power supply was the hope to avoid any noise/instability in the light output from voltage conversion and/or mains hum.</irony?> meh. live and learn.

We do this too for measuring biological signals, even down to having al foil over everything to shield our setup from noise. For lower voltages, as Jwatte suggests, we run linear regulators from said battery. It speaks volumes that in an organisation that got a good $20 million for use over 3 years, we're still using that kind of setup.