PDA

View Full Version : k-9 project



Baylink
11-17-2013, 10:52 AM
Yes, I'm starting at the wrong end of the size spectrum. :-} This project is only peripherally "about" robotics.

It is said that you never forget your first Doctor. You never forget his dog, either, and I've wanted one for some time. I think it's time.

This kind UK gent (http://www.instructables.com/id/Podpadstudios-K9-Dr-Who/) was good enough to post a set of takeoffs to give me size and dimension, and my goal (unlike, it seems, most k-9 builders) is to build a pet, not an R/C car.

That means he'll have to last most of the day on a traction motor charge, and cope with carpet and a step or two; curbing and front stoops; I don't live in a 2 story house. I live in Florida; not much has 2 stories. :-)

I have a bunch of introductory questions, which I will pose here in a single thread, and then as things get more in-depth, I'll move off to the topical forums. Feel free to reply to any parts of this on which you have an opinion; this is my first rodeo in robotics, but I was licensed as a ham in 1979, and have been an IT pro for 30 years... and I will have experienced help on chassis and body work from a filmmaker friend who builds Halo armor on his vacuum-former for a living. In short: I know just enough to be dangerous about almost everything about robot-building... except the electrical part, where I actually know enough not to be dangerous. :-)

So; to the questions:

1) I understand that the fundamental design decision to be made is weight/batteries/motors -- it's like rocketry; after a point, you're adding fuel just to lift the fuel. My initial design was 2 Group24 12v83Ah AGM batteries in series, at about 110lbs, which would give me on the order of 5h traction time at 100% duty, or roughly all day in the real world. That was about $300 worth of batteries. But then I found Golden Motor, who have a 48v20Ah LifePo pack for about $600 (http://www.goldenmotor.com/batterypack.htm) (their 4820 Easy Pack, halfway down the page)... which they would probably reconfigure for me as 24v40Ah... and at the sharply reduced weight of both batteries and motors, 40Ah would probably get me close; that's about 40lbs of battery pack, and also sharply smaller, leaving more room for my traction motors. I got most of my ideas about battery/motor usage and runtimes from this calculator (http://www.robotshop.com/blog/en/drive-motor-sizing-tool-9698), which may or may not be accurate, and which I wish was actually one column of a spreadsheet, so I could do multiple iterations of a design and compare them. Is that calculator in the right general vicinity, and does anyone already have that spreadsheet, or something close to it? :-)

2) Climbing steps is a bitca, and I can't decide which of several approaches will be a) easiest and b) cheapest to implement and c) most reliable once implemented. I'm aiming for tired 4WD rather than tracks or anything fancy; the implementation is constrained by the design: it *must look like* k-9. So the wheel size, track and wheelbase are constrained by the body design -- it's 18" wide, 18" tall, and 29" long *at the floorpan*; the sides slope in, so I need to cut at least 2" off each of those, if not more, to fit inside. I can probably make each of those dimensions 2" larger, possibly 3", without setting off people's "monkeyed with" detectors, if I absolutely have to. The approach I was looking at most seriously was "tripod wheels"; a 3-armed spider on a pivot axle, with a wheel at each leg's end. The problem with that is drive complexity: either gearing or single-belt drive is going to fill in precisely the parts of that spider I need to be open to clear a step, and 3-belt or chain drive is likely to either become so much bigger as not to fit in the available space or lose so much torque as to be a non-starter. Such a spider would have to be mounted on something that could lift the entire robot up so it's skirt would clear the curb before pushing forwards... which makes things even more exciting. Any thoughts on either how to implement that serviceably, or other approaches to being able to climb steps with landings long enough to stop on?

