May 21, 2016

Documenting all the things

I've been saying I'll post my design files and such online for a while now, so here it is.  Use anything at your own risk.

I've been using mbed to store and compile my code.  Here's the version of the code that's running the jumping leg.  I'm not a software person, so please don't judge me too hard on my code.  I went into this project thinking it would be a good idea to make all the code modular, but I think I went a little too far with that.  At some point I'll condense it all down into something a bit more manageable, and just keep things like position sensor code modular.  The current loops should have enough stability margin to work for a fairly wide range of small motors without any tweaking of constants.

Here are the python scripts that send serial commands to the motor controllers.

Here are the eagle files, gerbers, and BOM for the motor controllers and sensor boards.  When I sent the boards to 3PCB, the text the motor controllers got all scrambled so keep that in mind.  At this point I've built up three of each board, and they all work.  I haven't even blown up a single FET yet, in all of my motor control derping so far.

Here are my CAD files for the motor, gearbox, motor module, and leg.  Requires Solidworks 2015-2016 to open.  Many of the gearbox files have HSMWorks CAM in them, so you'll need the full version of HSMWorks to view the CAM.  There's also a list of the gears I got from KHK and the post-machining I did on them.

What's Next
I'm taking a break from for the summer, but don't worry, it's not getting abandoned.

Things I might do eventually:

Scramble the physical layout of everything to make it more robust.  No more sensors dangling off 3D-printed mounts, and I don't want to have to modify the motors in any way for the gearbox.  Probably move to a single-board design with both motor controller and position sensor on it.  Maybe get quotes for how much it would cost to get a bunch of the gearboxes made in China?  We'll see.

More motor stuff!  I'm in the process of building a motor dynamometer, so I'll be able to quantify dynamic motor performance.  This is something the MITERS circle of motor enthusiasts hasn't ever done.  Woo, science!

Thoughts on selling motor modules:  I've been asked a surprising number of times if I plan on selling these motor/gearbox/controller modules.  I definitely do not plan on it any time in the near future.  Maybe I'll give it more thought later, but right now I'm not interested.  Also, there's a lot more engineering that needs to be done to make this product-grade.

Oh, hey, I wrote a thing.  It's basically this blog half-assedly copy-pasta'd into Latex, and re-written in a slightly more formal tone.  There's fairly little that's not also somewhere in this series of blog posts, but hey, it exists.


Until next time,

May 5, 2016

Slow-Motion Jump

One more jumping leg post.  Bayley broke out his Photron high-speed camera last night, and we took some 500 fps video of the leg jumping.  Sorry it's so red, from a combination of incandescent bulbs and no IR filter on the lens:




Expect design files, code, etc.  to appear here in a couple weeks, when I'm done with classes.  Also, this is the 100th post on this section of my blog!  Only took ~4 years.

May 4, 2016

More Jumping

Last night I reworked all the communication to happen directly over serial, and hooked the leg up to a more capable power supply.  Performance was greatly improved.  Now the leg can max out the travel of the linear guide it's fixed to:


And the obligatory animated GIF:


That jump was actually still with a current limit set on the power supply.  Turning up the supply to max current, the leg can easily crash into the hard-stop at the top of the linear rail.  It actually managed to move the hard stop by a couple millimeters - I dialed back after that, because if the bearing manages to escape the rail, all the little recirculating balls will fall out.

I almost set it up for wireless control over XBee, but decided to take a nap instead.  Wireless communication with a small LiPo battery fixed to the leg, and no cables dangling off would be beautiful.

April 24, 2016

Jumping Leg

After 2 days of debugging (and only partially fixing) a mysterious SPI communication bug that appeared out of nowhere, here's a jumping leg:





A few things to note:
  - This is with current limited to 40 amps on the motor side.  For more current, I'll need to a smaller phase current shunt.  The current limit definitely gets saturated here.  The boards and motor can't handle that current continuously without real cooling, but seems to handle it just fine in bursts.
 - The linear bench supply powering things got pretty sad here.  You can hear/see it click into constant current mode, which certainly doesn't help jumping performance, and see the voltage spike as the leg lands and motors regen.  Needs more battery.
- This is at 12V, not the maximum 24-ish the controller's can handle.  Also, at peak motor power, the supply sags to ~8V, which may significantly affect jumping performance.

GIF infinite loop mode:


April 22, 2016

I'm Back to Building Robot Arms

Not really, but a sideways leg is basically a SCARA arm, right?

I milled out a simple 4-bar linkage leg.  Leg dimensions were roughly taken from the SMC robot.  It's really fun to prod at with different joint parameters.  Each motor controller takes joint position, stiffness, and damping commands in over SPI:



