With most of the mechanical design done for the 'hand' containing the tool interface, tool rotation and first (or last depending how you look at it) joint it's time to look at the motors that controll the arm. Best would be to get a premade servo motor that can controll the whole robot and call it a day. An alternative is to use stepper motors without feedback and trust that each step means an increase in rotation assuming no steps are skipped.
For light applications this would be viable, thats why most 3D pritners operate fine, trough have problems when they get stuck on something, having no feedback assumes the world complies to the machine.
Starting from a safety point of view, that would not be ideal. Having no feedback means no way to know if the robot is stuck and if the robot is damaging itself or someone operating the robot. Adding to this that no feedback would harm both the repeatability and the accuracy of the robot, an open feedback controll system is not an option.
I have thought of a few ideas, first of;
Take an ordenairy DC motor and add an absolute rotairy encoder to the system. This system allows for position feedback even if the power is cut. Trough accurate encoders are expensive, adding to a few hunder euros per encoder for the desired accuracy.
Looking for another option would be to take an relative encoder, just counting the pulses. there are two ways to implement it, dirrect on the axis or on the motor. Adding one dirrect on the axis would cause the same issues as the absolute encoder system. So, by using the gear redution and motor as encoding would increase accuracy without adding much to the cost.
Currently the motor selected is a polonu motor, due to the cost and availability. I am not married to this motor design and made the mechanical design such that I can easily interchange the motors to allow for prototyping and improvement, but more on that when the mechanical design is finalized.
Having the accuration and feedback leaves me with a single issue; control. Polonu offers servo controllers for the motors, trough what if I would make my own? I should be able to make one myself that would be tuned to the robots needs.
At the same time I was pondering this question the rpi R2040 came out and the idea of using one married in my head. This allowed me to grow my knowledge of microcontroller programming with more advanced systems. So I set out starting to learn how to work, first by programming a simple multicore 7-segment display multiplexer in C. It worked great but it left me wanting for more and wanting to get a hang of the PIO that the R2040 comes with. So I am at that stage, trying to get the PIO working and developing the idea i have in bits. So lets have a look at what my idea for the controller will be:
Seperating the controller and the comminucation should minimalise problems with time based controllers. For any system where timing is critical the PIOs will be used. The hope is that with this design the impact of processes interfering and causing unwanted behavoir is minimalized.