3) I saw the Syren and Sabertooth motor controllers from Dimension Engineering (http://www.dimensionengineering.com/products/sabertooth2x12). and absolutely fell in love with both the product, and the attitude of the two CMU grads who run the company. Up to 8 dual-channel motor controllers on one RS-232 link from the CPU? Genius! Only one problem: I *also* came across these motors from Golden (http://www.goldenmotor.com/frame-bldcmotor.htm) (the 57 and 90 frame ones, particularly), and these motors from Motion King (http://www.motionking.com/Products/DC_Motors/56JBX-57BLDC_planetary_gear_motor.htm), and they (particularly the latter, with built in planetary gearing) are gorgeous. And, apparently, relatively inexpensive.

Alas, they're also brushless, and Dimension doesn't make BLDC controllers, and all the BLDC motor controllers I *can* find are either a) R/C *specific* (control interfacing and such, and they're heat-shrinked), or b) $500 (Roboteq, etc). Anyone have a pointer to a BLDC motor controller that has bussable control less complicated than CANBUS, in the 10A continuous/$50-75 class?

4) Since this will be an autonomous robot, and my major skill is gluing together the output of *other* smart people, I hunted around, and found ROS... just in time to discover that major sponsor Willow Garage had all it's employees absorbed by its founder's other company, Suitable Technologies (presumably the one that was making money, in telepresence), and there's no clear announcement how that will affect the ROS project. Anyone got any inside track on that? Or experienced opinions on the competing projects and how complete they are? I'm not exactly an appliance operator, but I'm not a CS or Robotics major either, and I may be too old to become one.

5) On the next layer of that cake, what do we like for CPUs/mainboards for that class of smart bot? I've looked at the Gumstix stuff, and I have an RPi; haven't looked at the Beaglebone boards yet... but I want something with a (preferably RPM based) linux distro factory supported on it, and enough I/O to matter, that still won't quite break the bank power-budget-wise. I propose to have a separate 12V power system just for the electronics, with its battery charged by stepdown from the 24V buss, so that the robot can still scream for help even if it can't move anymore, but that will probably be 12v18Ah-ish; not a lot of power.

6) What else should I have asked, but I didn't? :-)

Thoughts, information, and opinions all welcome.

tician
11-17-2013, 01:48 PM
1) Sticking any lithium-based battery in parallel is tricky and potentially very dangerous. If the cells are not capacity and impedance matched, they will charge and discharge at different rates that cause, at minimum, balance issues and, in worse cases, can cause over-charge and over-discharge issues leading to damaged/dead cells. LiFePO4 are already kinda prone to balance issues, so it would probably be better to just go with 40Ah cells instead sticking two 20Ah cells in parallel if you really do need that much capacity. Batteryspace, all-battery, and a couple other places sell the larger capacity prismatic cells, but not always with the built in battery monitoring systems.
How much abuse do you really expect the motors to be dealing with? Most of the motor power ratings are maximum continuous draw and probably not what will be encountered over most of a normal day's use unless the bot is continuously running back and forth between different locations in the house.

2) Tri-star wheels are pretty cool, but require a bit of clearance so would require the body of the bot to lift up quite a bit when attempting to traverse a step (have the body separate from the chassis with a scissor lift or linear actuators to push the body up so it does not crash into the step). I do not really know of any methods that would allow you to keep the body anywhere near flush with the floor while attempting to make it over a step.

3) There are a lot of BLDC controllers out there for automation purposes, but not many that do not run into the several hundreds of dollars. There are a few open-source BLDC motor driver boards, but not thinking they were meant for traction motors. This MIT grad (http://www.etotheipiplusone.net/) has made some rather interesting BLDC motors and controllers for various ground vehicles, but I have not checked any of his recent projects.
On the brushed DC motor front, there are plenty of planetary gearmotor kits available from the likes of AndyMark and BaneBots. The various Dimension Engineering motor controllers are often used with them and similar motor setups.

4) Stewardship of ROS was transferred to the Open Source Robotics Foundation (http://www.ros.org/news/2013/02/ros-osrf.html) a while back, and there multiple university and industrial/commercial developers in addition to WillowGarage and UnboundedRobotics. One of the forum members has a book (http://www.pirobot.org/) on learning ROS that might be useful. As for alternatives, there are several open source projects out there and some are often used together with ros (like player and gazebo). Beware: Microsoft Robotics Development Studio has been mostly abandoned by Microsoft.

5) A couple of us have used various versions of the Zotac Zbox and there are several others who are using the Intel NUC. Being x86 computers, they can be up and running with pretty much anything you want quickly and easily. They require somewhat clean 19V power, but there are plenty of DC-DC converters on amazon and other places that can usually handle the power requirements well enough. The adapter for my ZboxNano AD-12 is rated 19V 3.4A, but I don't recall it ever really pulling more than about 30W under load. The AD-12 actually weighs less than the AC adapter to one of the new Dell laptops in the lab.

