Hi UAVCAN community!
I really like your protocol, design and philosophy.
I intend to use UAVCAN for my latest machine controller and am seeking community input into the protocol design, potentially co-conspirators and ideally (I am assuming this work is applicable to others as well) standardisation within a SIG!
The high-level project goals are:
- Develop a machine controller focussed on pre-planned tightly-synchronised multi-axis motion
- Focus on high-power servo motors suited for CNC machines, but also applicable to high-performance 3D printers (and perhaps the next generation of super-light direct-drive extruders)
- Create a control and driver board providing a similar level of “plug-n-play” functionality as a smoothieboard or duet do for 3D printers
- Make the system expandable and future-proof, while maintaining a low barrier to entry for other developers to launch into
In more tangible terms and for illustration’s sake, I intend to slap 6 (5 axes + spindle) servo controllers and a raspberry pi onto a board, glue it all together with CAN and use it as a CNC machine controller and keep the cost below what you’d normally pay for two “low-cost” servo drivers, without all the added fuss, looming and know-how required to string a normal control cabinet together.
Intended control scheme
A big key to this project is to remove the central real-time controller. I was partially inspired into this thought by the Klipper project around the start of 2019. I have not yet decided whether I will recycle some of it’s main components.
- Path planning using a more powerful machine and high-level language (python) and not in real-time, which means it can be done under linux
- These paths (represented as polynomials) will be transmitted to the CAN network using UAVCAN
- Each axes controller collects it’s instructions from the bus and follows them closely as possible with it’s motor.
- Time will be synchronised across devices using UAVCAN’s existing scheme
- Devices are assigned a node ID based on their position on the board; for example by using a divider on an analog pin which acts as startup configuration. This means the same software can be deployed to all axes
- Other functions (GPIO, temperature etc…) is all transmitted to the same CAN bus.
- Configuration describes what each function (“stop”) should be bound to (“limit switch x+”).
- There’s no limit to how many functions can be bound to a piece of data; a probe input should be bound to “stop” on all motion axes.
- There’s only a practical limit (e.g. array size) to how many data bindings can be made for a given function; “limit switch x+”, “probe” and “control panel stop” can all be bound to each servo’s “stop” function
- These bindings are interpereted by a pre-processor, using intelligble names for the data bindings and functions, but boiled down to discrete bounded configuration along the lines of “axis 1, stop when: limit switch x is high, probe is high or stop input is high. axis 1, reset position to 0 when: limit switch x+ is high” ect…
- The above node assignment means that devices can listen for the configuration relevant to them
So far, my approximate message types list I intend to create and perhaps standardise (pending community enthusiasm) is:
- Path: x, v, a, j + end time
- Input state: input ID + state
- Function bindings: node ID (and perhaps “all”/wildcard), function ID (ideally standard enumeration), data bindings (array, input IDs + state)
I’m looking forward to your feedback.
Thank you for such a beautiful design