Or a 1000W cheap standard inverter and a fan-heater? 
Grid-tie inverters are also pretty expensive… (and dangerous)
The newest software (rc0.5.0) includes the ability to regen back to the power source up to a configured value, and if you’re generating more current than the configured value it will start dumping to the brake resistor. Also, the brake resistor / bus voltage suppression was improved, and it’s much better at clamping the bus voltage.
What specific to that motor gives it poor static torque performance?
I.e what should I look out for on a motor to avoid this issue?
Something like this might do: https://www.aliexpress.com/item/32364452023.html
Only trouble with that is it has some residual friction / cogging so you won’t be able to set it to a zero or a completely constant torque.
Not sure what you mean by “static torque performance” but I’ll take it to mean “low torque-ripple” since that was what I was going on about.
Most PM synchronous / brushless motors designed for power density (i.e. all hobby motors) have cogging which is an effect of mixing permanent magnet rotors with iron stators - the magnets ‘prefer’ certain positions around the motor, where their total ‘closeness’ to the iron has local maxima. This is also known as a varying ‘reluctance’ iirc.
Cogging can be compensated out in software using a high-resolution encoder. Measure the current required to hold position with no load at every position on the motor’s rotation, and then add that as an offset from a lookup table in future. The ODrive has some (Beta) support for this.
The second issue is ‘magnetic hysteresis drag’ - this is also a product of using permanent magnets and iron, because as the magnets move past the iron, they will polarise it this way and that. Re-polarising a piece of iron has a finite energy cost, so you effectively feel friction on the motor even if there is none in the bearings.
so-called coreless, ironless or slotless motors do not experience any cogging or hysteresis drag, but they are more expensive and have a lower torque density (since they don’t use iron to amplify the field of the coils)
And thirdly, you have torque ripple caused by the geometry of the motor. The torque produced by the coils for a given current will change slightly as a function of angle. For example if the magnets are flat, then this will cause some variation (some motors e.g. expensive T-Motor use curved magnets to reduce this effect) or if there is some variation in the air-gap between the magnets and the coils.
The cheap 8318 produces a lot of torque because it has big magnets and many poles - but that also increases the hysteresis drag, cogging, and other torque-ripple effects.
You could look into ironless axial-flux motors. They can even be wound by hand, much more easily than other types of motor.
As an update I’ve most of this CAD’d up now, with a suitable load cell etc selected.
I wanted to check if an 8318 drone motor is going to be suitable for the torque range I’d like to test.
Test Motor: 62.5Kv, 2.1Nm nominal, 6Nm peak torque.
SInk Motor: 8318, 100Kv
I know I will run out of RPM on the test motor before the sink motor (so all is fine here), but how would i go about checking that the sink motor can handle the torque range I want to measure?
Based on an 8318 motor with max power of 2900W, at 14S (58.8V peak), I get a max torque of only 4.1Nm. I will probably not need to run much pas the 2.1Nm rated torque of the test motor, but it’d be nice to have the capability to run in this higher power region.
100 rpm/V equates to about 0.1 Nm/A iirc, so you’d need about 43A to produce 4.1Nm. From my experience with 8318 Kv100 motors, they can handle up to about 30A at stall, i.e. 3 Nm. They could probably sustain 43A, but only when attached to a propeller and nothing else (ie a great big cooling fan)
Where’s your encoder in that CAD?
Also, what kind of coupling is that? A solid coupling might produce some strange results, as it will be straining your bearings against any mounting misalignment / runout.
Spiral couplings are terrible for stiffness, and they fail easily. I’d suggest double disc couplings, but they can be quite expensive.
Do you know of any motors that might be more suitable to that torque range?
There’s a stub out the rear of the test motor that the encoder mounts on.
I believe i specced a Huco flexible coupler (CAD is just a package model) but need to triple check.
No, these are the best I know of in the hobby market. Unless you go for something from T-Motor. But those guys are obnoxiously expensive.
Huco make disc couplings too.
You need an encoder for each motor. You cannot use the encoder on the test motor for commutation of the load motor, because there is a compliant mechanism in between. If the coupling were to twist by one degree, it would have a significant impact on the relationship between current and torque in the load motor.
Also, you don’t want to have to recalibrate the load motor every time you move the set screws on the coupling.
Also, ODrive does not support using two motors with one encoder.
Unless it was an incremental encoder I suppose, in which case you could connect the same encoder to both inputs. But it’d be a nasty hack.
Ah cool cheers.
Can I not operate the sink motor in sensor less mode? If not do you know of any encoders with a large bore size?
Maybe you could run the load motor in sensorless mode… It depends if you are interested in low speeds (below 600rpm or so) or not.
Sensorless mode works well when there is no load at low speeds (i.e. with a propeller), but it cannot produce a reliable torque at low speeds, and is useless at stall.
You can get off-axis magnetic encoders which use a large ring-magnet with many poles. They are extremely precise, but unlike on-axis magnetic encoders, they are not absolute, so they will require calibration on every boot-up.
Ah thanks. I do probably want to operate in conditions all the way down to as close to zero RPM as I can get.
I’ve just about managed to package in an AS5047P encoder board (https://www.digikey.co.uk/product-detail/en/ams/AS5047P-TS_EK_AB/AS5047P-TS_EK_AB-ND/5452344)
Annoyingy the 8318 bolt pattern isn’t wide enough for them to clear without going down to really thin wall thickness spacers. I may wrap the edges of the PCB with some electrical tape to prevent a short.
I suppose for attaching the magnet to the motor shaft, I could print a very small adapter or perhaps just get away with glueing the magnet to the end of the bolt and then spacing the sensor PCB accordingly
Yeah, fast-setting superglue works really well in my experience.
The spacing to the magnet can be as little as 2mm. You could probably make those mounting legs shorter (& therefore stronger). Perhaps have some triangular buttresses to support them when the whole thing is going to be under torsion?
You could add four 2.5mm pillars to locate the holes in the PCB, instead of screw holes. Then use tape as you say to secure it.
How is your adapter made? Is it 3D printed or are you sending off for some parts to be machined out of stainless?
You could always make your own PCB for the AS5047p I suppose.
Ah cool yeah I’m planning on spacing up the encoder once everythings assembled. I’d rather give myself too much space to work with rather than too little in case I need to modify parts.
Yeah the bulk of the frane/flanges will either be steel or ali machined in Uni.
Thought I’d update this post given most of the mechanical design work is now done and components are starting to be ordered over the Winter exam period.
It was looking like the 8318 was going to be somewhat limited in terms of peak torque compared to the motor we wanted to test.
So, bit of a rethink and I’ve updated things to reuse our previous BLDC motor (uses built in Hall effects) with a very fancy rotary torque sensor that the team is kindly being supplied.
Shown below are CAD images of both powertrain test mode, as well as the wheel inertia measurement setup.
One question I do have is how rapidly can the torque command be updated?
I’m planning on programming a full vehicle simulation mode whereby the load on the test motor is varied to match that of the rear car (including inertia effects, and the load vs speed profile).
I can’t imagine I’ll need to update this faster than say 5Hz as eco-marathon vehicles run at very low accelerations to minimise losses.
In excess of 1kHz via USB, a little less via ASCII RS232, probably >1kHz via native RS232 or CAN 
Is that one of those Sensor Technology TorqSens transducers? I used one on a similar rig
don’t break it!
Sweet, should have no issues then (in theory 
).
It is yeah. It’ll be treated like a new born child believe me.
Did you find anything from using/implementing it thats worth sharing?
Yeah, be careful about couplings, mounting and alignment. Any radial force due to mounting misalignment will be seen as a spurious torque reading.
That’s why we ended up using the expensive MDW double-disc couplings that I mentioned earlier. They can take quite a lot of misalignment and are extremely stiff, which we needed for our measurements (torque ripple & friction of a motor and gearbox)
Also, their software was pretty horrendous. Written in some kind of LabView/VB/ActiveX abomination. 
But they do have an API, which for me was easier to use.
We also had some ground loop issues on the USB, which we solved worked around with a USB isolator.
The sensor itself is very nice though. Almost zero friction, completely non-contact “Surface Acoustic Wave” thing. I think it works by searching for the resonant frequency of the rotor element, which changes depending on load.
Don’t over-torque it though. I’d advise to fit fuses in line with your motor phases, at a current corresponding to a torque equal or below the sensor’s full-scale torque. IIRC the sensors can withstand no more than 3x their full-scale torque before they are permanently borked, and that applies if they are on or off.
1 Like