Code Monkey home page Code Monkey logo

mechaduino-hardware's Introduction

image

Engineers use servo motors to achieve the precision motion required in applications such as robotics, automation, and CNC manufacturing. Like RC servos, industrial servos actively correct for external disturbances. Unlike RC servos, industrial servos can provide very accurate motion, and often support advanced motion control modes. Unfortunately the cost of industrial servos is prohibitive to the individual maker (thousands of dollars per motor).

We've been developing an affordable open-source industrial servo motor, opening the door to sophisticated mechatronics applications. Our design leverages the low cost of mass produced stepper motors. We are able to achieve very high resolution via 14b encoder feedback (after calibration routine!).

image

Project Goals

  • Position, velocity, torque loops
  • Step & direction inputs for drop-in compatibility with stepper motors / step stick
  • I2c, serial inputs
  • Customizable/open source with access to internal variables
  • Transparent and user-definable control algorithms (commercial servos often lack this)
  • Arduino compatible with easy to use interface
  • High resolution pointing (sub 0.1 degree)
  • Low cost (should not be a huge leap from stepper + stepstick cost)
  • Serial interfaces for inter-motor communication
  • On-board processor allows for stand alone for simple applications
  • Adjustable commutation profiles
  • PID auto tuning
  • Anti-cogging capable
  • Open to customization. Outside of our firmware, we see Mechaduino as a very useful hardware package. If you would like to use the stepper motor in open loop mode w/ encoder to verify location, you can do that.

Strategy

An industrial servo motor can be broken down into four main components (below). First we looked at each of these components and tried to piece together an affordable breadboard-level prototype. After some experimentation, we were able to distill out a working lineup of components. From there, we've been iterating on our design, working out all the kinks, and tuning the control loops. It's starting to come together!

...Back to those four main components:

  1. The actual motor, usually of the brushless dc variety. When you look at industrial servo motors, a big chunk of the cost is the motor itself. They are often custom built, or at least built in limited quantities, which means $$$. Watt for watt, I'd guess that a mass produced NEMA 17 or NEMA 23 stepper motor is between a tenth and a hundredth the cost of the BDC motors used in industrial servos. Although their design is optimized for "stepping," stepper motors are really just 50-pole brushless dc motors. They can be controlled exactly like a more traditional 3 phase BDC motor with more poles. So that's the plan. It's working!

  2. A sensor for feedback, usually an encoder. Optical encoders are pretty standard, but get quite pricey if you want high resolution and/or absolute position information. We were intrigued by some of the cheap, high resolution magnetic encoders offered by vendors like AMS. It turns out that although they claim 12 and 14 bit resolutions (that's 0.09 and 0.02 degrees respectively), they suffer from non-linearities on the order of a degree or so! However, we found that this non-linearity is very repeatable, and we were able to develop a quick, self contained (on motor) calibration routine that restores resolution to better than 0.1 degrees. (More on this later. This was a significant design effort and is worthy of its own build log!)

  3. Drive circuitry/power electronics to excite the motor windings. Many industrial servos use discrete H bridges. Each phase requires it's own H bridge ( for a two phase motor... half bridges for each in a three phase motor), which consists of at least 4 if not 8 (...including freewheeling diodes) discrete switching devices. Throw in gate drive circuitry, and things start to get expensive. We hoped to find a single-chip, integrated solution that would allow for current feedback, and we found just that in the A4954 dual full bridge PWM driver.

  4. Control Electronics. Usually a microcontroller or FPGA. Early on, we decided that Arduino compatibility was a must in order to make the firmware as accessible as possible. We chose to use a SAMD21 ARM M0+ (Arduino Zero compatible) processor to balance cost and performance. Our breadboard prototype system verified that this processor was more than capable of executing the necessary algorithms.

Application Examples:

  • Fine, closed loop positioning for 3D printers
  • Fine pointing for optics (laser, telescope, camera gimbal)
  • Velocity loop for a record player
  • Force feedback/impedance control for robotics
  • Force feedback for gaming controllers
  • Adjustable mechanical impedance: virtual spring,mass,damper
  • Electrical gearing between two axes on a cnc machine, etc.
  • Haptics
  • Tele-operation
  • Gravity-cancellation (counter the gravitational torques on a robotic arm for example)
  • Load detection and characterization (simple case: use as a scale!)
  • Paper towel/tp dispenser
  • Variable load (brake)
  • Variable load (generator)
  • After market valve control (automate a garden hose, etc)

Other Advantages:

  • Finer resolution than stepper motors (0.02 degrees)
  • True closed loop for disturbance rejection
  • Lower power consumption: only uses power to fight disturbances. This in turn means higher peak torque.
  • Absolute position control (not incremental). No need to home on power-on.

License

All Mechaduino related materials are released under the Creative Commons Attribution Share-Alike 4.0 License

mechaduino-hardware's People

Contributors

biosafetylvl5 avatar jcchurch13 avatar thantik avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

mechaduino-hardware's Issues

Opensource.com article

Joe,

Apologies for opening a github issue, but I couldn't find an email address for you. I'm writing an article for opensource.com on some of the best open source hardware innovations in 3d printing in 2016, and I want to feature the Mechaduino. Would you be able to point me to a picture of the Mechaduino (maybe the "banana" picture from the kickstarter page) that I could use under a Creative Commons license (CC-BY-SA would be ideal)?

Thanks in advance,

Tom Callaway [email protected]

gerber file

can you share a gerber file for the v0.2 ?

AS5047D Magnetic Encoder Power Management issue.

I was checking over the Datasheet for the AS5047D Magnetic Rotary Position Encoder

The section on power management has two configurations. One for 5V operation and the other for 3.3V operation.

For 3.3V operation it states -> "In 3.3V operation, VDD and VREG must be tied together."

In Figure 10 the "3.3 Operation" diagram shows VDD and VDD3V3 tied together with one 100nF cap to ground.

It would seem to me that C17 1uF should be removed from this circuit and pins 11 and 12 of the AS5047D should be tied together.

This could easily be fixed on the current board by a small bridge between C16 and C17 on the top of the board after removing C17.

PS I also reported this to the Mechaduino Google Group

BOM mismatch between Value and Device - IC2 3.3V regulator - line 31

BOM Line 31 shows 3.3V regulator AP2112K-3.3 as the value however the specified device is AP2202-ADJ.

The AP2202-ADJ needs additional circuitry on pin 4 to set the correct output voltage.

Perhaps update the BOM to reflect the correct device?

1 AP2112K-3.3               AP2202-ADJ                             SOT23-5@1                     IC2

Feature request : Gadgeteer port

Hey.

As part of the Smoothieboard v2 hardware design, we are planning a very complete series of "extension boards" : goo.gl/XP5iZc
Those boards will all use the "Gadgeteer" socket. It is small, it's a very nice and well designed standards, a lot of boars already exist for it. We also hope to encourage other Open-Source controller board designers ( running Smoothie or otherwise ) to also use these in their hardware.
If you were to add a Gadgeteer port to your board, that'd make it super easy to interface will all of the Smoothieboard v2 hardware boards ( and possibly other boards in the future ).
What do you think ? Maybe for a v2 of your hardware ...

Cheers.

NEMA 34 and larger?

What would be required to make this work with larger stepper motors like NEMA 34 etc.?

hardware serial rather than USB

Hello All

Apologies for asking a question that may seem trivial, but I haven't been able to find an answer here or in the forks I was able to examine.

I was hoping to be able to use the serial interface, but over normal serial pins rather than USB. Are any of the existing pins available on the board attached to a serial peripheral? I realise I'll probably have to write up the serial handling myself, and happy to give that a shot, but in case there is another project that has done the same I'd be happy to take a pointer to such a project :)

