madcowswe
Joined 9 years ago
Karma
106
Submissions
9
Member since
May 6
Recent submissions
Comment · 9 years ago
Ignore the red circle/arrow, this is just a picture I found online.
Comment · 9 years ago
Position, velocity and current/force are the currently supported modes, see: https://github.com/madcowswe/ODriveFirmware/blob/master/Moto...
Coming soon will also be go-to commands which track 3-rd order polynomial position trajectories.
Comment · 9 years ago
The hobby outrunners come in both varieties: the cheaper ones are surface magnet ones, like this one: https://hobbyking.com/media/file/1010923149X745660X9.jpg
and the slightly more expensive ones have the magnets recessed into a thicker back-iron, and hence have saliency: https://www.electric-skateboard.builders/uploads/db1493/orig...
Comment · 9 years ago
One thing to keep in mind is that for many robotics applications, the duty cycle for high torque (i.e. acceleration) is often quite low. So they may still run fairly cool.
Comment · 9 years ago
I have compiled a small list of motors that I think are suitable for robotics applications, along with some useful calculations, here: https://docs.google.com/spreadsheets/d/12vzz7XVEK6YNIOqH0jAz...
You can take a copy of the spreadsheet and enter in your own motors that you find. Also do note there is a second tab on the sheet that lets you explore cycle times on trapezoidal trajectories.
Comment · 9 years ago
Thank you!
1. Thanks for the suggestion, I have DB-DTFC to my motor control theory bookmarks. There are a few reasons I am sticking to FOC for now. The main one is that it is, as you say, the more standard one used, and hence there is more material on it which makes it easier. The other reason is that I read that you need high quality current measurement to get a good flux estimate: if your flux estimators are not high bandwidth, you aren't getting the extra control bandwidth anyway, and there is no point. The ODrive is trying to be as inexpensive as possible, hence the current sensors have a fair bit of noise.
2. Yes the decoupling terms will be added soon, it is something that I know should be there but wasn't a priority to put in once the motor was up and running (there is a thousand of other tasks I have to do to get this product out). The control engineer in me won't rest until all the standard feedforward terms are there ;D
3. Yes, I actually implemented a sensorless estimator based on this paper: http://cas.ensmp.fr/~praly/Telechargement/Journaux/2010-IEEE... It is a non-linear flux estimator, so it won't work at zero speed. I did look into the high frequency injection techniques as well, but haven't implemented any of them yet. Right now there is no sensorless estimator in this instance of the code, and I don't think we will need one for the basic demos, since they will all require accurate enocder feedback anyway.
4. Okay, I'll look into it!
Thank you so much! I actually took the liberty of copying your reply over to the ODrive forums: https://discourse.odriverobotics.com/t/control-suggestions/5... This is so that I can easier refer back to your excellent advice even once this HN topic fizzles out. Cheers!
Comment · 9 years ago
So this product is still in development. Hence the hardware is ready for regeneration, but right now the firmware doesn't support it yet.
In principle it works by just putting a high charge current capable battery on the DC bus, and simply dumping the regeneration current onto the bus, and the battery will eat it, as the bus voltage rises.
The "Architecture" heading, a bit down on this page explains more: https://hackaday.io/project/11583-odrive-high-performance-mo...