I´ve been working on a project lately but I´m having trouble getting my motor to start up and run consistently. My 149kv aero drive motor is in an oil-filled housing with a 1:30 planetary gear (Running at 1000RPM on the motor with 500RPM/S ramp = 33RPM on the gear). It´s also hooked up to a load which is making the calibration fail. I´m getting CPR out of range. The problem is that I cant increase the calibration current or running current to over 25A before getting a motor failure. Even when it calibrates, I can’t seem run it for very long before it shuts down and I need to restart the entire system. (I think it could be from current spikes as the load suddenly increases…) I´ve had it running at 70 amps before. hmmm . Looks like the load is more than the motor can turn at 25 amps, and is making the setpoint drift ahead of the actual position during velocity control.
Could there be a problem with the encoder (8192 CPR) being submerged in thin oil?
Does current control mode require the motor to be calibrated?
/how do we run a motor without calibration every startup (Motor/encoder calibration = True + only Index search on reboot?)
I read on the forum that with high torque motors you can desolder some resistors, is the 149kv aerodrive considered high torque? in that case, what does the desoldering actually do?
Does anyone have a good python script for ramping in current control mode?
I can’t pinpoint a specific problem after a few weeks of trial and error with and without load. Any advice?
Also, I can´t seem to get the Odrivetool plotter to initialize when SSHed into a Linux machine. Maybe an issue for the Github repo? or just something I’m missing.
Adding some photos for reference: (I have more, discourse just won’t let me post them)
It could be an issue, because the encoder is cacacitive and the oil might very well change the capacitance between the encoder disk and the meassurement points
Okay this looks pretty interesting. Some questions:
Have you ever had this successfully working?
Are you trying to run this with or without a load? I would suggest first getting things to run without a load.
Is it possible to mount the encoder so it’s not submerged in oil? I’ve never heard of anyone running these encoders in oil. Might be okay, I’m not sure, but I’d test it in a way that’s known to work first
What control mode are you trying to use this in? You mention current control mode and velocity control mode.
What are the specs for your motor? 25A for calibration seems huge.
Hopefully I can answer a few things!
Current control just uses current feedback, no encoder feedback. This means you need to calibrate the motor, but calibrating the encoder is not necessary. See here for the control diagram.
To save the motor and encoder calibration (only do index search on boot), check the thread here
What I think you’re referring to is changing shunt resistors for low current motors (see here). This gives better current feedback because the range of measurement is more appropriate for the actual range of current draw. Usually this is relevant for motors drawing around 10A or less. I wouldn’t worry about this in your case.
Why do you want a Python script for this? The ODrive has a built in setting called current_ramp_rate (odrv0.axis0.controller.config.current_ramp_rate). I haven’t played with this myself but you could try this. That said, it largely depends how you intend to run this. You usually shouldn’t have to change much in current control unless you’re running this mode directly.
Are you doing x forwarding over SSH? The plotter uses matplotlib which most likely requires a display to function. If you’re just SSH’d in you wouldn’t have a display to output to.
I have had it working before, and it works now. Only 95% reliably.
Without a load it’s flawless. With a load, it chokes a bit.
This thingy will be 400 meters under the ocean in a couple of days and therefore needs to be oil-filled (or it will implode fantastically ).
I am trying different modes of control. Would prefere velocity control because I need to get a smooth ramp up & ramp down. Current control mode is working better but is very “digital” in operation. Using time.sleep function in python and setting amps is a bad way to do it. Maybe multi-threading is an option? Anyway, this might be the wrong place for that discussion.
I’m currently only doing index search on boot, and it’s working (almost) all the time. At 35A… With a spring load. Due to the reduction gear, the movement is very small on the gear assembly, which is helping a lot.
I need to control the motor with a python script because I’ll be piloting it over satellite connection. I have a custom server I’ve written running in an atmospheric flask (pressure tested to 40bar), and a client running on a pilot computer about 300km away. Were talking ethernet to fiber to satellite to ethernet to fiber to ethernet connection with a horrendous number of VPNs, router, switches and converters along the signal’s 70 thousend kilometer journey. (!!)
I cant seem to find the current ramp feature you speak of, maybe I’m on the wrong branch? The Odrive is only a month old so I would have thought I had the lastest firmware.
I must say I’m loving the challenge, but time is of the essence and I would love to iron out the last few kinks.
I am looking at swapping out the encoder with an absolute one. It’s the same dimension which is awesome. Ditchin’ the entire index thang.
The brake resistor also threw up an error once. Hope it hasn’t melted. Not easy to check.
Wow, that is really exciting!! Hope everything goes well
From my experience absolute encoders have worked very well. I would suggest switching to them to avoid startup movement completely. See here for info on setting that up!
For your control mode, do you care about the end position? Or you just care about the velocity? If you can use position control, ODrive has a trapezoidal trajectory planner! You can limit the max velocity and set the acceleration and deceleration parameters. This gives a very smooth ramp.
Given the impressive distance and potential points of failure between you and the ODrive I would really suggest you set up some sort of watchdog. ODrive has a built-in watchdog but it’s disabled by default. I haven’t used it myself so I can’t give too much info about that. Regardless though, you may want to have an external watchdog that can power cycle the whole board if something gets stuck. Just a thought
If you want to use the absolute encoders (or the trajectory planner I think) you’ll need to flash different firmware. The ODrive comes flashed with firmware from the Master branch, you need RazorsEdge branch. Here’s details on that.
Can you check the resistance of the brake resistor to verify it? It’s most likely just fine, they are usually pretty resilient and often the brake resistor errors are not actually because of the brake resister…
).
