ConceptFORGE

If you have a question or a comment that doesn't fit anywhere then start a topic here. As we get this forum up and running we will be adding more categories and liberally moving topics to the appropriate place.

So I was thinking that a somewhat (mechanically) simple and very low cost way to calibrate non-linearities with a SCARA bot would be just to put an accelerometer chip at the print head. Accelerometers with 3 perfectly orthogonal channels are quite cheap, less than a dollar, two bucks will get you one on a breakout board you can wire directly to your uC.

Then, during calibration, the machine would step around its bed verifying that its movements in X and Y only generate accelerations in the appropriate channel of the accelerometer, recording anywhere it deviates to update its internal model of itself.

There are a few other cool things you could do in the firmware with an accelerometer in the head.

Many types of errors such as massive missed steps, a belt falling off, movement constrained by an external force (like the rest of your bot because your endstop fell off) could easily be detected at run-time as they would cause gross differences in the accelerometer output vs what is expected and the printer can stop and alert you if something is wrong. Or at least avoid tearing itself apart due to a faulty endstop connection. It can probably replace the need for outer limit endstops completely which will more than make up the cost for a properly robust design.

By trying movements at different speeds and seeing how long it takes to stop due to inertia, the firmware can automatically develop some sense of the intertia/mass of the print head and the maxium speeds it can safely do or how gentle it needs to make its acceleration curves to keep the head from overshooting.

The bot would be able to detect (by looking at gravity axis after letting it settle at different points in the space) whether the head is causing the frame to bend slightly at full extension. with a trig calc (it knows angle and how far the head has extended so can figure out z offset) it can automatically adjust the z axis to make up for gravities effect on the frame. So, you can use heavier print-heads with less than perfectly rigid bots and it would be able to compensate to a degree for any droop due to gravity.

The nice thing is that there are no manual steps here at all for calibration, it is something the bot can do in a completely automated way on its own.

That is a great idea. I have thought about using it also as a touch probe. It would be very easy to see the first instant we get a spike in the z acceleration (impact with bed). You could also use this for crash detection and for using hard stops like end stops. (I know it sounds crazy to have the machine run into something to detect it but with a fast enough controller combined with a gentle approach you should be fine. )

It seems like with a stable (over at least a period of hours) bot and a sufficiently long calibration procedure you could conceivably characterize the whole geometry up to a scale. (We are talking where the bed is, where you have collisions of any kind, etc.) The scale could be had by measure a print.

Here is the problem, accelerators are supper noisy on a good day. You will have to do a moving window average to make them semiusable. Beyond that you would need to do a ton of measurements to allow for a decent geometry fit. The worst of it would be the calibration of the sensor itself. I assume they make them with +/-10% tolerance or so. What one sensor may call .9g another will call 1.1g. That sounds worse than it is. They are usually very precise after you filter out the noise. We can solve that by slapping the sensor on a well behaved Cartesian bot for initial calibration.

Good idea but there is a few things that will cause a bump or two.

One last problem, this all gets infinitely harder if you allow the sensor to rotate. Sure you could add a gyro but that is a lot of stacked error. I don't think we could get to micron accuracy.

Even if it can just replace endstops, I think it well worth it. A singe sub-dollar accelerometer chip vs 6 switches and the wiring needed seems like a win.

Plus, I think it can significantly improve the off the table experience even if it can't help with micron precision. It can make set-up signifigantly easier. You would no longer need to configure your firmware with which steppers are hooked to which channels or their polarity. it can auto-detect it. And when iterating designs a lot, having it 'self-calibrate' to even a rough degree will find any major errors in your build.

And it would immediately catch many of the common failure modes before it gets worse. Some things I have run into were my couplers delaminating, not immediately obvious to look at, but would easily be caught by even very rough interpretation of accel data. Or accidentally plugging in a motor backwards inverting an axis. or my magnetic base plate being not fully seated causing my print head to gouge a trail down it. or bumping my machine so an endstop no longer quite matches up. Pretty common errors among people actively iterating their designs.

I am not saying we need full closed loop control, but problems on repraps tend to escalate, the motors are very strong compared to the construction materials and a simple issue can turn into the machine tearing itself apart pretty easily. A simple "hey something is wrong, stop pushing" signal would do a lot to alleviate it.

It will be some firmware work, but it actually sounds like fun firmware work. Rotation will be harder, like with the LISA design, but it doesn't seem insurmountable. These are not calculations we have to do in realtime, just during calibration/self-test so brute force approaches will work.

The best part is that the idea is trivial for anyone to play with without modifications to their machine, just some tape, a dollar fify for the module and stick it to your print head.

The firmware could even potentially "learn" the geometry of the bot by trial and error. This could actually be a great game, contestants are provided with a bot with an unknown geometry and their firmware has to "derive" the geometry from just the acceleration data and control of the 3 steppers. Whoevers firmware can draw the best cube at the end of the day with no human interaction wins..

Actually, I wasn't even thinking in terms of the auto-z-level problem, but that could be a killer feature.

It seems like it would be easier to test if you bonded the accelerometer to the print bed rather than the head if all you wanted to do was detect when it hit since you won't have to determine that the head didn't accelerate when you intended it too rather just that the bed moved at all.

I went ahead and ordered several different accelerometer chips ranging from 75 cents to ten dollars. the best of which have full IMUs. Even accel+gyro can be < $2. Will hook them up to my prusa v1.5 in various ways and see what i can get. Z table leveling would dramatically improve the usability.

Oh this is a marvelous idea! If this works it would simplify construction and wiring and calibration of delta printers by a lot!

Simply by detecting end stops and bed leveling stops on a delta you can use numerical algorithms to determine the geometry. So you wouldn't need to use acceleration data for comparison to linear movement. But I love that idea as well!

Acceleration tracking of the print head (closed loop? Ideally position tracking like vive/rift) might allow for a lot of new 3D printer designs. A design with an robot arm that you know is elastic and droops like hell could just be measured. You would create a mathematical model to describe these effects depending on 3D position, current and previous acceleration and other factors like heat and then simply have an optimizing or machine learning algorithm create the parameters to compensate! After all our human musculature is inaccurate as hell but our brain creates pathways to compensate. So what if you measured wrong? Just learn to compensate Probably not something new in robotics, and probably not usable for applications that require stiffness, but it might just do the trick for 3D printing where range and accuracy is more important.

Thanks for sharing

PS: I see this topic is more than a year old, anything ever come from this?