My only hesitation with the approach you outline is that I'd be going a
long way outside my comfort zone, though maybe this is the excuse I've been
looking for to learn some more electronics. I'm still tempted to have a go
at implementing the controlling digitally. If it doesn't work I'll probably
learn a bit in the process anyway. By the way, what do you mean by
And one more question - how in your scheme would you measure motor current?
The LMD18200 has a current output, but would it provide the kind of
On Wednesday, September 14, 2016 at 10:33:03 PM UTC+1, John Kasunich wrote:
> On Wed, Sep 14, 2016, at 05:17 PM, 'Luke Steele' via Machinekit wrote:
> > Hi John,
> > I'm intending to use a belt and pulley. I've spec'ed my pulley diameter
> > in theory I'll have sufficient speed and force.
> > In your experience what kind of frequency do you need for a current
> > feedback motor control loop?
> It depends on the response of the motor armature, in particular the
> armature inductance.
> For example, suppose your motor armature inductance is 1mH, and
> your supply voltage is 24V. When the PWM state is high, the armature
> sees +24V, and the current ramps up at 24A/ms. If you are sampling
> at 1mS, you will have a hard time controlling currents less than tens
> of amps.
> In reality of course, you aren't really applying 24V and leaving it there
> until the next control update. Your PID loop looks at the current error
> and generates a voltage command, then that command is turned into
> a PWM duty cycle. If you are using a hardware PWM generator then
> the 24V is switched on and off many times during the control interval,
> delivering the average voltage that your PID asked for.
> Regardless, low PWM frequencies (relative to the motor inductance
> and applied voltage) will result in a lot of current ripple. And low
> control update rates (relative to the motor inductance) will result
> in PID tuning that is difficult or impossible.
> Basically, the time constant of the motor armature current is one
> or two orders of magnitude faster than the time constants of the
> pendulums. That is good in one way - once you have your current
> loop working, you can almost neglect the lag due to current loop
> response and focus on the main control algorithm. But it is bad
> in that getting good current loop response with a sampled control
> loop can be challenging.
> If I was tackling your project, I would be very tempted to implement
> a hysteresis current loop in analog hardware. Subtract current
> feedback from current command in an op-amp. Send the resulting
> error signal to a comparator with hysteresis, and use the output
> of the comparator to switch the H-bridge. Knowing the supply
> voltage, motor inductance, and maximum desired switching
> frequency, you can calculate the current ripple. That becomes
> the comparator hysteresis. The resulting current loop is stable
> and fast.
> > Thanks for the links to the linuxcnc info - I'll have a read through. In
> > general though, what is the 'correct' way to achieve high speed use of
> > GPIOs on the BBB?
> > Thanks!
> > Luke
> > On Wednesday, September 14, 2016 at 7:21:01 PM UTC+1, John Kasunich
> > >
> > >
> > >
> > > On Wed, Sep 14, 2016, at 01:09 PM, 'Luke Steele' via Machinekit wrote:
> > > > Hi John,
> > > >
> > > > I'm planning to use a DC servo (an electrocraft E240 - because I
> > > one I
> > > > can borrow from a CNC conversion). Haven't selected an H-bridge, but
> > > maybe
> > > > an LMD18000 (also because I have some already), though maybe I'll
> > > > something with a higher peak current. I'll start with those two and
> > > how
> > > > I get on.
> > > >
> > > > Yes, controlled variable will be force. To be honest I haven't had a
> > > great
> > > > deal of experience with DC motor control (other than simple PID
> > > > speed/position controllers with no real modelling), so I'm expecting
> > > this
> > > > to be a challenge (a fun one, hopefully!). My vague plan at the
> > > is
> > > > to leave the servo unconnected, then try attaching a known mass (via
> > > cable
> > > > and pulley, and no pendulums) to the cart, then look at
> > > and
> > > > try and use this to establish my viscous damping etc. Then progress
> to a
> > > > force controller, again just moving a mass along the track (still no
> > > > pendulums).
> > >
> > > You also have to decide how to couple the motor to the cart. One
> > > would be to use a screw, where one revolution of the motor will move
> > > cart one screw pitch - likely 2-4mm. This would give you lots of
> > > but
> > > not much speed, and the motor inertia would dominate relative to the
> > > cart inertia. Or you could drive the cart wheels directly, meaning
> > > the motor has to move with the cart. Or you could use a pulley and
> > > with the cart attached to the belt and the motor stationary. In
> either of
> > > those cases, one revolution of the motor moves the cart by the
> > > circumference
> > > of the pulley or wheel, likely to be much more than 5mm. Bigger
> > > mean less force available per unit of torque (and current).
> > >
> > > > So anyway, I'll have three incremental encoders - one on the back of
> > > > motor, two for the pendulums. Then current consumption for the servo
> > > from
> > > > my h-bridge.
> > >
> > > If you close the current loop in software, you'll need a fast control
> > > thread and an A/D converter. Might want to measure the L/R time
> > > constant of the motor armature to get a feel for the bandwidth needed.
> > > It might be more than you can practically do in a general purpose
> > > controller like the BBB. Analog current loop (or even a simple analog
> > > hysteresis controller) might be the best choice for the current loop.
> > >
> > > > I thought the BBB looked promising as people are using it for motion
> > > > control. I'm not actually intending to use machinekit - my
> > > > was it's basically for CNC type applications where you have a
> > > precomputed
> > > > trajectory, am I wrong?
> > >
> > > Machinekit (and LinuxCNC) consist of two main parts. There is the
> > > high-level
> > > CNC application with GUIs and non-realtime code to interpret G-code.
> > > And there is the low level part, HAL and drivers and the realtime
> > > The CNC application isn't relevant to your project, but the HAL layer
> > > might be. It gives you a bunch of functional blocks that that you
> > > interconnect
> > > as needed. (in some way similar to NI's Labview, but without the
> > > GUI).
> > > It also gives you some handy testing tools - a software oscilloscope
> > > meter to look at signals as they flow between blocks, etc. You can
> > > your own realtime blocks in C, and non-realtime blocks in multiple
> > > languages.
> > >
> > > Skim thru this tutorial for a good overview that should help you
> > > if it makes sense: http://linuxcnc.org/docs/html/hal/tutorial.html
> > >
> > > --
> > > John Kasunich
> > >
> > --
> > website: http://www.machinekit.io blog: http://blog.machinekit.io
> github: https://github.com/machinekit
> > ---
> > You received this message because you are subscribed to the Google
> Groups "Machinekit" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> > Visit this group at https://groups.google.com/group/machinekit.
> > For more options, visit https://groups.google.com/d/optout.
> John Kasunich
website: http://www.machinekit.io blog: http://blog.machinekit.io github:
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.