I’ve found the same. I would love to see some high quality encoders from a company like CUI.
A single motor driver is a good idea, but with reservations.
At first, there is a tendency to equip BLDC referred above (big diameter, short axial size, a lot of poles) by the magnetic encoder. Encoder integrated by motor probably is a better solution that encoder integrated by the driver.
A second, there are at least two areas with substantially different requirements: CNC and CNC-like devices and “new generation robots”. Distinctive features of last one:
[1] Bigger number of motors that should provide coordinated moving (up to 18 and even more). This means that single motor drive is a preferable solution,
[2] In a difference with CNC, new generation robot intended to use in non-special environment where any moment some obstacle may affect moving, and such situation is not a failure rather routine sequence of events that of course should be processed by parent unit that control a few motor boards. So motor board should be programmed to notify parent unit about the impossibility to execute the command.
[3] A huge number of motors makes step/dir mode impossible or unreasonable; a reasonable way of providing coordinated moving by a few motors is to load kind of moving short program prepared by parent unit into each controller then command to start.
[4] Points [2] and [3] means that mission-dependent part of controller code must be written by the customer. To be able to do this, customers require detail description of the source code and clear separation of two segments, common segment, and mission-dependent segment. PID-based control must be part of the mission-dependent segment that can be replaced or modified by the customer.
[5] USB as the main communication channel is questionable in case of a huge number of actuators; CAN and serial one are preferable, but USB is useful for board reprogramming.
3 Likes
Putting heatsink on the case of the mosfet is not very good solutions for cooling since mosfet case has bad thermal conductivity. The best way to cool dowm mosfets it to put thermal vias to transfer the heat to bottom layer and but heatsink on bottom layer.
2 Likes
This is definitely interesting. Personally I think a step-direction interface is a must for this single motor board, since that would turn it in to a drop-in replacement for stepper motors. For that reason I also think high torque is important, at least 1 Nm (preferably as high as 1 Nm continuous and 2 Nm peak). Most servo applications may still require gearing of some kind, but the lower the gear ratio the better (and when you can go directive drive that’s fantastic)
Naturally this has applications beyond stepper motors, so a drop-in replacement for steppers is far from the only use. I’m just saying that it should have this ability.
With calibration the magnetic encoders can turn out quite well, and could easily be calibrated using a high resolution optical encoder at “the factory”. The question is how often this process must be repeated by the end user? If necessary, I’ve been thinking that temporarily attaching a flywheel to the motor axle could also be used to calibrate the encoder. Spin it up to speed at low current and figure out the inaccuracy of encoder by assuming that it rotates at a constant speed, and comparing the calculated position to position reported by the encoder. The flywheel just needs to be big enough to filter out the torque ripple in the motor to a level below the desired tolerance.
1 Like
Yes, I was thinking to offer the biggest motor that makes sense, mostly for the torque capability, for this very reason. Later we can expand the supported motors (at least sold from ODrive Robotics) to some cheaper ones too. Indeed it will support step/dir from day 1.
Yes I was thinking that perhaps we can use just the rotor’s inertia alone to calibrate. The basic version would be to spin as fast as possible, to raise the torque ripple frequency as high as possible, to let the inertia filter as much as possible. The improved version would be to spin at 100%, and also at 70% or so. Then we can compare the calibration curves between the two. Because torque ripple is an acceleration (not a position offset), we should be able to discern the two, and get the torque ripple map and position offset map at the same time. At least I believe there should be enough measured dimensions to do this with the two speeds.
Giving some thought to single drive board could you include option to use optical encoder instead magnet type.
One big advantage with high torque motor to easily build XY slides any length with static lead screw and spin motor with nut round shaft.
So no high cost machining to shaft just saw to length and clamp to machine.
Also no whipping shaft with smaller diameter can be used for longer travel.
Plan use hollow Gimbal type motor then fit adjustable nut and bearings fitted to carriage.
Think this could make building many types machine lot quicker and more accurate.
Paul
1 Like
Hello,
i am new here.
Is this a current design or pre beta? 
I want to start with the odrive Topic and search a small PCB to manufacture in china.
I am able to open Altium Files and i am also able to do measurements to help you.
Greetings from Germany
Hi Spechtrap,
This design is not finished yet, and so you would not be able to manufacture it. Actually I am not entirely sure we will be releasing the board files, it is a business decision that we have yet to finalize, so we’ll see.
Either way, when the design is done we’ll certainly need testers, so make sure to keep an eye out for the announcement.
Cheers,
Oskar
2 Likes
Very much agree with this post.
Any updates to the single channel odrive concept?
ODrive v4, which Oskar is currently developing, will be a single axis. I’ve also developed a single-axis iteration based on v3.4 architecture.
1 Like
Rad! Looking forward to it.
Do you have the design files for the single channel variant handy by any chance?
I really want to release them and wish I could, but I completed it through my work at an engineering company and they are not allowing me to release the files. For what it’s worth, I’m planning on making my own iteration in late April.
1 Like
pjhayton, did you have to change the firmware a lot? I’m working on single axis board too and wondering what happens when odrive firmware finds out second motor driver IC is not present.
Only for the first iteration, because I took off the CAN IC (so I had to debug through the firmware and comment out any calls to CAN) so that was a nightmare.
With my latest rev, which includes CAN, I hardly had to change the firmware. I only changed the firmware to update my shunt resistance values, the dead time clocks (due to me changing the low-side gate resistor values), and my tup.config file to v3.4-24V.
Thank you for the insight. I hope this can become a community project cuz many people are interested in it. Please do share with us when you get the next design going.
Will do. I’ll be starting on it the last week of April.
Any news on the official single axis odrive?
Yes we are working on it. We are aiming to have beta ready by the end of the year, or maybe early next year.
You can sign up for news about it here:
3 Likes
I am also working on a single motor version based on Odrive3.5 but also re-purposing M1 signals and peripherals for additional features unique to my application. I modified the CubeMx project to remove M1 signals and peripherals and carefully merged the code. I am a bit confused about some of the functions in low_level.cpp and how to isolate M0 from M1 dependencies. Specifically sync_timers() and vbus_sense_adc_cb() . If you have any suggestion or if your new code can provide some information on how to do this, I would really appreciate any help.