Hi Folks,
I have been lurking here since the start and was wondering if anyone has done any more on the multi-axis sync issue. To date we have been using the excellent KFLOP product with closed loop analog servos but the ODrive project is always in view and continues to be of great interest for smaller projects. So far there apears to be a dearth of low end CNC controllers which can do full closed loop on multi-axis systems, I suspect due to the complexity of the problem. At best the step/dir interface generates the expectation that the closed loop servo following will be capable of keeping up.
In absence of any solid understanding of the area … The simple path would appear to be to use a common clock to drive the time steps used to drive the individual axis polynomials generating the motion profiles. If axes report the instaneous position errors at each time step then the emerging trend can be used to assess the axis loading capability in real time. A possibe resultant solution is to slow the master clock as then all axes are slowed by a proportionate amount. If this is still insufficient a feed hold can be triggered. This method would close the loop from the trajectory planner onward. It is not without it’s issues but at present the problem is largely ignored in most embedded open source systems. It should be noted that the goal is to keep real time constraints well away from the PC in a reliable embedded device.
ODrive currently acts primarily as a servo amplifier, and has limited motion controller capability. It has a trapezoidal trajectory planner, but that’s per-axis, it’s not designed to do multi-axis sync. I suggest you use something like LinuxCNC or a 3D printer controller (Marlin, smoothieboard, Grbl, etc) to do your motion planning today.
Wetmelon, Thanks for the reply.
The issue with Grbl et al is that they themselves do not ( as far as I am aware ) make use of closed loop feedback yet.
The question was put to see if anyone else had stumbled accross a hackable open source system which had incorporated the encoder feedback back to an embedded controller, thus keeping time critical code away from the PC. Examples of this in commercial systems are from Galil & as mentioned, the Kflop systems. The current goal is a low cost modular multi-axis system using Odrives and hobby motors with CUI encoders.
Perhaps the short term solution is to just generate an alarm if the motion profile is not able to be acheived by an axis and leave the closed loop purely at the motor servo end of things.
They don’t need to. They just have to give the servo amp a feasible trajectory. That being said, I believe I just talked to someone who said LinuxCNC can take feedback directly. We do plan to (eventually) add motion controller capabilities to ODrive, so it can take feedback from other ODrives and coordinate everything.
Yeah, we’ve actually thought about doing exactly that.
My plan was to still use a Kflop and keep it closed loop to the Kflop so the Kflop takes care of any errors, I’m planning to build a 5 axis CNC using BLDC motors. I have put a Kflop into old mill which has DC motors and encoders and works really well. I have also done some testing with the Kflop + Snapamp using BLDC and encoder and works really well except the SnapAmp is $400 and will require 3 of them. I have also tried some Chinese BLDC drivers and they are all useless. The major problem is the minimum acceleration setting of 300ms causes major issues trying to follow commands and trajectory. Also the low speed control is terrible. Having FOC and 0 -100% PWM and direction control on the Odrive would be perfect. Kflop is set to output an 10khz PWM signal and a direction output that is held high to change direction. I have looked into the code but no idea where to start to add these features. Having all the CNC control handled by the Odrive would be nice but don’t think there will be enough resources to do all that type of control.
… The simple path would appear to be to use a common clock to drive the time steps used to drive the individual axis polynomials generating the motion profiles. If axes report the instaneous position errors at each time step then the emerging trend can be used to assess the axis loading capability in real time. A possibe resultant solution is to slow the master clock as then all axes are slowed by a proportionate amount. If this is still insufficient a feed hold can be triggered. This method would close the loop from the trajectory planner onward. It is not without it’s issues but at present the problem is largely ignored in most embedded open source systems. It should be noted that the goal is to keep real time constraints well away from the PC in a reliable embedded device.