Vector control

From what I can understand of the firmware, and from looking at the schematic, you are missing out on field / vector control of the motor. With vector control you control the torquing current and the "magnetizing current" (think of the current that is 90 degrees out of phase with the torquing current). This allows for a few things:

  • Easy "current advance" and it's more general cousin "field weakening" which is advance past the point needed for just overcoming inductance. It allows a much higher top speed when torque is allowed to decline.
  • Better position accuracy (and lower position latency) by combining the encoder with the driving currents and a motor model through a Kalman filter. This especially would help here with the 50 pole motor.
  • Some amount of force feedback
  • Quieter and cooler operation through sine-drive commutation over square wave. I can't tell exactly what you have implemented now from a quick look at the firmware, so this one might not count.

The reason I bring this up in the hardware project is that you are missing motor feedback that is needed to allow this. The "normal" way to do vector control is to control the phase drive voltages (via PWM) and sense the phase currents. To do that you would need to add an amplifier to bias and scale the current sense resistors, and ADCs (maybe in the MCU already? I didn't look) that can sample at least around 40 per pole, or 2000 times per rotation on a 1.8 degree stepper.

Another option that may be possible (I'm making this one up as I go along, I don't know if it's been done before or disproven)... Since you are using a bridge driver that self-regulates current, I think it might be possible to implement vector control using a "control the current, read the phase voltage via PWM transitions" model. This would depend on being able to change the current Vref values at at least a few times per pole to control the phase current directly, and having some digital feedback from the motor phase outputs to know when the A4954 switches between internal PWM modes. This method would only need a diode or two and some resistors for each of the 4 motor leads. The big sticking point would be whether the A4954 Vref input has that kind of frequency response. I don't see anything to give a hint in the datasheet, so it might have to be determined by experiment.

Either of these methods would allow estimating the back-emf of the motor, which gives an estimate of motor position, and when combined with knowing the phase voltage or current give force feedback and the ability to directly control the 2 current vectors occurring in the motor.

Looking forward to getting some hardware... I'm glad someone is finally doing this!

License and Smoothieboard

Hey there.

Great project.

Both the hardware and firmware repos are missing a license file as far as I can see.
Once that's fixed and you confirmed it really is Open-Source, if you want we can send you a free Smoothieboard to use/test with your system.

Cheers.

Feature request: Trinamic drivers

Any word of advice on interfacing trinamic drivers on board instead of the a4954 stepper drivers? This so stepper operation can be quieter.

Compilation error w/ Arduino 1.8.2 IDE

After opening the firmware Mechaduino_01.ino in Arduino IDE 1.8.2, verification fails with errors from gcc. I tried to google things up, nothing shows up. Maybe some problem between keyboard and chair. I am new to mechaduino so maybe I am missing something obvious. I looks as if types were not recognized, but there is no error about #include not being found. These are the first few messages. Thanks for help!

sketch/analogFastWrite.c: In function 'syncADC':
analogFastWrite.c:17: error: invalid type argument of '->' (have 'uint16_t')
   while (ADC->STATUS.bit.SYNCBUSY == 1)
             ^
sketch/analogFastWrite.c: In function 'syncDAC':
analogFastWrite.c:24: error: 'DAC' undeclared (first use in this function)
   while (DAC->STATUS.bit.SYNCBUSY == 1)
          ^
sketch/analogFastWrite.c:24:10: note: each undeclared identifier is reported only once for each function it appears in
sketch/analogFastWrite.c: At top level:
analogFastWrite.c:29: error: unknown type name 'Tc'
 static __inline__ void syncTC_8(Tc* TCx) __attribute__((always_inline, unused));
                                 ^
analogFastWrite.c:30: error: unknown type name 'Tc'
 static void syncTC_8(Tc* TCx) {

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.