6) Sensors.
Cliff detection would be useful to keep it running off a step when it is not ready, and bump sensors are nice when vision fails to identify obstacles (glass doors and/or debris on the floor).
The kinect and asus xtion are popular and quite affordable for vision, and the depth data is very useful in navigation. If don't want the kinect/xtion to break the aesthetics and you want to use only a webcam, then a planar laser rangefinder would probably be very useful for map-making and navigation with ROS. Some people buy a Neato vacuum and pull the rangefinder from that since it is still less than most commercially available rangefinders (Hokuyo modules are $1100~$6000 each). Another alternative is the PML (Planar Meta Laser) which is basically a Sharp rangefinder attached to the horn of an AX-12 and panned back-and-forth to give coarse 'laser' scans to ROS. The PML package for ROS was deprecated quite some time ago, but it is not too difficult to replicate.

jwatte
11-17-2013, 02:30 PM
I used the Zbox and it's small and nice. For something that has 60 pounds of batteries, though, you might as well go for a full mini-ITX motherboard.

I like LiFePO4 batteries A LOT, as long as you have the proper BMS. They are a lot safer than LiPos, and a lot lighter than NiMH or SLA.

You can turn an RC BLDC motor controller into a serial-controlled controller by using a small microcontroller, such as an ATTiny85 or something pre-fabricated like a Arduino Nano. The code to make that happen isn't particularly tricky.

Baylink
11-17-2013, 06:16 PM
1) Sticking any lithium-based battery in parallel is tricky and potentially very dangerous. If the cells are not capacity and impedance matched, they will charge and discharge at different rates that cause, at minimum, balance issues and, in worse cases, can cause over-charge and over-discharge issues leading to damaged/dead cells. LiFePO4 are already kinda prone to balance issues, so it would probably be better to just go with 40Ah cells instead sticking two 20Ah cells in parallel if you really do need that much capacity.

So their 48v20 is actually 14 or 15 3.4v20 cells? Oh. Yeah, I guess that makes sense.

And yeah, I hadn't thought about the fact that they wouldn't already be in parallel.


Batteryspace, all-battery, and a couple other places sell the larger capacity prismatic cells, but not always with the built in battery monitoring systems.

I'm not done looking around, certainly. I need to get the aforementioned capacity spreadsheet worked out so I can more intelligently compare all the possible approaches.


How much abuse do you really expect the motors to be dealing with? Most of the motor power ratings are maximum continuous draw and probably not what will be encountered over most of a normal day's use unless the bot is continuously running back and forth between different locations in the house.

Well, if I use tri-star wheels, with*out* actuators to rotate them over the steps -- the "just bash into the step and let it rotate over" approach -- then that will probably be the hotspot. I'm looking at 7.5 ft/sec, or about 5mph, top speed, with 1-2 second accel to top speed, though I don't envision it moving at top speed 100% of duty cycle, obviously.


2) Tri-star wheels are pretty cool, but require a bit of clearance so would require the body of the bot to lift up quite a bit when attempting to traverse a step (have the body separate from the chassis with a scissor lift or linear actuators to push the body up so it does not crash into the step). I do not really know of any methods that would allow you to keep the body anywhere near flush with the floor while attempting to make it over a step.

Sure. I had planned on, probably, mounting the entire tri-star assembly on a frame that I could raise the body up off of with a worm-rack drive of some type; I hadn't gotten quite that far in the mechanical engineering, as it depends a lot on the motor and tire sizes, which I haven't locked yet, and the body construction, which likewise.


3) There are a lot of BLDC controllers out there for automation purposes, but not many that do not run into the several hundreds of dollars. There are a few open-source BLDC motor driver boards, but not thinking they were meant for traction motors. This MIT grad (http://www.etotheipiplusone.net/) has made some rather interesting BLDC motors and controllers for various ground vehicles, but I have not checked any of his recent projects.

Dan Strother has a really gorgeous board (http://danstrother.com/2011/01/12/brushless-dc-motor-controller-board/) that probably has enough power for the 50-75W traction motors I think I'll need, but it's just a layout and parts list, and I'm not sure I'm up to SMC construction.


On the brushed DC motor front, there are plenty of planetary gearmotor kits available from the likes of AndyMark and BaneBots. The various Dimension Engineering motor controllers are often used with them and similar motor setups.

Yeah, I know. I'm not all that fond of the idea of brush motors, if I can have brushless, for both the maintenance (getting them out of those wormgear cages won't be fun) and intrisic safety (brushes make sparks) reasons. But if I gotta pay $300 for a controller for a $50 motor, then yeah, that's a forcing reason.


4) Stewardship of ROS was transferred to the Open Source Robotics Foundation (http://www.ros.org/news/2013/02/ros-osrf.html) a while back, and there multiple university and industrial/commercial developers in addition to WillowGarage and UnboundedRobotics. One of the forum members has a book (http://www.pirobot.org/) on learning ROS that might be useful. As for alternatives, there are several open source projects out there and some are often used together with ros (like player and gazebo). Beware: Microsoft Robotics Development Studio has been mostly abandoned by Microsoft

I wouldn't ever go near the MS thing, no matter how nice it was. :-) Been a Unix guy for 33 years, for really good reasons. I will check out the book; thanks for the pointer. I noted some of the compatible projects like Player that they mention on their wiki.


5) A couple of us have used various versions of the Zotac Zbox and there are several others who are using the Intel NUC. Being x86 computers, they can be up and running with pretty much anything you want quickly and easily. They require somewhat clean 19V power, but there are plenty of DC-DC converters on amazon and other places that can usually handle the power requirements well enough. The adapter for my ZboxNano AD-12 is rated 19V 3.4A, but I don't recall it ever really pulling more than about 30W under load. The AD-12 actually weighs less than the AC adapter to one of the new Dell laptops in the lab.

