S is the name of my current robot and the robot is an evolutionary step towards building a device to act as a personal assistive device as I age.
There is unlikely to be an affordable service to provide for my care needs as I age, such as doing some household chores and some personal chores. So it seems my best bet is to invest in trying to invent a device that will do as much as I can make it do with the time and money I have available. I don’t expect a robot to be able to do everything I would like, but by enumerating some possible, valuable tasks, it will provide a vision to guide my invention. Tasks that would be useful include:
- The usual kind of smart table device, able to transport objects from one place to me or from me to some other place.
- The addition of some sort of gripper mechanism would enable the robot to actually pick up something, placing it in the smart table, or remove something from the smart table to be placed somewhere. Sample scenarios might include:
- Fetch me a beer.
- Get my mail.
- Put my shoes away,
- Clean the table and put the dishes into the dishwasher.
- Really ambitious gripper-based goals might be:
- Take out the trash.
- Take the clothes from the dryer, fold them, and put them in the dresser.
- Patrol my house interior and report to me issues I should know about. Sample scenarios might include:
- Look for objects strewn on the floor.
- Look for objects that have moved from their usual location.
- Look for unlocked or open doors and windows.
- Look for water on the floor.
- Look for smoke.
- Look for unexpected people.
- Look for unexpected temperatures.
- Stretch goals would include:
- Clean the toilet.
- Clean the floor.
- Dust the objects on shelves.
- Change a lightbulb.
- Notice that I am not responsive and call for help.
To perform any of those goals, I envision a slow evolution of capabilities for the robot. I have built several robots in the last few years, each one being built upon what I learned from previous robots and each one having a name starting with the next letter of the alphabet after the previous robot. This robot is called S and the previous robot is called Raven, giving you an idea of its evolutionary heritage. I will rename S at some point with a better name.
At the least, I expect S to be able to reliably move from where it is to an indicated spot in the house. Adding a gripper may involve significant mechanical redesign after required object weights and torques are determined. Designing a robot that only needs to fetch a beer is quite different from designing a robot that can load a dishwasher which is different from designing a robot that can pick me up from a chair. Sensor requirements will evolve as needs evolve. It is expected that mechanical needs will drive each rebuild of the robot more than software needs. Requirements like faster networks, or better network coverage throughout the house generally are solved with minor changes to the robot. Requirements to move a weight at the end of an arm without the robot tipping over are likely to be dominant mechanical concerns..
Of equal concern is the safety and trustworthiness of the robot. The predecessor to S, namely Raven, was largely an experiment in providing some safety features and providing some sense of trust. My robot will be useless to me if I cannot trust it to avoid smashing into my rather expensive glass walls or damage my one piece of expensive furniture or drop some hot liquid on me.
Some safety and trustworthiness issues for the robot include:
- The robot should be able to reliably boot up and shutdown.
- The robot should be able to reliably detect obstacles to its movement and avoid bumping into furniture, walls, people and so on.
- The robot should be able to reliably detect that power is going to be depleted and perform an action to either recharge itself or put it in a safe state so that it can be recharged.
- The robot should fail safe in most common failure situations, including:
- Any sensor fails.
- Any communication path fails, such as a signal wire, the WiFi network or the Ethernet network.
- The battery voltage nears some low discharge voltage.
- The battery voltage is above some safety margin.
- The wheels get entangled with wires or other debris.
- One or more of the power converters fail.
- A motor draws too much current.
- A motor rotates unexpectedly fast or slow.
- Any part of the robot overheats.
- The robot’s intended path is blocked with no easy way to get unblocked.
- The robot ends up in a pose that prevents normal operation, such as falling over, or a wheel falling off.
- One or more of the control devices no longer communicates as expected, such as a CPU crash or a device getting fried.
- An independent (not the main CPU) analysis of the proximity sensors detects an imminent collision of the robot with some object, so the robot gets an emergency stop signal until some person can intervene.
At a minimum, S is expected to be significantly improved over it’s predecessor in its reliability (it fails seldom), robustness (it can fail safely) and safety (it can be trusted not to do bad things), and be able to autonomously move to any place in the house that doesn’t require pushing the boundaries in an unreasonable way, such as needing to pass through a impossibly narrow passage or pass over an obstacle that would raise one of the wheels so it no longer could contact the floor.
Presenting S
Here is S as it exists as of today.
The frame is made from 2020 aluminum extrusions and aluminum plates. The open frame design allows me to somewhat easily get at the internal wiring, which still changes from time to time. There are a pair of 8 inch wheels (200 mm) mounted under the centerline of the bottom plate. A pair of caster wheels underneath prevent the robot from tilting too far forward or backward.
A large LiFePO4 battery is placed in the back of the bottom plate to weigh the robot so it sits on the back caster, tilting the robot slightly. The front caster provides just enough clearance to pass over floor rugs in the house without causing either drive wheel to lift off the ground. The use of two casters is intended to help stabilize the robot when a gripper is attached.
The power plate you see above, with the terminal barrier strip, holds nearly all of the DC to DC power converters and provides good ventilation, though the power converters never really warm up.
Those gray rectangles at the corners of the bottom frame hold time of flight sensors. Those black rectangles in the center of the crossbars in the middle of the frame hold SONAR sensors.
The Bottom Plate
The robot consists of a bottom plate holding power components and sensors, and a top plate holding computation and communication components. Eventually another plate could be attached above the current top plate to hold an arm and a gripper.
To the right you can see the thick, vertical aluminum plate holding three DC to DC power converters and a terminal barrier strip (two of the converters can be seen from a different angle in a previous picture). The thick, vertical plate in the center holds two custom PC boards I made which are Teensy Monitor boards, and the RoboClaw motor controller. To the left you see the top of the power panel which has the on/emergency-off power switch, a power meter, a touch screen and a few other components. The blue rectangle in the back is the battery that powers the robot.
The Top Plate
In this view of the top plate, you can see the pair of WiFi antennas to the left, then a USB hub to the right of that and then a plate holding an HDMI and USB breakout from the main computer. The plate allows me to hook up a monitor and keyboard/mouse to more easily program the main computer, which is an AMD 3700X 8-core computer on a Mini-ITX motherboard with 32GB of RAM and 512GB of NVME disk. Next to the HDMI/USB breakout are PC panel breakouts, such as the reset switch and power/disk activity lights.
Above the WiFi antennas, showing red and black wire connections, are a pair of Anderson Powerpole breakout boxes that distribute 5 volt and 12 volt power from the bottom plate to the top plate. The black cube in the upper right is an LD06 LIDAR. I previously used a pair of LIDARs, mounted at two corners of the robot at different heights, but currently I’m only using a single LIDAR mounted higher up.
The picture below gives a better view of the main computer and also the NVIDIA GeForce GT 1030 graphics card. To the right you see a pair of OAK-D stereo RGB and depth camera modules mounted on a plate that positions them 90 degrees apart, giving the robot a horizontal field of view of nearly 180 degrees.
Below the OAK-D cameras but not visible in the picture is an Intel Realsense T265 visual odometry camera. Currently I’ve given up trying to keep Intel’s software working on the Ubuntu 20.04 operating system. Intel’s software seems to frequently break when I accept software updates. Eventually, I may take the time to fix their software again, but it’s not needed for now.
The picture below shows the other side of the top plate. The rats nest of white cables provides the needed power to the Mini-ITX motherboard. Obscured under the white wires is a small silver box which is the final DC to DC power convertor that converts 12 volts to 3.3 volts for the motherboard.
The Power Control Panel
The panel includes the on/emergency-off power switch, a 30 amp fuse and a meter showing the battery voltage, current draw and power draw as well as the battery charge. The battery temperature sensor is not hooked up to the battery at this time.
The top left holds a touch screen which is talked about elsewhere. Below that is a power cutoff switch for the RoboClaw motor controller, allowing me to run experiments, such as path planning, without any chance of the robot actually moving. The two red, push button switches below the motor power switch can be used to reset either of the two, custom Teensy Monitor boards, so I don’t have to try to reach my hand behind this panel in case either of the Teensy 4.1 microcomputers fails to program correctly. Finally, there is a panel mount for a pair of Anderson Powerpole connectors to provide the 42 volts power to charge the battery. Eventually the 42 volts will be supplied via some sort of docking connector.
The Motors
The motors and wheel encoders are mounted underneath the bottom plate. The motors drive a right angle gearbox, allowing a better mounting position for the motors and offloading the weight of the robot from the motor shaft. Glued to each motor housing is an analog temperature sensor so the Teensy Monitor can check for motor overheating.
Cabling
Where I remembered, I used shrink wrap, tubular markers to mark the various cables as I built them. Where I didn’t remember, I added wraparound labels to the cables after the connectors were added to the ends of the cables. I used Lever Nuts to connect high current wires. An example is the gray connector with the orange lever sticking out. Since there are 4 SONAR cables and 8 time of flight cables (as well as a few other non-power cables), I also crudely colored the cables with felt tip markers to make them more easily stand out when I’m trying to find where a cable is routed through a bundle of cables.
All of the power distribution cabling is documented using the WireViz software. An example of the documentation is in another paper. I try to keep the documentation up to date as I make changes. It lets me see exactly where each cable end attaches, and even lets me include pictures of the connectors or other devices.
Long cables are generally attached to the frame with self adhesive cable zip tie mounts and zip ties, similar to the following.
Custom PC Board for the RoboClaw
I’ve had many failures with the Dupont style connectors for signal cables to the RoboClaw itself. These connectors don’t offer much friction and fall off rather easily with a vibrating robot. On order to provide a more reliable connection, I designed a simple PC board that connects to all of the terminal pins of the RoboClaw board, providing more friction because of the number of simultaneous pins connected to a single, rigid PC board. It also gives me locking connectors to the signals from the two motor encoders and breaks out test points for various signals so I can test for electrical noise and provide shielding as needed. I still need to provide an even more robust connection in the future, but this works well enough for now.