Fail-safe half-bridge

Question

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...)

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

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:

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:

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.

Answer 1

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.

Answer 2

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.