I'll check both of those out. Do you have any feeling for whether power usage is a reason to be looking at ARM based stuff at that form-factor-size? Is there any? Or should I just go for Intel/AMD based stuff? Make my Linux distro issues a lot easier, certainly.


6) Sensors. Cliff detection would be useful to keep it running off a step when it is not ready, and bump sensors are nice when vision fails to identify obstacles (glass doors and/or debris on the floor).

A cliff sensor would be "aim IR at the floor, and if it stops bouncing back, Emergency Stop while you think about it"?


The kinect and asus xtion are popular and quite affordable for vision, and the depth data is very useful in navigation. If don't want the kinect/xtion to break the aesthetics and you want to use only a webcam, then a planar laser rangefinder would probably be very useful for map-making and navigation with ROS. Some people buy a Neato vacuum and pull the rangefinder from that since it is still less than most commercially available rangefinders (Hokuyo modules are $1100~$6000 each). Another alternative is the PML (Planar Meta Laser) which is basically a Sharp rangefinder attached to the horn of an AX-12 and panned back-and-forth to give coarse 'laser' scans to ROS. The PML package for ROS was deprecated quite some time ago, but it is not too difficult to replicate.

Ok; cool. *Wow* those things are expensive. I have some time to deal with making those choices, I suspect, since none of them bubble up onto the critical path of power/size.


I used the Zbox and it's small and nice. For something that has 60 pounds of batteries, though, you might as well go for a full mini-ITX motherboard.

What I was thinking.


I like LiFePO4 batteries A LOT, as long as you have the proper BMS. They are a lot safer than LiPos, and a lot lighter than NiMH or SLA.

About a third the weight, it looked like, yes. I was not looking forward to 110 lbs of lead; if I can avoid it and only double the cost of the pack, I'll take that.

[quote]You can turn an RC BLDC motor controller into a serial-controlled controller by using a small microcontroller, such as an ATTiny85 or something pre-fabricated like a Arduino Nano. The code to make that happen isn't particularly tricky. [quote]

Yeah, I probably can, but I'm *really* trying to stay with packaged commercial stuff at the subsystem level whenever possible; I am not really a boardlevel guy.

Thanks for the thoughts, gents.