I threw together some quick Python command line tools for setting the joint parameters in real-time:



Time to strap it to a linear rail and make it jump, then hide away for a couple weeks to write my thesis and finish the other stuff I need to do to graduate.

April 13, 2016

Torque Ripple Characterization and Position/Impedance Control

I promised more science, so here it is.  I took some measurements of my motor's torque ripple  - its variation in torque with rotor position - at different current levels, to see how bad the ripple is, how easy it would be to compensate, and get a sense for how well my motor control is working.

The basic idea for this experiment was apply constant current to the q axis, and measure the torque out of the motor as a function of rotor position by slowly rotating the rotor through a single mechanical rotation.

The setup, from left to right:
Indexing head, a rewound 80-100 motor acting as a shaft, an S. Himmelstein rotary torque transducer, my Multistar Elite motor, and an optical encoder.


At the center of this setup is the the in-progress motor dynamometer I've slowly been working on, which will get documented in its own set of posts later.  The absorber (the 80-100 sized motor) is unused in this setup, and just acting like a shaft between the torque transducer and the indexing head.  The indexing head was used to slowly rotate the rotor.


I made an ER-32 spindle for the torque transducer, for ease of coupling to arbitrary motor shafts.  For these measurements, I used my test-motor setup with optical encoder, because coupling my motor module  pre-gearbox would have been difficult.


Here's the data out of the setup.  Turned out surprisingly well, I think.  Cogging torque shows some ripple at 2x electrical frequency as well as a higher frequency component.  Total cogging amplitude is plus or minus .025 N-m.  Bumping up the Q-amps, overall amplitude of torque ripple doesn't change too much over cogging torque, but becomes noticeably spikier.   I think some cogging torque compensation (which should be easy to implement via a  lookup table) would smooth things out pretty effectively.  But that's an exercise for a later date.  Straight lines in the plots are sections where I'm missing part of a rotation.


For the higher-current tests, I pointed a big fan at my motor and inverter setup.  Thanks to the wonders of modern FETs, the wires going to the motor were the hottest part of the setup at 24 amps, followed by the electrolytic capacitors, then the motor itself.

I wrapped some position and impedance control around my FOC scheme.  For the sake of running robots, high performance position control isn't particularly desireable - instead you often want to control leg stiffness and damping, so the position control is just a PD controller.  The proportional term corresponds to spring-stiffness of the joint, while the derivative corresponds to damping (both ignoring rotor inertia).  Here's what some different levels of springiness and damping look like:


Getting good damping performance is dependent on good velocity measurement, which is not trivial.  The gist of the problem is that differentiating your position signal sucks.  By the time you can filter the differentiated signal enough to have a nice looking velocity, the phase lag caused by the filter ruins your signal.  Fortunately, the MA700 sensor I'm using for position sensing has an encoder output as well as an absolute position output.  I'm able to use the encoder output to my advantage for velocity measurement.  By configuring one timer on the STM32F4 in encoder mode to keep track of encoder count, and then configuring another free-running timer as a slave which resets whenever the count changes, I'm able to automatically capture the time between encoder edges.  This gives a value inversely proportional to the motor speed, which gives good results for velocity measurement when combined with some logic to handle the zero-speed case where the count isn't changing.

With dumb differentiation (at my encoder resolution and sample rate), here's what a velocity output would look like.  Most of the time velocity is zero (because encoder position doesn't change during one sample period), and for samples where the value has changed, the velocity is 1 encoder line width divided by the sample period.  You can try to filter this signal, but the results are not at all satisfactory.



With the encoder period measuring scheme, here's what velocity estimate looks like, both using the raw period value and with some simple 1st order extrapolation to estimate between edges.  Much better.


It's a simple concept, but took about 4 days of staring at the STM32F4 reference and ST forum to figure out how to get this implemented natively.  And now that I have this code, I can stick it on my closed-loop subwoofer for improved performance there.

Next step is to build up another motor module, and cram two of these into a 2 degree of freedom leg.  And go copy and paste my blog into a latex document write my thesis, which is due in three weeks....

April 5, 2016

Motor Module

Another fairly unsubstantial post (as far as technical details are concerned), but pretty pictures.  I promise there'll be more science in the future.

Here's a motor + gearbox + position sensor + controller module assembled:



Cute feature:  The FETs on the bottom of the board heatsink to the flat spot on the gearbox.


At the other end is a small diametrically magnetized cylindrical magnet, glued to the rotor, and MA700 chip sensing magnet orientation.




Here's it spinning with the gearbox open.  Nice sound of dry-running spur gears: