RepRapServo 1 0
- 1 A RepRap Universal Servo Controller
- 1.1 Introduction
- 1.2 Design Considerations
- 1.2.1 Scope
- 1.2.2 Order of Battle
- 1.2.3 Flexibility of application
- 1.2.4 Cost effect
- 1.2.5 Performance
- 1.2.6 Positional Feedback
- 184.108.40.206 Tool Head/Carriage Position Feedback
- 220.127.116.11 active optical position control camera
- 18.104.22.168 optical mouse's sensors
- 22.214.171.124 linear magnetic position sensing
- 126.96.36.199 Motor Shaft Position Feedback
- 188.8.131.52 Workspace Units versus Drawing Units
- 184.108.40.206 Sizing the workspace
- 220.127.116.11 Workspace Centering
- 1.3 Specification
- 1.3.1 DC Brushed Motor
- 1.3.2 Motor Power Drive Stage
- 1.3.3 Pre Drive Stage & Level Shifting
- 1.3.4 Positional Feedback
- 1.3.5 Resolution
- 1.3.6 Workspace Discovery & Error Detection
- 1.3.7 Interfacing
- 1.4 Design
- 1.5 Implementation
- 1.6 Bibliography, Related Reading and other Sources
- 1.7 Acknowledgments
- 1.8 Further reading
A RepRap Universal Servo Controller
If you are reading this, then you are potentially interested in either understanding how, or intend to actually use, a servo motor method for driving one or more axes in a motion control project.
The aims of this document are to describe the design and, where possible, implementation for a servo motor control system that can be universally applied to solving some of the problems of motion control typically found in robotics applications, particularly Rapid/Flexible manufacturing.
I guess that's a fancy way of saying we want to build a Servo Controlled DC Brushed Motor option for driving the moving bits in a RepRap Robot.
To take part in the discussion and development of this Servo Controller please sign up to the RepRap Forum. The discussion thread for this can be found at :-
As with any project, we need to consider the scope, ie Which bits will we, by necessity, be limiting our activities to. In saying "by necessity", we are recognizing that we cannot control/specify everything and that in attempting to create a "Universal" controller we will have a fairly broad design specification.
Our scope, then, will be a single axis using a single servo controlled DC Brushed Motor. In deciding this, we are limiting ourselves to considering only those activities which pertain to our single axis, more complex matters--i.e. motion planning, drive train and synchronization--are beyond this project's scope. We need to be aware of these factors and allow for someone else to work work with them but will intentionally not worry about such things too deeply at this time. (In particular, stepper motors with inadequate resulution will be covered by a similar but independent project, Microstepping with optical feedback).
The motor specification will be a broad range or class with capability included to make it broader still but we will use a specific motor in our designing and prototyping to make sure it works. The specific motor we will use will be one that has a specification that sits well within our chosen class.
Actually extending the range of motors that can be driven will be outside our scope, although we will be giving some guidance as to how someone could go about this.
The Drive Train--including any gearing, etc--will be outside of our scope.
It will be within our scope to specify how to get positional feedback from a Drive train or Tool Head and we will, within our scope, provide more than one way of achieving this. The methods of communicating this to the controller we will by necessity limit to two.
Detection and failsafe limiting of the extremes of powered travel on our axis will be in scope as will a method to detect the center of the travel on our axis and the ability to regularly cross check this as our axis is operating in a production mode.
Penultimately our scope will include two principle methods of instructing or interfacing to the controller and the ability to mix and match components of both in an end users chosen final connectivity solution. The end users chosen final connectivity solution is firmly out of scope.
Finally the catch all, anything not stated as being in scope is quite clearly out of scope and we will not be doing anything with it.
Order of Battle
Like many systems a servo system is a chain of processes that to some degree interact. It follows then that each component will rely to some degree on the specification of the other components to which it is coupled. To minimize design effort we will be starting the design at one end of the chain and working through in a relatively orderly manner to the other. In our case we will start at the motor end and progress through to the controller's interfaces stage by stage.
In working with each stage in the chain we will only need to consider what cam before it. Each completed stage then becomes the specification for interconnecting the next.
You may think of this as the usual divide and conquer approach. Whilst Servo Control systems are complex, each primitive constituent part is actually quite simple. The quantity of the constituents and their interaction however make the whole thing difficult to take on board in one go.
Flexibility of application
To make the design as universal as possible (Have the widest possible application) we will be looking for ways to make key sections of the design replaceable/upgradeable. We will also be looking to create more than one way of interfacing the controller to the existing RepRap designs whilst avoiding precluding the controllers use with next generation designs.
Similarly we need to make sure that the design will allow a number of different types of positional feedback to be utilized.
See the Positional Feedback section that follows for an discussion of this topic.
The design will be for a single axis only, the idea being to make a single axis work very well and leave the user the flexibility of then applying the design as many times as they need for the number of axes the end application requires.
Inevitably any engineering solution is something of a compromise between features, cost and performance. This controller design will be no different.
We will however be keeping a close eye on cost not only of the controller itself but the implications of it's design on other system components.
For example whilst we may slightly increase cost in the controller design we will attempt to do this only where we can offset the cost elsewhere by enabling less expensive components to be used.
Sourcing the most cost effective components in a commercial world can be somewhat taxing. By commercial world we are talking about the commercial urge to charge what you can get for something rather than what it is sensibly worth and the geographic exploitation that results. If you consider the market for motor vehicle components a component branded with a major marque sold in a country considered to be wealthy will always cost savagely more than one that is generically named and sold in a country that is considered less wealthy (i.e. Volvo versus Unipart).
Some pointers that are worth mentioning, lowest cost can be found for components that have the greatest production volume for a competitive market with just enough saturation to make it worth while competing for.
Some useful examples:-
- 608 Roller Bearings whilst sold for a number of applications can be purchased in more precision than we need for lowest cost as Skate Bearings.
- DC Brushed Motors Whilst sold for a number of applications can be purchased new for lowest cost from Toy and Modeling Suppliers and Used 12v models from Automotive Scrap Dealers as Windscreen Wiper Motors.
Being aware of the pointers and applying a bit of lateral thinking can yield some great results (It also helps to be a skip rat)
The initial target audience is us the small home constructor so cost is a key consideration. A certain quantity of Industrial Class performance may be sacrificed to ensure that this is met whilst producing maximum flexibility.
On cost effect and the home constructor I guess a final word is in order, the most cost effective solutions for most home constructors are what they have squirreled away or can source locally (Often from Surplus). Flexibility then is more cost friendly to the home constructor.
The baseline for our performance requirements is in effect the current state of Darwin's (Stepper System Driven) art. That is to say we want to be able to use motors etc that will allow us to exceed this "baseline" specification whilst saving money by using motors that are more cost effective.
Greater performance in our case can be though of in terms of:-
- Same or Lower Power Consumption
- Same or Greater Speed
- Same or Greater Torque
- Same or better Accuracy
- Same or better Precision
- Same or better Resolution
- Same or better conformance between the final object and what is drawn.
If we score each of these on a yes/no basis and award each a gold star for "yes" and add this to a gold star for we did it for less cost (see considerations for cost effect)
- No Gold Stars = Bad (Remind me again, why are we doing all this work?)
- More Gold Stars = Good (Choose which method you fancy or your budget dictates)
- All Gold Stars = Excellent (Remind me again, why are we using steppers?)
(****Put some stuff in here describing the motor/driven performance spec for a typical Darwin RepRap when we get some.****)
A Servo System without positional feedback quite clearly isn't a Servo System so we need to give this some thought. Positional feedback isn't simply an electronic problem. Where accuracy and precision are needed (example Rapid Prototyping & CNC) a good controller design will need to allow for less than optimal mechanical characteristics in the drive train design. A universal controller will also have to be able to deal with the fact that it will need to be able to cope with each constructors preferred axis design and each constructors chosen resolutions of position.
Tool Head/Carriage Position Feedback
Positional feedback that can directly read the absolute position of the tool head can do so without worrying (a sensible amount) about the mechanical tolerances in the drive train. This is because the drive train becomes part of the feedback loop. It follows then that positioning of the tool head using the servo control method continues until the directly read position tool head position exactly matches that required.
Printers that use a linear positioning strip along the carriage's length are a good example of this. The print head is in effect the tool head of a printer.
A printer though has very limited degrees of freedom and is mechanically speaking a strictly controlled environment. Production or Amateur fabbing and CNC work on the other hand requires many more degrees of freedom and flexibility not to mention the probability of a contaminated working environment, often making this method cost prohibitive if not impractical. It can also be challenging to achieve the required degree of resolution. Precision implementation of mechanical drive trains is also often unavailable to the home constructor.
Direct positional feedback of a tool head with sufficient resolution, precision and accuracy is actually quite difficult due to physical limitations. It is far too easy to limit the degrees of freedom or foul the tool head with the measuring method.
An alternative that has only recently become available and economicaly viable is Laser Navigation. The same techniques used in Laser Mice to detect how much desk surface the mouse has traveled over.
Other than Laser Navigation, Motor or Motor Shaft Positional feedback has to date been the norm.
active optical position control camera
Is it possible to use a cheap webcam looking at the toolhead tip to control position more precisely?
"Think about this: Would you rather pay for high precision bearings, drive trains, and encoders for each joint in an arm, or pay for two high precision servos for a tiny little eye that will track the end point of the arm?"  
As a simple proof-of-concept, consider this camera watching several LEDs on a helicopter, using a single camera to estimate the XYZ position of the helicopter, and using that to drive the helicopter towards the desired position: RCgroups: "My tricopter design (autonomous indoor hover etc.) - Atmega32"
"Visual Servoing Curriculum"
optical mouse's sensors
This is a kind of optical position control, talked above. Mouse sensors are simple cameras with about 32x32 vision area. Their internal software processing optical pattern very quickly and output as TTL signals.
This sensors are available for sale (  ) or can be salvaged from old mice.
linear magnetic position sensing
Annie Ogborn says: I also just made a cool discovery. You know the rubbery ferrite fleximble magnet material? It's available in sheets to make 'fridge magnet' type things, with an adhesive backing. Any crafts store.
I just noticed that the polarization is in narrow strips, horizontally like this
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
The spatial wavelength is about 1/8", so you could make a handy position sensor or linear stepper out of it.
Motor Shaft Position Feedback
Positional feedback that is a guestimate based upon how much the motor drive shaft has rotated can with high precision mechanics give as good if not better results than Tool Head Positional Feedback. It can also yield fairly high resolutions of tool positioning on a very cost effective basis. However, unlike direct tool head positional feedback, the drive train does not form part of the feedback loop.
Where the drive train and gearing have any degree of position error the motor mounted encoder will be oblivious to this. We are in effect saying that if the motor shaft has traveled x distance then the tool head must have also traveled x distance. I reality though the tool head has traveled x + or - y distance. Where y is the error introduced by poor mechanical precision in the drive chain. Clearly the greater the error or y is the less precision our drive train has and therefore our tool head positioning.
Loss of mechanical precision can creep into a drive train in may ways, backlash, end float, thermal expansion/contraction and the elasticity of components through wear and tear or where drive belt/chain tensioning and sprung backlash pre-loading is utilized.
The two most popular ways of measuring shaft position are optical and magnetic.
magnetic shaft position feedback
- Main page: MagServo
Workspace Units versus Drawing Units
Sizing the workspace
DC Brushed Motor
Motor Power Drive Stage
Pre Drive Stage & Level Shifting
Workspace Discovery & Error Detection
Signaling of Movement and Error States
Stepper Motor Emulation
Parameterized Serial Control
Bibliography, Related Reading and other Sources
- Building Robot Drive Trains (Robot DNA Series, Clark & Owings, TAB Robotics (McGraw-Hill), ISBN 0-07-140850-9)
- The Art of Electronics (Horowitz and Hill, Cambridge, ISBN 0521-37095-7)
- The Robot Builders Bonanza (Gordon McComb, McGraw-Hill, ISBN0-8306-2800-2)
Papers and other Publications
- Wikipedia - PID Control Theory
- Wikipedia - Accuracy v Precision
- Wikipedia - ISO Metric Screw Thread
- www.embedded.com - PID Control Practice
Data Sheets and Application Notes
Please note that I have taken the liberty of embedding copies of data sheets and application notes here where ever possible. This only to ensure that most of these links stay live with the minimum of link maintenance allowing for the fact that manufacturers (quite reasonably) change specifications, retire product lines and reorganize their sites. For the latest copy of this type of data please refer to the manufacturer.
- The Arduino Project Home Page
- The RepRap Research Foundation
- Bits From Bytes
- Mabuchi Motors
- Precision Microdrives
- MFA/COMO Drills
- Active Robotics
- International Rectifier
- Zach Hoeken for sorting out the Wiki bits.
- Demented Chihuahua for ably assiting with my poor english
- Everyone at forums.reprap.org for their contribution to this ongoing development
-- Main.AndyKirby - 14 Jan 2008