3-axis closed loop motion control

I've spent a few minutes over at hackaday and there are several ( robotic- ) projects using optical mouse sensors. They mostly failed, due to top speed of the robot or dirt/ distance to surface issues. All of that can be ignored in our application, but the max. speed might still be an issue.

The reliability of the encoder signal can be greatly improved by sensor fusion, but for 3 axis and ( several ) extruders, it takes a lot of CPU time to maintain all those sensors. Maybe an independent controller for each motor which only reports errors to the main CPU is the better way.

Quote
o_lampe
I've spent a few minutes over at hackaday and there are several ( robotic- ) projects using optical mouse sensors. They mostly failed, due to top speed of the robot or dirt/ distance to surface issues. All of that can be ignored in our application, but the max. speed might still be an issue.

The reliability of the encoder signal can be greatly improved by sensor fusion, but for 3 axis and ( several ) extruders, it takes a lot of CPU time to maintain all those sensors. Maybe an independent controller for each motor which only reports errors to the main CPU is the better way.

The idea of only adding a mouse sensor is pretty seductive, but I agree the cpu overhead is likely prohibitive. To keep costs inline with current controller boards I'd like to do it in a single MCU, some flavor of ARM most likely.

IMO it definitely makes sense to do the motor control and sensor processing in a separate processor. You can get an ARM processor for about £0.50 now - less than the cost of an attiny - so there is no reason not to use one per motor.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
o_lampe
the L6234D chip is a 3phase H-bridge, able to control one BLDC motor or three DC motors

Sorry about that statement.
I had the L298 Driver in mind, which can drive one stepper or two dc motors and extrapolated from there...

Quote
dc42
IMO it definitely makes sense to do the motor control and sensor processing in a separate processor. You can get an ARM processor for about £0.50 now - less than the cost of an attiny - so there is no reason not to use one per motor.

