Here's our System-Level diagram (still a work in progress):
Admittedly the system diagram is very busy, but it does accurately reflect our desired system configuration. I will try to explain the various parts of the diagram and how they work together.
Software Topology and Theory of Operation
OpenPnP is the high-level brains of the machine, that does the seemingly-simple stuff like "pick up that part" and "put it over there". Lots of libraries and sub-systems feed information to it, and it passes information to the various motors and actuators via other libraries and software modules. It was created by Jason von Nieda, long before FirePick Delta was started. It's technically still in alpha-state, but the underlying software is solid and has been used on several production machines. Although it was well-written and extremely modular and extensible, the documentation wasn't great... Until now. In the spirit of open-source and full-disclosure, we've decided to document OpenPnP ourselves. Hopefully we'll get all of this pushed upstream back the official project.
Here's a system-level diagram of OpenPnP, before we forked it:
The Java files shown above ('JAR' icons) can be replaced or used as a base class for coming up with your own machine configuration. Each of the Java files above (with the exception of the configuration model(s)) can be specified in the 'machine.xml' file. If you're not familiar with Java, this might seem strange, but it's really neat. It means you can specify the path to a bunch of .java files, and that will determine which classes get instantiated and used, thereby changing the behavior. It keeps the code really clean and modular, which is important for something as complicated as a pick and place machine. OpenPnP comes with a set of reference files for a vanilla PnP implementation with TinyG motion control, a single head, single nozzle and actuator, drag tape feed, and a downward-looking camera. We've modified quite a lot of stuff in order to make it do all the crazy things that we needed.
Motion driver: We're using a custom motion controller board that was inspired from RepRap RAMPS 1.4 and Melzi boards, which runs modified Marlin firmware. I wrote an OpenPnP Marlin driver that sends the correct g-code to the motion controller. This works great at the moment, but we're finding that doing the delta calculations and multi-point Z-probe correction on an 8-bit arduino with limited memory and no floating point seems a bit dumb when we have all that computing power on the Pi. Furthermore, we want to use the camera and a custom XY calibration app to improve accuracy, and it's much easier and faster to do these calculations on the Pi. However, this code isn't a part of OpenPnP, since we plan on offering other apps down the road. This means that OpenPnP can't talk directly to the motion controller, it's got to go through a layer of software that does the delta calculations and XYZ correction offsets. We wrapped all that code up in FireFUSE (our file system in userspace mapper), which allows us to do a lot of neat things that we'll get into later. This is pretty transparent for the most part; rather than OpenPnP writing to '/dev/ttys0', you write to '/dev/firefuse/sync/cnc/marlin/gcode.fire'. FireFUSE will turn the Cartesian coordinates into delta coordinates, calculate the error offset using interpolated points from the machine auto-calibration process, and send this new g-code out to the Marlin driver. And, that code will be portable and can be used with 3D printing apps, solder paste dispense apps, etc. The only thing needed to get OpenPnP talking to FireFUSE is a FireFUSE driver, which is currently in being written.
Camera driver and Vision Framework: OpenPnP's camera support was a bit finicky and didn't support the wonderful 5-megapixel Raspberry Pi camera. Their computer vision was a thin shim on top of OpenCV code, that had implemented some really basic hole-finding, but not much else. Karl Lew, our software guy, saw this as a huge problem, and has spent the last year or two writing an amazing open-source vision library called FireSight. He wrote dozens of awesome vision routines that can be ganged together into a pipeline, in a very high-level manner that doesn't require higher-level math or lower-level C/C++ knowledge. For the camera, we're using the RasPi camera module as mentioned, with a custom version of the 'raspistill' called FirePiCam. We take snapshot images and save them to the FUSE filesystem which keeps us from wearing out the bits on the SD card's FLASH memory. In order to get OpenPnP to see the images and perform computer vision operations, Karl wrote a java library called 'firerest-client' that makes it all work.
Hardware Topology and Theory of Operation
We use a standard Raspberry Pi Model B+. The B+ is the RPi we always wanted; they moved the connectors to a more logical place, and added a real set of mounting holes. Still has the crappy slow Broadcom 2835 but for $30 what do you expect. We often get the question, "Why did you use a BeagleBone Black?" or a dozen other single-board computers. The answer is pretty straightforward. We're shooting for a $300 machine, and that means we need to pick a CHEAP single-board computer. Raspberry Pi is the cheapest, therefore it wins. QED. :) Actually, we do like the BeagleBone black quite a lot, and other platforms such as the Allwinner A4, Intel Galileo, and even more traditional setups like Mini ITX. All of our software and hardware should work on those platforms. But they're expensive, and Raspberry Pi gets the job done.
We've actually been surprised at the performance with the Pi so far. It's not lighting fast, but it does computer vision and serves up web pages with no issues.
ERPIHAT01 HAT Board
Shortly after the release of the Raspberry Pi Model B+, the RPi Foundation released a "HAT" specification, which is very similar to an Arduino Shield, or a BeagleBone cape. It's a custom-shaped mezzanine board that can be customized to add neat things to a Raspberry Pi without all sorts of cables and other nonsense. There were plugin modules before the HATs, but they weren't standardized. We're happy with the new HAT spec, and are proudly presenting our FirePick Delta HAT below:
Here's a list of things that our FirePick Delta HAT does:
- Provides a 16x2 character LCD connector, which is wired to the Raspberry Pi GPIO connector
- Provides connectors for a rotary encoder and pushbutton switch (with LED), which are wired to the Raspberry Pi GPIO connector
- Provides a 12V -> 5V step-down switching power supply to the Raspberry Pi.
- Provides a pass-through connector for the RasPi camera module, so that we can extend the camera to the delta mechanism's end effector.
- Provides a piezo buzzer, driven from the RasPi's only PWM pin on the GPIO connector. This was cheaper than using the Pi's audio jack.
- Per the official HAT spec, this board provides the necessary EEPROM chip and backfeed protection on the +5VDC input. Because we're feeding power in via the GPIO connector, we don't need to provide power via the micro-USB connector.
Github link to PCB and SCH files:
EHDMIFFC01 Raspberry Pi Camera Extender
When you purchase the Raspberry Pi camera module, they give you a cute little flat-flex cable, that's completely inadequate for mounting somewhere far away from the computer:
We needed to extend the camera cable, somehow. Adafruit sells a longer ribbon cable (610 mm) that would do the job, but it's kind of hard to mount something thin and flat onto a moving robot like ours. Plus, flat-flex cables aren't that durable. I decided early-on to just make a set of adapter boards that pass the 15 conductors through a durable cable. And I'm not fond of making/fabricating high-density, high-speed cables myself, I decided to look around for an off-the-shelf cable that could work.
The schematic for the RasPi camera connector looked like this:
OK, so there's I2C, 3.3V, ground, a clock and GPIO signal, and 3 differential pairs (or "lanes" as they call them in the biz) used for data transfer. They're using differential signaling because of the insane amount of data transferred from the camera. Therefore, to avoid timing issues, we need to ideally pick a cable type that has twisted-shielded pairs. I've seen something very close to that before. Seems very familiar..
That's right.. HDMI. Although the Raspberry Pi camera doesn't output HDMI, we can still use the cable as a physical interface, because the pins are very similar. You can see all the same stuff in both pinouts: differential pairs. I2C, power, ground, a few other pins... It's all there. So we just need to make a set of flat-flex cable to HDMI pass-through boards and see if it works.
I've been using the extender now for several months and I've had zero issues with it. We recently had them remade with matched-length pairs, logos, and a slightly different pin layout through the HDMI. Here's the new version, in all of its curvy, twisty goodness:
EMC01 Motion Controller
Thanks to the RepRap movement, there are tons of existing motion controllers out there: RAMPS 1.4, Melzi, Azteeg, and RAMBO to name a few. Yet none of them seemed to fit the requirements for FirePick Delta. We wanted something that was:
- Cheap, no frills
- ATMega based, so we can use the Arduino bootloader and Marlin firmware
- Use readily-available parts
- Near 100% usage of SMT parts (we want to be able to use our machines to make more EMC01 boards)
- If we're making a custom board, we might as well put the connectors somewhere logical for our Delta-based machine.
- We want a machine capable of switching tools out. So we came up with a modular tool changing system (documented below).
We made the board in a hexagonal shape to make the wire runs a bit more manageable (remember that the delta mechanism has three motors in a perfect triangle). This keeps all of the stepper and endstop wires an equally-sized small manageable length. Power input is +12VDC to the back of the board. There's a mini-USB port in the front that connects to the Raspberry Pi. There are three StepStick drivers that contain the stepper motor drivers (these might be integrated into the main board after the first run of prototyping.. but the modules made more sense in case we inadvertently burn one up). A unique feature of this board is that it doesn't have any other stepper drivers or circuitry for tools such as hotends and SMT nozzles. Instead, there's four connectors to modular tools (the drivers and other circuitry are on a separate board that plugs into the EMC01). This is explained a bit more below in the auto-tool changer section.
Here's the schematic, grabbed from the eagle files in github:
EOPTO01 Opto Endstop
Endstops are used during the homing process to make sure that the axes are in a known position. There are several types of endstops, but my favorite are the optical interrupter type. We based ours on the TCST2103. As you can see in the picture below, the delta mechanism arm has a little 3D printed plastic interrupter, that passes between the TCST2103's infrared LED and its phototransistor.
These sensors are used commonly on RepRaps, and are available from Chinese vendors such as Sainsmart. But the design isn't that great, I've had problems with the TCST2103 getting loaded down by the status LED, causing intermittent behavior. Christian Lerche, our schematic / PCB guru, added a simple transistor to fix this problem. Also, we relocated the connector to the other side in order to make it easier to connect and reconnect while installed on the machine.
Auto Tool Changer
Our system features a very unique auto-tool changer. It allows the machine to hold up to four (4) modular tools. The machine can use one tool at a time, and can switch between them via a tool-change operation.
The primary modular tools that the FirePick Delta will support is:
- SMT nozzle with luer-lock nozzle tip, hollow-shaft NEMA 8 stepper motor and 12V diaphragm vacuum pump
- 3D print hotend and extruder
- Auto Z-probe (switch used to find the Z distance to bed, used during calibration)
- SMT solder paste dispense (provisioned)
- Heated bed for 3D printing
- Auto cover tape winder for SMT component feeders
Each modular tool consists of three pieces:
- A tool with conical 3d-printed taper that mates with the delta-mechanism end effector. Three rare earth magnets are used to hold the end effector in position
- A pump or extruder, depending on the tool
- A circuit card that contains, if applicable to the tool, a stepper driver, a MOSFET or other digital output circuitry, analog input circuitry, a 5V regulator, and an EEPROM for part identification. This circuit card plugs into the EMC01 motion controller, in one of its four slots.
For example, an SMT tool would have an SMT vacuum nozzle tool, connected to a 12V vacuum diaphragm pump via vacuum tubing, both of which are connected to a circuit card that contains the stepper driver for the SMT part rotation, and a MOSFET to turn the 12V pump on and off. The 12V pump is attached to the frame in the top-back of the machine.
Here is a small section of the EMC01 schematic, showing the modular tool #1 female receptacle.
Since this machine has lots of different uses to different people, this keeps it extremely modular. Don't want a heated bed? No problem. Want four 3D print heads to do four-color parts? Or four SMT nozzles of different size? The idea is that you buy what you need and can change them out whenever. This makes it easy to try different types of 3D print hotends or whatnot.
DIR and STEP lines are shared between all four tools, but each has their own ENABLE line. This works because only one tool can be used at a time.
The DOUT can be used to drive a MOSFET, relay, or whatever. The cool part is that you only have to spec out an expensive MOSFET if you really need it. A heated bed might require a high-current MOSFET, whereas a vacuum solenoid might only need a small cheap one. This also opens the possibility of using TRIACs or other neat things for silicone heated beds, or other stuff.
The AIN pin can be used with a thermistor, vacuum sensor, thermocouple, or other things. Each tool is completely free to use whatever circuitry makes the most sense. For example, you could have four 3D printer hotends, each with different thermistor types, or maybe a mixture of thermocouples and thermistors. Since each module has an EEPROM, the tables can be loaded into nonvolatile memory on the module's pcb, rather than in Marlin firmware. This allows arbitrary tools be hooked up without having to re-flash the motion controller firmware.
This system seems a bit crazy and complicated at first, but since this machine is designed to do lots of small tasks, it makes a lot of sense to have this kind of modularity. It's a bit crazy compared to the status quo, but we're hoping that everyone eventually sees how easy it is to swap tools, they'll realize what kind of potential it really has for the desktop microfactory.
- FireREST (including some debug web apps for computer vision, calibration, etc)
- FireSIGHT (or high-level computer vision)
- OpenPnP fork
- Marlin fork
- The machine's frame, delta mechanism with interchangeable tool system
- The SMT vacuum nozzle and 3D printing hotend/extruder modular tools
- New PCB assemblies: EMC01, EHDMIFPC01, ERPIHAT01, EAT0001, EOPTO01
What we're still working on
- Finalizing mechanical documentation and build instructions
- Writing web apps interface for OpenPnP, 3D printing, and solder paste dispensing
- High-level system-integration
- Some minor mechanical problems with the machine's delta mechanism rod ends
- SMT component feeders need some minor tweaks
Open Source Licenses
Due to space limitations on this hackaday build log, we've created a Google Spreadsheet with all Open Source licenses called for this project.