CAN bus for the farmbot

Very cool prototype @jan.janson! We have been slowly contemplating a very similar electrical architecture overhaul for Genesis v2.0 (still probably several years out). Here is the gist of what we’re thinking:

  • Integrated driver/motor/encoder units. So, moving the stepper driver from the Farmduino to the motor/encoder unit itself. On the back of the motor we would have a PCB with the driver, a magnetic encoder sensor rather than the current optical one (saves a lot of cost and is more than adequate for FarmBot’s needs), a 2-pin micro DIP switch for selecting the axis, a MOSFET for a daisy-chained ‘dumb’ peripheral, pin headers for endstops, and an STM32 microcontroller.
  • This microcontroller would run an amalgamation of the current rotary encoder firmware running on the Farmduino’s STM32, as well as some of the driver/pin control logic from the current farmbot-arduino-firmware.
  • The driver/motor/encoder units would be connected and networked to the main electronics box via a single 4-wire cable and communicate over CAN. So the cores would be GND, 24V, CAN Low, and CAN High. There are other potential protocols/physical layers to consider PoE+, Differential I2C, BLE, USB-C but CAN seems the most appropriate.
  • The main electronics box would be downsized and the new Farmduino would actually not be an Arduino at all. Instead it would essentially be a large breakout board for a Raspberry Pi Compute Module.
  • FarmBot OS would then replace the farmbot-arduino-firmware and G-CODE middleman and orchestrate control of all the motors and peripherals via the CAN network.

The advantages of this architecture would be to:

  • As you mentioned, eliminate a lot of cabling, which would allow for much smaller and lighter weight cable carriers which reduces cost and improves performance (less mass to move around).
  • Move away from the slow and memory constrained Atmega 2560 and towards the orders of magnitude more capable STM32 and Pi hardware. This would also allow for movements to be non-blocking, so we could do things like Rotary Tool load monitoring in a less hacky way.
  • Eliminate an entire codebase (farmbot-arduino-firmware) by moving a small amount of low-level stuff into the STM32 and the rest of the things into the Pi where it will be easier to develop and maintain using a higher level language than C. By eliminating the G-CODE layer we’ll eliminate a lot of complexity and shortcomings that have come from its use.
  • Distribute heat-generating electronics throughout the machine.
  • Save a lot of cost by eliminating the optical rotary encoders which account for 80% of the cost of the current motors.
  • Daisy chaining peripherals will allow for much cleaner and shorter cable runs: X1 → Solenoid, X2 → LED Strip, Y → Vacuum Pump, Z → UTM (maybe).

There are some other projects I have been following that are developing network controlled integrated closed loop stepper motors. Check them out:

Anyways, all of this is a long ways out. Its just an idea at this point, but I am happy to see others in the community thinking along similar lines. Definitely open to suggestions and personal experiences in this area from any other electrical/mechatronics engineers out there.

2 Likes