Baylink
11-17-2013, 08:00 PM
SCORE! Thanks for the keyword; I just found a good design (http://exhibit13.weebly.com/stair-climbing-robot.html) for a powered tri-star with good inter-tire clearance without a lot of moving parts.

tician
11-17-2013, 09:02 PM
LiFePO4 is 3.2V nominal, so 48V is 16S. The 12V 20Ah in Darsha is 4S1P at ~$140 shipped from batteryspace without BMS. Has not gotten much use since Darsha's rebuild is somewhat stalled and have not been doing any NIR spectroscopy in the lab recently (power for an IR light source).

I know I've pondered about other designs, but I don't think I've seen any implementation of tri-star wheels that does not just use a center axle that is linked to the three wheels using some combination of gears and/or chains arranged so that when the first wheel slides into a pothole or hits a rock, the wheels stop rotating relative to ground as the spider starts rotating forward until the top wheel hits the hole or rock and the spider can no longer rotate forcing the wheels to start rotating again and climb over the obstacle. I'm pretty sure that is the major draw of the tri-star wheel, the obstacle compensation is achieved without the need of any active control system or additional actuator. I could see there being an internal shaft driving only the wheels through gears/chains in the spider and a second hollow shaft driving the spider, to permit a much more controlled ascent of stairs. I seem to remember something from a GITS episode: force the wheels to drive very carefully along the steps while using the spider to balance the wheelchair during ascent.

7.5 fps is pretty fast for a large-ish bot. There are mouse-size maze solvers that zip around at high speed, but most bots larger than that do not do well at high speeds in confined spaces around easily damaged objects (walls, tables, doors, people, etc.). The somewhat common speed limit for larger robots is about 1 m/s, but usually moving quite a bit less than that unless in a wide open space known to be clear of obstacles.

I understand the appeal of BLDC. I have been looking for a BLDC and P60 gearbox combination to upgrade Darsha for a while, but the controller cost has been a sticking point. Still have not gotten around to finishing an attempt at a custom controller/driver board. Recently tempted to just make a quick and dirty driver board to stack on a CM-904 to control it all through USB or dynamixel bus.

The main reason I've seen for going x86 is reaching the processing limits of the RaspberryPi. Not sure about the BeagleBoneBlack or the dual/quad-core ARM board some of the others have been using, but access to more than 1GB of RAM and a SATA SSD are certainly useful for the really memory and processing intensive tasks.

There are lots of ways to go with cliff sensors, but the simplest and most reliable are usually just some sort of IR reflectance sensor. The nicer ones use a triangulating system instead of just measuring intensity of reflected light. There are a few companies like Pololu and DFRobot that sell breakout boards for some of the newer Sharp digital output sensors that simply output high or low depending on whether the calculated distance of the object is more or less than some limit value.

Baylink
11-17-2013, 09:25 PM
LiFePO4 is 3.2V nominal, so 48V is 16S. The 12V 20Ah in Darsha is 4S1P at ~$140 shipped from batteryspace without BMS. Has not gotten much use since Darsha's rebuild is somewhat stalled and have not been doing any NIR spectroscopy in the lab recently (power for an IR light source).

Hmmm...


I know I've pondered about other designs, but I don't think I've seen any implementation of tri-star wheels that does not just use a center axle that is linked to the three wheels using some combination of gears and/or chains arranged so that when the first wheel slides into a pothole or hits a rock, the wheels stop rotating relative to ground as the spider starts rotating forward until the top wheel hits the hole or rock and the spider can no longer rotate forcing the wheels to start rotating again and climb over the obstacle. I'm pretty sure that is the major draw of the tri-star wheel, the obstacle compensation is achieved without the need of any active control system or additional actuator. I could see there being an internal shaft driving only the wheels through gears/chains in the spider and a second hollow shaft driving the spider, to permit a much more controlled ascent of stairs. I seem to remember something from a GITS episode: force the wheels to drive very carefully along the steps while using the spider to balance the wheelchair during ascent.

Yeah; I'm seeing that now; I wasn't sure if it needed to be powered for the outside rotation or not. Since I'm not trying to go up full staircases, I probably don't have to be as concerned about that.


7.5 fps is pretty fast for a large-ish bot. There are mouse-size maze solvers that zip around at high speed, but most bots larger than that do not do well at high speeds in confined spaces around easily damaged objects (walls, tables, doors, people, etc.). The somewhat common speed limit for larger robots is about 1 m/s, but usually moving quite a bit less than that unless in a wide open space known to be clear of obstacles.

I want it to be able to outwalk me, if necessary, but as I say, I don't expect it to be going more than about 30%FS most of the time.


I understand the appeal of BLDC. I have been looking for a BLDC and P60 gearbox combination to upgrade Darsha for a while, but the controller cost has been a sticking point. Still have not gotten around to finishing an attempt at a custom controller/driver board. Recently tempted to just make a quick and dirty driver board to stack on a CM-904 to control it all through USB or dynamixel bus.

Are BLDC motors that unpopular in the robotics field? Why are all the controllers all so expensive?


The main reason I've seen for going x86 is reaching the processing limits of the RaspberryPi. Not sure about the BeagleBoneBlack or the dual/quad-core ARM board some of the others have been using, but access to more than 1GB of RAM and a SATA SSD are certainly useful for the really memory and processing intensive tasks.

Quite so. And those things are stupidly cheap these days. 16GB, 6 SATAs and 10 USB 2's...


There are lots of ways to go with cliff sensors, but the simplest and most reliable are usually just some sort of IR reflectance sensor. The nicer ones use a triangulating system instead of just measuring intensity of reflected light. There are a few companies like Pololu and DFRobot that sell breakout boards for some of the newer Sharp digital output sensors that simply output high or low depending on whether the calculated distance of the object is more or less than some limit value.

Interesting.

I'm wondering if I want to just have an Emergency Stop buss that goes all over the bot, and lets any subsystem throw a flag if necessary. I guess they would have to say who and why, so the main processor would know how to proceed...

tician
11-17-2013, 10:31 PM
Emergency stop is essential. Don't build anything large without it. Lots of ways to implement it, but having the contact sensors and cliff sensors (and stop button) trigger the motor controllers to immediately cut motor power and brake then let the PC deliberate would probably be safest.



It is mostly that BLDC motors are kind of the newcomers in some ways, and brushed DC is old and reliable and easy to control, so why rock the boat?
Robotshop has a couple BLDC drivers/controllers, but those that are meant for robotics instead of R/C control still carry the industrial automation price tag. I have not really been able to find anything in a reasonably small package at a non-industrial price that easily permits control of direction and speed; just a bunch of unidirectional hobby and scooter ESCs, or the occasional hobby car/truggy/truck ESC that might have a reverse direction but probably not the desired voltage and/or current rating.

There are some biped robots that use BLDC, but the bot I am thinking of uses custom, water-cooled Maxon BLDC motors at relatively high voltage and very high current with a gigantic supercapacitor array to allow it to hop up and down. Purely a custom research bot in the many thousands of dollars, so industrial or custom controllers would be no issue.

Baylink
11-18-2013, 05:54 PM
Emergency stop is essential. Don't build anything large without it. Lots of ways to implement it, but having the contact sensors and cliff sensors (and stop button) trigger the motor controllers to immediately cut motor power and brake then let the PC deliberate would probably be safest.

The approach I had planned on was to put an ES relay between each traction motor controller and it's motor, that is held in by one of its own contacts that, when you open that loop, disconnects the motor connectors from the motor controller and shorts them together.

Assuming that the controller doesn't wig out from suddenly having the load yanked out from under it, that seems like it would work. Then you just put as many NC trips as necessary in series in the loop circuit, and any of them can trigger it -- one of which will be a totally independent RF receiver for the key fob in my pocket -- with its own battery.

Even at 50-60 lbs total, and only 18" tall, I still believe in safety.



It is mostly that BLDC motors are kind of the newcomers in some ways, and brushed DC is old and reliable and easy to control, so why rock the boat?

Well, except for the intrinsically safe issue, yeah; and I don't *actually* spend much time in environments where that matters, so...


Robotshop has a couple BLDC drivers/controllers, but those that are meant for robotics instead of R/C control still carry the industrial automation price tag. I have not really been able to find anything in a reasonably small package at a non-industrial price that easily permits control of direction and speed; just a bunch of unidirectional hobby and scooter ESCs, or the occasional hobby car/truggy/truck ESC that might have a reverse direction but probably not the desired voltage and/or current rating.

Yup. So I'll go back to the brushed motors. Do we have a list of good vendors/manufacturers around the forum somewhere?

jwatte
11-19-2013, 12:55 PM
put as many NC trips as necessary in series

Note that high currents make that a lot less feasible, because contacts start wearing/sparking for real above about 10A. Even always-closed, they will heat up because of contact resistance.

If you have a motor controller with an "enable" input, you can disable that pin with a transistor based on the input from your e-stop sensors; that should be robust enough for most purposes (especially as described here.)

Baylink
11-19-2013, 02:05 PM
Note that high currents make that a lot less feasible, because contacts start wearing/sparking for real above about 10A. Even always-closed, they will heat up because of contact resistance.

If you have a motor controller with an "enable" input, you can disable that pin with a transistor based on the input from your e-stop sensors; that should be robust enough for most purposes (especially as described here.)

I will check; I think the DE controllers actually use S2 for that when in digital mode. What I had meant, though, was to use a third contact on the ES relay *to hold the relay closed*. Anyone who wants to could open that line, and the system would go into Stop mode. And that's just a signal level contact.

Baylink
11-23-2013, 10:26 AM
[ checks ]

Yup; I was right; S2 in packetized serial mode is an active-low Emergency Stop with a pullup. They don't say you can tie them all together, but I sure hope so.