I've been thinking about this for a while now, to use in the powered jaw of some publicly accessible, human-sized animatronics. I want a lot of force to be available to move quickly, and to demonstrate some decent bite strength, all with feedback to a human operator, but I don't want any excuse to bite someone's hand off by accident.

Thus, no excuse to ever have the output higher than intended, regardless of component failure or bad sensor data or cosmic-ray bit-flip or whatever else might happen. EVERY failure mode must result in the output going LOW and staying there.

I haven't completely nailed down the choice of parts yet, including the actuators, but I do want a direct-drive electric thing like a solenoid or Nitinol wire or something like that. A motor and gearbox is too noisy - hobby servo, for example - I've seen/heard those, and it ruins the effect.

Update Sep. 14, 2022:

This is the result of a different forum suggesting that I look at automotive power steering, following that path for a while, and eventually designing my own again around the concepts that I saw there because TI's detailed documentation - what you need to know to actually make it work - is behind an NDA. (What's the average hobbyist supposed to do? Make things dangerous? Seems to me like a repeat of the U.S. creating the Hindenburg by refusing to sell Helium, but anyway...)

enter image description here

Instead of doubling up two half-bridges on top of each other and trying to coordinate them (essentially making it so difficult to not blow the fuse, that if anything goes wrong at all, it does), this one has two cascaded bridges. The first is designed for DC, and has its own boosted gate supply to do that, and the second is the traditional bootstrapped half-bridge that we're all used to, but with some extra monitoring tacked on.

The feedback is also non-redundant now, but the monitoring still is. The idea is that a feedback failure won't behave as if it were working, and so the software will see that and kill the output in several different ways at once.

Also, the two MCU's having different jobs now, and only monitoring each other (all inputs go to both, and all outputs also become inputs for the other, in addition to the communication cross-links) means that they're running different software, and can even be different part numbers or even brands. If they're different, and there's a problem with a particular batch, it won't affect both of them at once.
(they're identical here because I'm only interested in the general architecture so far, and it was easier to re-use the same symbol)

The operator's force-feedback is controlled by a second copy of the output half-bridge, and by the same MCU that controls the main actuator. Only one copy is shown here. If there's a failure that allows it, both can let go gracefully, and if everything needs to die now (fuse, or the supply bridge shuts off), it all goes together.

As before:

Have I made any mistakes in my analysis?
Can you see any other potential failure points that leave the output high?
Or further simplifications without introducing such a failure point?

Previous versions:

Version 1, Aug. 19, 2022

enter image description here

I think it would work, but it seems a bit "Rube-Goldberg-y" to me. But if that's how it has to be, then that's how it has to be.

It's essentially two half-bridges superimposed on each other to drive one single-ended output, but each is still controlled by its own separate MCU. (I haven't chosen one yet; this is still in the concept phase.) Only the clock and external sync signals are shared as inputs. Everything else is redundant hardware, including the sensors for both intent and actual behavior, and the MCU's constantly cross-check each other. If either of them detects too much of a difference, it latches itself low and tells the other to do the same. Otherwise, they take the minimum output command just to be exactly equal. If they try to drive differently, the resulting shoot-through blows the fuse.

The entire block to the right of the two high-side FETs is to detect if one has failed short and the other hasn't yet. There's a separate copy for each MCU, but only one is shown here. The MCU's configure their internal hardware to force the output low when that happens, in addition to checking it in software and clamping the PWM duty cycle to zero, and telling the other to shut off too.

Status information (which includes faults) is reported to a supervisor that is not shown here. It's only a supervisor, with no control. This safety-critical function operates entirely on its own, without sharing anything that might interfere.

Version 2, Aug. 22, 2022

Then I realized that the series high-side FET's that were meant to shut it off even if one failed short, would also prevent it from blowing the fuse if the two controllers disagreed. So here's the second version with that fixed, which in turn eliminates the single-failure detector:

enter image description here

It seems odd now at first glance, to have a redundant pull-high, as that's exactly the stuck condition that I want to avoid. But considering

  • the R-C "return to off" between the MCU's and the FET drivers
  • the firmware itself not allowing 100% duty cycle anyway, to keep the drivers' bootstrap capacitors charged

the only unhandled single failure that I can think of is if one were to fail open/off and its parallel partner continues to work. (could be a literal FET failure or a driver failure) Any one failing short/on would now blow the fuse, same as a disagreement.

