Open jasonwebb opened 7 years ago
So far what I've learned is that:
Marlin was derived from Grbl and Sprinter, and more strongly resembles Grbl in its architecture and coding style. It basically adds lots of nice 3D-printer-specific features on top of Grbl, like auto bed leveling, managing up to 5 extruders, controlling an LCD screen, a couple more kinematics models, etc. The stuff that is most relevant to this project is pretty much boilerplate Grbl, so it'd be smart to start there.
Repetier is also derived from Grbl and Sprinter, but more strongly resembles Sprinter. In a way it feels somewhat like a spiritual successor to Sprinter with a small amount of Grbl peppered in. It is popular and proven, but not as abstracted or extensible for general purpose applications the way Grbl is.
And for reference, Sprinter was a firmware platform for 3D printers from the early days of DIY printering that took no cues from Grbl - perhaps it wasn't created at that point, or just wasn't popular yet. Regardless, Sprinter mainly served as inspiration for future 3D printing platforms and isn't all that relevant to this particular project.
While the robot arm doesn't look like a traditional 3D printer or CNC machine, its actually very similar. It will need a G-code parser, a serial communications layer, motion planning and interpolation between arbitrary mathematical points, and other such functionality that has already been built (and built well) by others.
Therefore rather than reinventing the wheel and building an entire firmware stack from scratch I feel it would be more effective to extend an existing platform to use a custom kinematics model for converting arbitrary X,Y,Z Cartesian coordinates into appropriate motor signals.
Existing platforms that jump to mind include:
My initial intuition is that grbl-Mega is the way to go, as it is the least opinionated and the most generalized, allowing for easier context switching between various applications like 3D printing, CNC milling, hot wire foam cutting and more.
Marlin and Repetier are both phenomenal projects, but are quite strictly focused on 3D printing applications. I feel like this could mean that certain types of extensions (like added more axes) may not have been planned for. They would also include a good amount of functionality that is not always needed, like running extruders, temperature control, and various G-code implementations that aren't relevant for robot arms.