They are definitely cheap these days. If two encoders were used (shaft and axis), there's a much larger chance it would make sense. I really don't want to just emulate steppers though, so figuring out what communication needs to happen is going to be tricky. At the very least I think each axis is going to need to know what the 'next move' is to properly plan the acceleration curves, which will be easier to do if it's a subroutine in a single processor that's receiving the GCode (do I even WANT to use gcode, is another question. Standards are awesome and everything speaks it but I've read people complaining about its limitations)

I wouldn't pass gcode to the motor control processors. Instead I would pass move parameters similar to the ones we use internally in RepRapFirmware. These define Cartesian motion, extruder motion with optional pressure advance, or delta motion - all with acceleration, steady speed and deceleration phases. Then the ARM processor can work out the required motion. In fact it would be easier than in RepRapFirmware because we can work in time increments instead of movement increments - which makes the calculations much simpler.

If we can come up with a good combination of BLDC motor and control IC, I'm up for implementing the necessary support in RepRapFirmware.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42
If we can come up with a good combination of BLDC motor and control IC, I'm up for implementing the necessary support in RepRapFirmware.

Sounds like a plan!

I suggest we could start with a hall sensor pcb that fits a wide variety of BL outrunners. I would also volunteer to rewind them to a lower kV if necessary. ( That's what I did at Plettenberg-Motoren , com all day long )

Maybe we can use a mouse sensor aimed to the can of the outrunner as "shaft" encoder?

Edited 1 time(s). Last edit at 01/15/2017 01:31PM by o_lampe.

The mouse sensor sounded like a good idea to me for use as a linear encoder, but for a shaft encoder I'd prefer to use something more conventional.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

It's been a while and I wanted to ping the discussion with a new idea:

Multicopters are stabilized by a 6DOF gyro/accel sensor MPU6050. They are very sensitive, but tend to drift.
With a coarse encoder strip or wheel and the MPU data to navigate "between" the encoder signals, we would have a stable feedback loop.

There is plenty of code for arduinos about sensor fusion with MPU6050 and other ( magnetic ) sensors, so we wouldn't have to invent the wheel.

That's a very interesting idea. I don't know much about the gyro/accelerometer specs, wouldn't they be quite noisy at the resolutions we're talking about?

That's right, but hardware & software lowpass filtering and sensor fusion algorithms can improve the output. I've built a self balancing robot with such a sensor and it regulates so fast, you don't see or hear it.

Quote
o_lampe
I've built a self balancing robot with such a sensor and it regulates so fast, you don't see or hear it.

I must put that on the todo list. Self-balancers have always seemed amazingly cool.

See

[forums.reprap.org]

[forums.reprap.org]

I got MPU 6050 IMU hooked up
what should I measure?

MPU6050 6-axis MotionTracking device that combines a 3-axis
gyroscope, 3-axis accelerometer, and a Digital Motion Processor™ (DMP) all in a small 4x4x0.9mm
package.

Quote

I got MPU 6050 IMU hooked up
what should I measure?

Awesome coincidence... I should read more subforums.

Is it raw IMU-data you're getting now?
I'm no expert in vector algebra, but the Skrogh-guy seems to be.
All I know is, you have to calculate acceleration vector over time to get a movement as result. My tech/math English vocabulary is to limited to explain.

Anyone considered using GT2 belts as encoders? An array of IR sensors could help with the resolution, and the belt directly driving the axis might reduce backlash?

You can use $8 digital calipers as linear encoders. Most models have serial ports accessible via the battery compartment, although you might want to directly tap the quadrature signals for faster updates.

I highly doubt that stepper motors are limiting print quality in hobby FDM. Stepper motors are by far the best performing option for their cost, which is why they are used everywhere.

I wonder how these guys did it? it's impressive
[www.panowin.com]

or its first vid on this page
[www.panowin.com]

I have experienced from close loop DC Motor from PIC16F / MCS2051 era. I have built several DC Close loop motor driver using uC, FPGA even Labview.

I have built several 3d printer too, i'm currently working on my 18th revision and currently my 30th printer.

What I have try in these few years. The theoretical of Stepper and DC motor might conclude the superior of DC motor (not mention Direct Drive Brushless Linear Actuator). For some example such as in the industrial 3d printer they use Close loop DC motor.

But Why dose a close loop dc failed in hobby grade. Well, there is/are 3d printer project(s) many years ago that promises the advantages of DC Brushed Close loop motor by reference from the commercial inkjet printer.

The problem of dc brush/brushless motor you have to archive is...

1. DC torque vs Stepper Holding torque. Imagine one axis is hold and the other is moving, and there is some coupling force. Without breaking system, the vibration will effect the holding motor due to low holding force of dc (unless you will need to use a dc with bigger size and a good winding inside which we prefer Maxon,Faulhaber,any Coreless for ex) and If ther is no error there wont be any force. If you crack down PID algorithm, there must be some error or movement for encoder to sense and feed into the PID gain to energize power to motor.
2. Synchronization, the success in large scale CNC or Robot that use dc close loop is they calculate their kinematic of multiple axis together. They use a vector drive scheme which is the technique to sync the error of each motor in realtime.
What I'm talking about is in every system there will be error. In stepper motor control the error we are talking is not the step missing but the deviation from the desired position in microstepping (which is the major cause of Salmon skin effect).
In PID there must be Overshoot, Lagging and steady-state error which is need to compensate. If one axis has error more than other axis that means the current of the current state is not on the planned trajectory which a new heading vector (or angle) must be recalculate in each iteration.
3. In the end, then normally we feed the velocity control loop with the step/ direction signal to make sure that the feedrate is constant. you can implement in PID loop but the equation is the same.

Normally in motor control, we gonna use layers of control-loop , stacked on each other.
For ex. Trajectory(Step/Dir) ->Position Control(PID with position feedback from encoder -> Velocity (PID with calculated speed from encoder(Poor) + Back EMF Voltage from motor(need kalman filtration !!sophisticate!! )) -> Acceleration (aka Electric Current loop) sense from resistor or hall device.

Edited 1 time(s). Last edit at 10/28/2017 04:51PM by bnarit.

For encoder strip.

I think GT2 is ok and we can use the motor attached encoder with 1024 ppr just fine.

But if you want to go crazier,

Looking on Optical strip, there are cheap and they are used in large format inkjet printer or you can go to the stencil/printing/plating mask film company they can go down to 10um resolution(industrial standard).
But if you want to use magnetic strip, it might be a good choice you can find magnetic strip and reader ic from many vendors.

However if you want to go to sub micron, you can try laser interference as well, think about using a laser time of flight sensor and let them bouncing a thousand time across two parallel mirror. you can readout the distance in many km and divide into sub micron accuracy due to the nature of time of flight reading which the error is the constant latency delay.

Or you can use multi different encoder strip pitch with different prime number. the you can calculate the resolution up to a million factor sue to there just a few prime numbers construct in to a million.