Even if both low-side FET's were to fail open, the circuit still works via their body diodes. (assuming they haven't been vaporized too) Only if a high-side then fails short do I have a problem, in that order. Any other order would blow the fuse.

I wonder how to detect a stuck-open FET in this arrangement?
Or at the very least, two stuck-open low-side FET's?

Version 2b, Aug. 23, 2022

And here's an answer to that. Not necessarily the best answer, but an answer nonetheless:

enter image description here

The idea here is to detect the raw switched node going below GND by a diode drop or more, which would mean that neither low-side is on. I figured that since a fair number of MCU's now have internal analog comparators that can be fed from an internal DAC, I could use that to get a binary pass/fail out of it.

Test it periodically, by intentionally turning off all 4 FET's while the load happens to have some current already. (each MCU turns off the 2 that it's in charge of, on the same schedule) See if that trips the fault detector. If it doesn't, then the detector doesn't work. Shut down immediately and report that failure to the supervisor.

  • 2
    \$\begingroup\$ You're right in that it is Rube-Goldberg. You're way over complicating things. Use weaker motors, use a mechanical solution, or add something to disable the H-bridge. Don't build it into the H-bridge itself other than something like current limiting which helps but shouldn't be relied on for safety. \$\endgroup\$
    – DKNguyen
    Commented Aug 19, 2022 at 3:42
  • \$\begingroup\$ Disabling the bridge might be good, instead of building everything together. The other parts I have difficulty seeing how they would fit into the overall idea. There will likely be situations where a potentially harmful force is actually desired, on something other than a person, and then without time to reconfigure, a random hand goes in, that absolutely must not be hurt. This is controlled by a human operator that can see what's happening, in addition to force feedback, so we don't have an automation problem. \$\endgroup\$
    – AaronD
    Commented Aug 19, 2022 at 4:32
  • 2
    \$\begingroup\$ But at the end of the day, there will be no 100% safety. The "safest" rate defined for a TFFR (tolerable function failure rate) to achieve is 1 error in 10^8 hours of operation. The TFFR can be calculated from the THRs (tolerable hazard rate) of the components. Another technical term to search for concerning hardware is the unit "FIT" (failure in time), the reciprocal of THR. \$\endgroup\$ Commented Aug 19, 2022 at 6:12
  • 2
    \$\begingroup\$ One machine I have, which is quite capable of severing a human hand, has three separate independent interlocks to prevent that from happening. One electrical, one hydraulic and one mechanical. Of course they can easily be defeated (or gone around) if you really want to, but it has to be a deliberate act. And that's on top of the control system which should detect the obstruction and result in a somewhat mangled but not severed hand in the worst case. \$\endgroup\$ Commented Aug 19, 2022 at 14:03
  • 1
    \$\begingroup\$ @DKNguyen Well, I finally took your advice. Single half-bridge now, with a disable-able power supply. \$\endgroup\$
    – AaronD
    Commented Sep 14, 2022 at 22:58

2 Answers 2


If you have the ability to modify the mechanical components, then you could mount both the upper and lower jaws to normally closed pushbuttons.

Set up the pushbuttons so that the contacts open if more than a certain amount of force is put on either the top or bottom halves of the mouth. Wire both switches in series and have them power the motor.

Then if either the top or bottom of the jaw is pressed, then the motor power disconnects.

enter image description here

  • \$\begingroup\$ You probably also want to wire up the relays to latch once they are triggered which means using DPDT relays...or to just use latching relays. Not unlike E-stop button circuitry. Instead of pushbuttons, they make things specifically for stuff like this called "limit switches" which have long levers to minimize activation force and to also move the activation point away from the surface which gives it some safety space. \$\endgroup\$
    – DKNguyen
    Commented Aug 19, 2022 at 3:46
  • \$\begingroup\$ Leave it to the community to come up with something I hadn't thought of. :-) In this case though, what I hadn't thought of is a requirement that I simply assumed was understood. I want to have some bite strength too, as well as fast movement, so it's a bit more nuanced than just limiting force or travel against an object. The operator will have force feedback, so he knows that there's something there and how squishy it is. And depending on the situation, he might want to squish it. I just don't want something to fail in a way that exaggerates or overrides the operator's intent. \$\endgroup\$
    – AaronD
    Commented Aug 19, 2022 at 4:25
  • \$\begingroup\$ If we make the assumption that the maximum force needed for fast movement and squishing some stuff is below the force needed to damage a finger, then you can just use a spring to set the max bite force to whatever you want that's under that safe range. \$\endgroup\$
    – user4574
    Commented Aug 19, 2022 at 15:22

