I recently purchased an odrive and I’m intending to use it with a linear motor like this http://www.nipponpulse.com/catalog/parts/search/motors-linear-servo/part_id:17 to perform short, fairly dynamic motions (~3G’s acceleration, max speed ~3m/s). The principle of operation is just like a traditional rotary brushless motor - three actively commutated sets of coils.
I don’t have a linear encoder and don’t need high resolution positioning, so I was hoping to run it using hall sensors as feedback (my pole pitch is 30mm North to North). I don’t think sensorless operation is an option because it is probably not practical for the relatively low speeds I’ll be operating the motor at. Is there anything I’m overlooking? I’m particularly worried about messing up the initial setup - as I understand it, the odrive likes to “spin” the motor to calibrate its operation; with a linear actuator, of course, attempting to “spin” the motor will drive it past the operating range and probably break something.
I am building a linear encoder just like the one you describe. It works very will. You only need to spin/calibrate once, then the settings are saved. You will need some kind of end/start stop though, and this will need to be searched every time the ODrive is rebooted.
Thanks for the reply, but your actuator is very different from mine; you are using a rotary motor to turn a screw, whereas my actuator has no rotary component (or screw) at all. It is essentially magnets in a tube with commutated coils to drive the tube.
If I was using a rotary motor like you, I would simply use a traditional rotary encoder.
You should be fine, the default rotation distance for the calibration is 8 electrical turns (cycles). So if you leave it 8 pole pairs to move it should be OK.
Yes, I went down quite the rabbit hole with this project - I ended up building my own linear actuators from parts (wires, magnets, etc). You can find a short video of one such actuator being driven by an odrive here: Login • Instagram
In terms of integrating with the odrive - it is indeed the same as a rotary BLDC - just wire the three motor phases to A/B/C on the odrive and it simply works. In terms of position feedback - I tested two options: a linear encoder + mag strip, and a rotary encoder + gt2 belt/pulley (used in the video above). The latter option was cheaper and performed better.
Edit: I also tried getting position feedback with hall sensors as I described in my original post; this does work, but it’s not as precise or efficient as the above two feedback methods.
Any sort of specs for relative sizes, voltages, currents, turns/henrys, etc?
I can figure out the geometry for the most part but there’s a lot of non-linear interplay with available voltage deciding coil current deciding turns etc…Where did you settle?
My last thought is I’m tempted to use an accelerometer to give position feedback by dead reckoning - like how klipper firmware uses an accelerometer on the 3d printer head to compensate for open loop motion inconsistency. Better than hall, worse than encoder - but no external index needed.
There is indeed a multi-faceted interplay between the coil wire gauge, its inner & outer diameter, number of turns, current, voltage, rise time, thermal performance, etc. Deriving a process for finding optimal values for these parameters was a good chunk of the first stage of the project. Ultimately, I think you need to start with your power supply - specifically, your supply voltage and how much current you can pull. I ended up using 0.4mm magnet wire and coils with ID of ~13mm and OD of 22-26mm, length of ~6-8mm, and a ~20v power supply. Another primary constraint might be the magnets & tubes you are able to procure for the stator. It also depends on the duty cycle you impose on the actuator - generally speaking, more copper (bigger coils) gives you better thermal performance, since the applied power is distributed across a greater mass.
I very much doubt that an accelerometer would provide the positional feedback necessary to properly commutate the motor - IMU data is too noisy. Hall sensors would certainly perform (much) better. That said, as indicated in my prior post, I recommend a traditional rotary encoder linked to the moving element via GT2 belt or similar.
Really appreciate it Knowing a ballpark starting area to tweak from will surely save a ton of time (and money since copper is expensive).
In your 'gram video it almost looks as though the stator tube is carbon fiber…is that correct? Basically…everything is wizardry and finding ‘high magnetic permeability’ with ‘nonmagnetic’ with ‘doesn’t get eddy currents’ is troublesome. fwiw, I pledge to open source/share anything I build so again I really appreciate your help!
Yes, I used a CF tube for the stator, for two reasons:
The stator weight was a consideration for my application.
It was easier to find a dimensionally accurate CF tube, and easier to machine the inside if need be (though you definitely want good dust collection + ventilation + breathing protection while you’re producing carbon fiber dust!)
Hi - I am curious what the calibration setup looks like for this type of linear motor. Since out of the box calibration is expecting to do a few rotations based on a radial setup (radially aligned encoder and pole/pairs) how might I calibrate a non-linear direct-drive type of motor? Does it require setting end-stops, a max scan range, or somehow manually entering values and skipping automatic calibration? Any help is appreciated! I’m a little unclear what the pole/pair and cpr should be set like in this configuration as well (i.e. pole pairs for a full encoder commutation?)
