A while back I did a post about controlling a hospital bed with a robotic button pusher and then voice activating it. That can be a useful method if for some reason the bed controls can not or should not be modified. But in cases where you can modify the bed controls, this can simplify the solution and remove some possible points of failure. Here’s a video of one implementation in action:
The individual I built this for had great voice recognition success with Amazon Echo and was already using that for other things like controlling lights in her apartment so for this first go that’s what we also used to control the bed. Similar to my voice activated window shade project, voice commands are picked up by Echo and sent to a Photon board via IFTTT.
Even though the bed is now voice activated, there are times an aide will want to still be able to control the bed with a controller for more direct control. Also if there’s some issue with the voice activation you want a fallback. To facilitate this I repurposed the controller as an input to the new system. In this way both voice and the controller can control the bed.
NOTE: the original bed controller for this bed is directly in the current path of the motors. The original controller simply had relays in it that were button actuated. Each pair of buttons (relays) forms an H-bridge to control one of the motors under the bed. Significant current and voltage (48V) goes directly through this handheld controller and to the motors.
Below are some pictures of the original prototype wiring. The electronics perform the same functions that the original bed controls did but these can also be activated by voice. This new setup also has a set of relays, wired up the same way to the bed control wiring, but they are triggered by an Arduino board waiting for voice commands.
NOTE: Given the high DC voltage, you need to add flyback diodes to the relay outputs as pictured.
If you don’t then the flyback voltage from the inductive load (motor) will arc across the relay contact gap and burn it out. After a while the relay will begin to work only intermittently, and eventually stop conducting altogether.
Here are a set of relay contacts from the original prototype I abused by not including flyback diodes. I’ve cracked open the plastic casing and pried apart the contacts to show the type of contact damage that the arcing will cause over time. For comparison are close-ups from the heavily used relays on the left and the barely used one on the right.
Here are some pictures of the cleaned up project in a proper plastic enclosure. In this final setup only the head motor is voice activated as per the user’s preference. The other 2 motors are still directly wired to the controller. NOTE: To allow the head motor buttons to act as inputs to the MCU I removed the NO contacts on just those relays (buttons) so that they would not attempt to connect the MCU’s input pins to the high motor voltage.
Original Bed Control Wiring
For each of the movements, the corresponding wire should connect to GND when OFF, and connect to VDD when ON.
- Lt Blue -> S1 -> Head Up
- Dk Blue -> S2 -> Head Down
- Pink -> S3 -> Feet Up
- Purple -> S4 -> Feet Down
- Yellow -> S5 -> Bed Up
- Brown -> S6 -> Bed Down
- White -> GND
- Green -> VDD
Below is the main motor under the bed including the cable to the bed controls and the cable to the secondary motor. NOTE: kept in the room is a second unmodified bed controller. If for some reason the new setup breaks, it can be unplugged and the unmodified controller can be plugged in to replace it until a repair is made. As much as possible fallbacks must be in place so the user is not stuck in a bad situation.
This particular setup does have several dependencies and risks which must be evaluated for the the user’s exact situation. First are the network dependencies which amount to the internet connection in the user’s living space, the WiFi router, Amazon’s Alexa servers, IFTTT’s servers, and Particle’s servers. If any of these are down, the bed will not operate by voice until those are restored. Note that there are several means of voice recognition that do not rely on the internet, but those must be evaluated with the particular user.
Lastly, the outcome of a malfunction must be understood and weighed, in this case the bed moving when it shouldn’t, or not moving when it should. If a malfunction would only be inconvenient, that’s a different conversation than if a malfunction would be harmful.