The Raspberry Pi platform has become popular in the maker community for various CNC projects. The single board computers are readily suited to acting as a server for a small CNC setup or 3D printer, though it’s fair to say that for heavy work they probably aren’t quite up to the task of driving the steppers in a serious rig directly. [Danny] set out to try to build a CNC plotter of his own, using a Pi Zero, and learned a few things along the way.
The plotter uses 3D printed parts combined with brushed DC motors which are geared down. Potentiometers are added to allow the Pi to keep track of the location of the pen. This enables the position to be corrected through feedback.
While the plotter does move and accept commands, it does have some issues. There is significant play in the gear train which [Danny] suspects of causing the poor output results. If you’ve got any ideas as to how this could be improved or overcome, throw them down in the comments!
We’ve seen another take on CNC control with the Raspberry Pi, too. Video after the break.
I applaud Danny’s courage for posting this.
There are a couple lessons here.
1. The lack of structural rigidity of the setup is the most serious issue, IMHO.
2. Closed-loop is not always better than open-loop. This implementation of a closed-loop system increases the design complexity (over an open-loop stepper-based system), but without a net payoff in accuracy, because it can only correct for errors after they have already been made. A well-designed and tuned open-loop stepper-based system can operate (in many cases) without significant positioning errors over thousands of moves. Consider a 3D printer running an overnight print job.
I’d echo this. A closed-loop system is also only as accurate as the sensor – which isnok if you’re using an encoder on a stepper to detect failed steps, but using a potentiometer into an ADC won’t be that accurate due to the resolution of the ADC and potentially noise.
Nice ones presumably less so/over a longer period of time; but pots also have the nasty habit of wearing.
For trimming that usually isn’t a huge deal, but repeated cycling(especially over a small area of their range) does not do the stability of their resistance values any good; and the wear is rarely perfecily linear across their entire range.
I’ve had to swap out a bunch volume control pots over the years when things start to get horribly erratic, especially around the region of the dial that actually saw frequent use.
Mechanical encoders can wear as well; but since they depend on a bunch of binary switch states they don’t drift around as much; and optoencoders are paragons of reliability by comparison to either. Pity they are more expensive.
“repeated cycling(especially over a small area of their range) does not do the stability of their resistance values any good; and the wear is rarely perfecily linear across their entire range.”
I agree that the pots will wear out quickly. I hoped to eventually switch to higher-quality encoders to improve accuracy and lifespan.
Unfortunately, I don’t think pot inaccuracy can explain my results. I had the Pi print the calculated positions; they closely resemble the actual positions. It appears that the Pi “knows” where the end effector is.
“using a potentiometer into an ADC won’t be that accurate due to the resolution of the ADC and potentially noise”
I definitely get noise, but only 1-3 units (on a scale from 0 to 1023). This corresponds to less than a degree of rotation; the arm’s joints would need errors of several degrees in order to get the behaviors I’m seeing.
>”because it can only correct for errors after they have already been made”
Only if you’re running a naive control loop that doesn’t look ahead. A closed loop system can have an internal model of the system, so it can track and prevent the accumulation of error before it happens.
The power of closed loop control is that you have the error information at hand all the time, and you can tune to minimize the error by trying different control values. That means you can capture some of the (semi)static properties of your system automatically, like how much mass your robot is carrying, or how great the friction between the pen and paper, while you’re performing the motion. Better yet, you can implement an internal model of your system and compare with that you’re expecting to happen, which yields more accurate results.
A closed loop servo system is only as good as the rigidity between the feedback pots and the tool end. Here, there’s so much slop, the position at the pots doesn’t come close to representing the position at the tip of the pen, so it is impossible to correct for that portion of the error.
If you are trying to prove that stiffness and rigidity isn’t important in a mechanical system, the key is to take the same approach that 4-wire ohmmeters (aka Kelvin sensing) take: use a separate mechanism for sensing the tool position that isn’t affected by the forces on the tool.
“Here, there’s so much slop, the position at the pots doesn’t come close to representing the position at the tip of the pen”
Thank you for the feedback. If I understand correctly, the suggestion is that the errors occur between the pot and the end effector. In other words, the arm is bending. I disagree for two reasons:
(1) The errors can be almost as large as 1cm. Each dowel is only 2cm long, and the printed parts are even smaller. I don’t see how the any part(s) would bend enough to cause the large errors I’m seeing.
(2) As a debugging technique, I had the arm print its estimated position, as determined by the pots. The calculated position closely matched the actual position; i.e. the Pi knew that the arm was in the wrong position.
Dowel flex would be one of the last things I would worry about here, as there are far more critical design issues. The main problems are that each axis is really only supported on one end, and the angular errors (primarily from joint slop) are cumulative. Also, the pen lifting mechanism is trying to lift the majority of the structure, rather than just the pen. Look at how the angle of the pen changes as moves are made.
For reliable operation, each axis should be supported on both ends.
To keep the stresses more uniform, I would have the pen remain vertical at all times, with only motion being in Z.
In 2.5D plotters, a hobby servo is commonly used for pen lifting, to reduce the load on the rest of the structure.
Danny: First thing: don’t get defensive. If you’ve already ruled out things that people have suggested, just let it go. The problem is that there are MANY problems with this design, so fixing any one problem is NOT going to fix the system. But to address your response directly, if you are getting large error values, then ONE of your problems is that your feedback loop is not tuned right. There are two things I have to add: 1) it may be that with all of the mechanical issues (backlash, slack, and just plain lack of stiffness), it would take an impossibly complex feedback algorithm to correct for all of these, and 2) even if you get your error signal down to an acceptable amount, you’re STILL going to have inaccuracies at the pen tip due to mechanical issues between the pen tip and the pots.
What I would suggest is working from the pen tip out, concentrating on ONE axis at a time. Once you have each axis behaving well, work outward to the next, first by controlling that axis alone and then that axis combined with all others out to the pen tip. This will reduce the number of unknowns at each iteration.
“Here, there’s so much slop, the position at the pots doesn’t come close to representing the position at the tip of the pen”
Thank you for the feedback. If I understand correctly, the suggestion is that the errors occur between the pot and the end effector. In other words, the arm is bending. I disagree for two reasons:
(1) The errors can be almost as large as 1cm. Each dowel is only 2cm long, and the printed parts are even smaller. I don’t see how the any part(s) would bend enough to cause the large errors I’m seeing.
(2) As a debugging technique, I had the arm print its estimated position, as determined by the pots. The calculated position closely matched the actual position; i.e. the Pi knew that the arm was in the wrong position.
So technically this is a project that should file under the name “fail of the week”? Or perhaps that is a bit to harsh.
But with some extra effort, improving stiffness, better way of position sensing this can go a long way. I’m pretty sure that this project will evolve.
This is to mechatronics, as 50 Shades of Gray is to literature and erotica.
This is to engineering, as Hackers (1995) is to technical documentaries.
Which is to say, the tragedy isn’t actually the product, so much as the failure (on the part of much of the audience, and perhaps the author as well) to recognize that they’ve made an absurdist comedy. Which makes it all the more absurd.
Which may make it a masterwork.
no, hackers (the movie) was a masterpiece because it was a well-executed good representation even if it was not a literal representation. the 3-D printed internal combustion engine head in the other article today, that is a masterpiece! it could not have succeeded, and the craftsman knew that and then thoroughly and competently explored the non-solution space anyways! this is just an ambitious project by someone who hasn’t yet learned the fundamentals. normal, progressive, laudable, and even a good exhibit. but not a masterpiece by any stretch…we’ve all started on projects that turned out to be failures because of backlash, flex, and inappropriate sensors. this is just mechanics 101, the way we learn.
>”failures because of backlash, flex, and inappropriate sensors”
I wrote an earlier comment outlining why this isn’t the case.
Every axis you add to the arm introduces errors caused by the length of the arm sections. The first gear train will have a large error at the end of the arm. The weight compounds the problem. Adding rigidity often also adds weight, however the first motor/gear train can be stationary and should be the most rigid and can be the heaviest, then progressively smaller and lighter for each section. 3D printed material is also not the most stiff material. Try to build it using aluminium for example. If you own a cnc router or mill you can make plates that interface between the sections. Using proper bearings (and used in the proper way) will also reduce compliance.
Also, the sections are only supported by the motor. The dowel only gives support to one side which is no support at all basically.
Usually you see u shaped couplings where the motor only supplies rotational forces. Try printing a U shaped part where there are bearings at the ends of the U. Use gears (V shaped to reduce backlash/compliance) or toothed belt to drive the shaft using a stepper motor. Use collars to lock the shaft between the upper and lower bearings. There are optical encoders you can add to the shaft for closed loop feedback or use end stop switches. It’s also possible to use TMC2130 drivers that have StallGuard, so basically you can skip the end stops reducing complexity at the cost of a little accuracy.
Another option is to use steel wires guided through the arm and put the motors in the base. You could use a corexy like setup.
(1) Thanks for the comment regarding errors at the base of the arm; I completely agree. I’m thinking of switching to a parallel scara or a linear design to fix this issue. I knew this issue existed, but it seems to be more of a problem than I anticipated.
(2) The vertical dowel (parallel to the motor shaft) was added to hold the pot in place; it is not intended to support weight. I wasn’t excited about having the motors support the weight of the arm, but I assumed it wouldn’t be a problem for this small of a robot. However, the stress may have contributed to the loosening of the gear system.
(3) Thanks for the recommendation of the TMC2130. But does it work for DC motors? I looked it up; it seems to be a stepper driver. I could switch to using steppers if I need to, but I’m hoping to design a robot that doesn’t use them. The current design uses DC motors that are driven by PWM.
(4) The bearings and u-shaped couplings would definitely be an improvement; I might need to implement them in later versions.
I’d come up with a damper system and compensate for the backlash in code.
Thanks for all the helpful replies! I thought I should post an update regarding the project, in case someone visits the article later and wonders what became of the project. I’ll probably post the same update to my project page.
Several issues have been pointed out that would not be fixed by replacing the wobbly worm gears. Each issue could be addressed individually, but this would be time-consuming.
Therefore I’ve decided to reduce the scope of my efforts. I plan to continue testing the Pi and DC motors, but to use a conventional, cartesian robot that will be similar (or identical?) to existing open-source designs. This will reduce complexity and make debugging much simpler.
Since I’m rebuilding the robot anyway, I might as well invest in higher-accuracy sensors. Perhaps I’ll get some optical encoders. Alternatively, I might make an attempt at using computer vision- others on this website have had success with this approach. I would have to purchase and calibrate a camera of sufficient resolution, but OpenCV definitely has the capability to do this sort of thing (at least to moderate accuracy).
I’ll probably post something to this website when (if) I get another robot built and working. But it will probably be a few months (or even a few years).