Even in current control mode running at a constant setting the brake resistor is still getting hot. Should that be happening?
Just a funny thought but have you set ddc_bus_overvoltage_trip_level =
ddc_bus_undervoltage_trip_level =
Or maybe they are the shut down levels, but some where you must set what rail voltage the braking resister is switch on and starts dipping the rail down, sorry Iâm not sure as we are running off a battery with no brake resistor connected or function nut maybe yours is set at 24v still but your trying to run it at 30v? Just a thought.
Nope, was still set to 8V and 51V. I did some testing and it looks like as soon as you hit either of these values it throws a error code and locks up the ODrive.
I am wondering if it could be caused by me guessing the pole pairs in my motors wrong. The motor cogs 20 times while rotating by hand. So I went with 20 pole pairs. Strangely if I select 10 pole pairs it still seems to go at exactly the same (correct) speed.
Because at base speed the drive physically cannot generate a significant positive current in regular control mode, this is basically the definition of base speed. Itâs not âtryingâ to generate a low/negative current, nor trying to slow down, itâs trying to go but canât. Iâd recommend operating into the base speed limit, as the current control isnât operating nominally at that point.
In current control mode, usually the motor will either spin quite slow or spool up to base speed. If you spool up to base speed, you have the same problem as above.
Nope, the brake resistor logic is based on current, and has no voltage-keeping feedback function right now. We may add that in the future though.
The sensorless control is in electrical units, so the settings for pole pairs is actually unused, and the speed wonât change.
Thanks Oskar
Sounds like I am finding problems where none exist.
I find it unintuitive that we are dumping power into the brake resistor in very similar amounts either running just under the base speed of the motor or trying to attain a speed above the base speed. Doesnât power being dumped into the brake resistor imply the motor is being slowed down?
In my project the motors will be mounted in a 3D printed R2D2, and will be running off lithium ion batteries. I believe in such an arrangement I donât need to use the brake resistor, which is lucky as it would probably melt PLA.
Martin
Hi Ben
Iâm looking at these motors too, do they work OK for you at low speeds? Would you be able to share the settings/ config you are using if so?
Thanks
Sam
Yes with encoder the motors can just creep along.
Here is a crappy promotional video I made.
Our project is using Robot operating system (ROS), we made and published a ROS node for the odrive. We are using a lidar on the head to workout where the device is within the room and navigate around and dock into the unloading station.
We are finding that we still either have some noise or mechanical dust on the encoders, so we sometime miss or get extra encoder pulses and this can slowly mean the encoder based position model is out from the physical motor position and then the motors do not produce correct torque and do not get to position so the controller feeds more power in. This is not an issue with the Odrive but would be nice if the odrive monitored index, and checked it made sense when seen and errored out, instead as a band aid solution we monitor heat, which we are doing both with a software model, tracking current over time and a physical temp sensor but a better method would be index checking each rotation. The challenge is that we donât have a true index on the encoder, instead we are using one of the Hall sensors as a index. Meaning it is seen multiple times per rotation and not a nice narrow notch like a true index, but varies depending on speed and direction it is seen from.
One issue is when the position gets out the motor can drive out of control at great speed and we donât necessarily catch this in time with temp monitoring. For some reason the setting the odrive to monitor and error out on overspeed doesnât catch this either, so the encoder error must mean the velocity tracking model is out as well and the max velocity is not simply raw encoder counts per second. Would be a great safety feature if max velocity was raw encoder, we might need to implement an external safety monitoring circuit to do just that.
Regarding axis settings, I donât have them, I only initially got it working as a feasibility test and all further calibration and control of the motors has been done by a colleague that is on leave at the moment.
Hmm⌠it should fault out for that, I donât know why it wouldnât.