This doesn't sound like a good idea. The problem with force feedback is that it still won't provide the operator with feedback required for safety. It needs to provide 1:1 force feedback so they operator knows in a human context how much pressure is applied. So a display won't work, nor will a traditional tactile control like a knob or lever with force feedback. You would almost need an ergonomic hand or finger pinching pendant with force feedback.

But then there is the problem that you also want enough force to quickly close a potentially heavy jaw. So the forces are no longer in human context anyways and with high-speed you also have the problem of INERTIA. So now you're intentionally putting the operator in a position where they need to know their own strength but can't.

Mechanical stops so it cannot close all the way are below the bare minimum and thus utterly insufficient, but I'm guessing you don't want those because then the jaw can't close all the way for display purposes when nothing is in it.

At minimum you should:

  • build pliability into the jaw via rated springs somewhere with mechanical stops to prevent over compressing the springs (but still allow visible closure when nothing is in the jaw) so at worse the pressure is mechanically limited to some value of pressure. You need to work out the size of the arm to use in the calculations since smaller arm = less area = more pressure but at the same time will be thinner so the springs are compressed less = less force. Depending how much sprung mass and speed there is, is you also want retainers/stops to hold the springs at or below the unsprung length so they can't snapping outwards under speed. The force and pressure will also change as you move closer to the hinge so you may need to use a range of springs.
  • Then you build shutoff limit switches into a range where the spring compression should not be entering.

Don't neglect the inevitable possibility of someone's hand not being perfectly centered between the top and lower jaws such that it gets smacked by one jaw first.

You can then use position sensors to measure spring compression to estimate the force for use in your control system in regular operation and wire these in a way so that if they fail short or open the system doesn't react inappropriately.

I would not stick my hand into anything less that I know has crushing force behind it. I don't care how carefully the electronics try and go about doing it.

Don't just make your system so that although it could bite off someone's hand it will not; Make your system so it cannot bite off someone's hand. Electronics can't do that. With electronics only safeties, it's kind of like someone pointing a loaded gun at you but saying "Don't worry, my finger is off the trigger."

Bonus points if there are teeth you can subtly build these springs and mechanical stops into.

There will likely be situations where a potentially harmful force is actually desired, on something other than a person, and then without time to reconfigure, a random hand goes in,

No. Just no. Don't do this.

  • \$\begingroup\$ I was wondering about inertia as well. +1 for explicitly saying it. My hope was that the fast movement would be small enough that the full (intended) motion would be okay even if someone got their hand in it, thus making the force in that context irrelevant, and that an intentional crush would be slow enough that inertia isn't such a factor. That may not be true though. I'll have to think about it some more. \$\endgroup\$
    – AaronD
    Commented Aug 19, 2022 at 15:55
  • \$\begingroup\$ @AaronD Also consider someone might stick their head in it if big enough. People do dumb shit for photos. Even springs and stops won't protect against that. \$\endgroup\$
    – DKNguyen
    Commented Aug 19, 2022 at 15:56
  • \$\begingroup\$ Yes! That was my original reason for making it fail-safe to start with. If it's publicly accessible, then someone WILL get into it. Therefore make it guaranteed to not hurt them unintentionally, regardless of why. \$\endgroup\$
    – AaronD
    Commented Aug 19, 2022 at 15:58
  • \$\begingroup\$ @AaronD Maybe some cross bar guide to divide up a large opening so even with a large opening a head literally can't fit in. If the model suits it, maybe a tongue arranged and protruding the correct way to prevent a large object from getting too deep. \$\endgroup\$
    – DKNguyen
    Commented Aug 19, 2022 at 16:06
  • \$\begingroup\$ I thought about something else that might be a misunderstanding. If you're thinking of a full-size dragon with hydraulics or similar, then even the warnings you gave here would be woefully inadequate. But this character is human-sized, probably with direct-drive electric actuators. (solenoid, Nitinol, etc.) Even contemplating to make it a costume, hence the battery designations for the power supply. It does have a muzzle, so there's still the possibility to (barely) get someone's head in it, but I think the scale is small enough to allow at least some use of the operator's existing instincts. \$\endgroup\$
    – AaronD
    Commented Aug 19, 2022 at 17:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.