I know that some of your comments about me overengineering my robot are tongue-in-cheek, but some are not. You do know that my robots are not just a hobby. My robot will have to provide serious assistance to me in a few years. My robot is capable of causing serious damage and endangering me in my house. I do actually have requirements and specs for a lot of what I do. Titania is a follow-on to Sigyn with even more specs and even more requirements. Each iteration raises the bar on what I’m doing.
- Sigyn has brushed motors. They are too noisy to allow patrolling the house at night—they would wake me up. I need quieter motors, so Titania is moving to brushless motors.
- The ODrive motors I’m moving too are rated at 48 volts. But a 48 volt LiFePo4 battery system doesn’t peak at 48 volts. In fact it exceeds the maximum voltage for the motors so I have to stay with a 36 volt system. This means fatter wires, bigger fuses, etc.
- Sigyn has wheels attached to the axle via set screws. This always, and I mean always, will cause the wheels to come loose over time. No amount of thread lock will prevent wear at the contact point, and the wheels, by their very nature, are under a lot of torque trying to hold the robot upright. I need to get away from that problem. The ODrive wheels I am going to look like should run considerably longer without an issue.
- My power system doesn’t use a precharge during the power up. I have a simple emergency-stop switch to power on. This will eventually weld the contacts. I’m moving to a pair of contactor switches rated at 100 Amps. One will do the precharge to prevent arcing before the second does the real power up.
- My safety system is ultimately limited to stopping the motors. There is a mechanical e-stop switch, but the software cannot turn off power to various subsystems (like resetting the PC, turning off power to the motors). That is changing. The power-on switch talks to a new, always-on system that operates the two relays above and also has the ability to power up/down subsystems and force reset or force MCUs into programming mode. The mechanical e-stop switch is inline with the mechanical contactor switch in order to kill the battery as a final cutoff.
And there are a handful of similar issues that make Sigyn untrustworthy to patrol the house for a week while I’m on vacation.
Again, Sigyn will eventually be checking to see if I’ve fallen, that I’m still breathing. I may need to deliver medicine to me quickly. These things cannot fail. It needs to know if a window is broken, if a door is left open, if there is something about to catch fire, if there is high CO or CO2 in the house. Again, not a toy.
I’m curious as to just what your serious side comments on overengineering are? Nearly all the things I think you might be referring to are very low-cost items.
My motor runaway detection? That’s a very real issue, and it’s easy to detect.
My measuring temperature gradients to predict that something will overheat? Well, when my motors are operated for long periods of time, they do heat up. The question of whether the motors are too hot is one safety issue, but it takes a long time for motors to cool down. I want to detect that they are heating up quickly so I still have time to, say, force a slowdown rather than wait until they are too hot and have to stop the motors.
Motor overcurrent management? My motors are somewhat expensive (about $100 each), hard to buy again, and it takes many hours to physically replace them. My robot is heavy and has a powerful battery — if you stop my motors by, say, running into a wall, I have probably much less than a second to detect this and kill power before the windings would literally melt.
My rings of protection? Well, Nav2 is not reliable by any means for a lot of reasons. My robot should detect that the configured safety ring in Nav2 isn’t being honored (e.g., even with my fast PC brain, I don’t always sustain my 20 loops/second minimum for the control loop), and when a small violation is detected, the safety system tries to slow down the motors hoping that Nav2 can then catch up. If objects enter “zone 3” (obstacles are almost touching the robot), then ROS 2 has screwed up, and I shut down the motors.
My motors cannot “stutter”. My mechanical design requires smooth operation. I haven’t allowed for quick starts and stops — my robot would faceplant. There is a fair amount of engineering I’ve don’t to make the robot fast and smooth in its movements.
There isn’t much in my long effort to provide safety, trustworthiness, and reliability in my robot that any hobbyist couldn’t duplicate. You just need a few more sensors, an ability to respond to issues, like stopping the motors, and a hardware compute system that is similar to a hard, real-time OS. In my case, all safety is provided by several, tightly coupled MCUs where I’ve engineered the code execution to ensure some computational guarantees. I need several MCUs because ROS does not work well if you cannot provide fast frame rates for data.
I’m moving more and more to a spec-driven system. Enclosed is the very first draft of the spec for Titania. There will be many iterations of this as I redesign and redo everything as I build Titania.
I invite a polite, considered critique of my architecture and goals.