With a Side of Raspberry Pi
The emergence of culinary robotics and automation has already begun to revolutionize the way we prepare our meals. In this article, learn how these two Cornell undergraduates designed an advanced toaster that’s able to toast any pattern—image, text or even today’s weather—onto a piece of bread. The project makes use of Microchip’s PIC32 MCU and a Raspberry Pi Zero W board.
ToastBot is an automated toaster equipped with a heat gun and a PIC32 microcontroller (MCU). It is able to toast any image, text or even the weather onto a slice of bread (Figure 1). The device uses two servos to control an acrylic, two-axis gantry with a 3D-printed heat gun mount. A Raspberry Pi board is used to gather image or weather data from the Internet to be sent over to the PIC32 MCU to control the motors in real time. ToastBot has three modes of operation: Image, Sketch and Weather. In Image mode, a user can upload an image from the Internet through SSH into the Pi with a phone or computer, which is then processed into a print sequence. In Sketch mode, a four-button controller is used to manually control ToastBot to create a work of edible art. In Weather mode, the device automatically collects the temperature and conditions via Yahoo!’s weather API and prints the weather onto the toast.
Setting the mode and processing an image or displaying weather conditions is done via a Python script hosted on a Raspberry Pi Zero W board , which then passes the information to print onto the PIC32 through a makeshift serial bit-banging process. In the two automatic modes (Weather and Image), the two stepper motors move the heat gun in a lawnmower pattern through a 10×10 array, either choosing to toast a pixel or not, based on the information sent from the Pi. In Sketch mode, a four-button switch controls the motors, either moving the toasting point up, down, left or right. To darken a pixel, the user can let the heat gun remain still for a few seconds. The high-level design is shown in Figure 2.
Our idea for ToastBot was conceived through several layers of brainstorming. The project was created for Cornell’s ECE 4760 Microcontrollers class, focused around using a PIC32 to implement real-time control of various systems. Two themes that we were enthusiastic about implementing were creating a device with a significant mechanical component and that incorporated food. ToastBot fit these criteria, and was both a challenging endeavor and a fun project. The device is also pragmatic, in that it can combine some of our morning routines autonomously. If a user runs ToastBot upon waking up, it can provide a warm breakfast and an overview for how the user should dress or prepare for the day ahead. Additionally, there is a lot of potential for further fun and creativity within the device itself, including sending texts via toast, sending a loved one a picture, or another novel avenue for drawing and sketching.
As shown in Figure 3, before we began laser cutting or 3D printing, we used Autodesk Fusion 360 to make a detailed 3D model of our design. As an overview, the chassis has two layers. The bottom layer houses one stepper motor that moves a plate holding the bread along the Y-axis. The top layer houses another stepper motor that moves a plate along the X-axis with a hole in it, such that the heat gun can be mounted through the plate to access the bottom layer. To translate the stepper motor’s rotational motion into linear motion, we designed our own laser-cut rack-and-pinion tracks, shown in Figure 3.
The majority of our pieces were designed to be manufactured using a laser cutter due to its faster rate of prototyping compared to production using 3D printing. As shown in Figure 3, the two side pieces support the two layers with built-in slots. Each layer has a sliding piece—one holding toast and the other holding a heat gun—along with some railings to restrict the movement to just one axis each. These layers must be strong enough to support the weight of the stepper motors and endure the minor vibrations from the motor’s operation. Our final design measured about 10″ × 6″ × 4″.
One of the first challenges we had to overcome was finding a method to join 2D acrylic pieces together into a 3D assembly. Our first version was made with slots and secured with glue. However, we found that, although this held well initially, it was not nearly as robust as we wanted.
Upon further experimentation, we designed our own screw joint, which built off a slot-and-tab design by adding an additional hole on the slot side and a nut holder on the tab side. This essentially built in threads onto our 2.5 D model, offering several advantages. Among these are ease of assembly, no cure times, very strong joints and modularity of individual components for redesigns or replacements. Our final laser-cut design can be fitted onto two 12″ × 12″ acrylic sheets as shown in Figure 4.
Despite having most of the physical design laser cut, there were a few more complex 3D pieces that we chose to 3D print. The first was a simple motor holder, shown to the left in Figure 5, which secures the motor to the frame with M3-size screws. The second was the heat gun mount, which is screwed into the sliding top plate, as shown on the right of Figure 5. The heat gun fits into the cylindrical cutout and is secured with some strong elastic bands. This mount keeps the heat gun securely fastened at a proper angle and distance from the toast as the device moves it.
Our electrical hardware was centered around the PIC32 MCU. Eight of the MCU’s GPIO pins were dedicated to operating the two motor drivers, four more were used for the button controller and two more were used for communication with the Raspberry Pi. The detailed schematic is shown in Figure 6 .
A large part of our preparation for the project consisted of learning how both our stepper motors and motor drivers worked. Stepper motors have a magnetic core with “fingers” sticking out with alternating polarity. Each of the electromagnets surrounding the core are toggled on and off, drawing the finger to the next magnet, “stepping” it forward or backward, depending on the signal. Stepper motors are precise compared to other motors, but require quite a bit of current to operate well.
We used two STMicroelectronics (ST) L298N motor drivers , which have four data inputs, three power pins and four data outputs. We powered the drivers off a 6 V line. There is a built-in voltage regulator on the motor driver board for up to 12 V input. The drivers were common-grounded with the PIC32 and the Pi. After carefully examining the Arduino stepper.h library, we found the sequence for the four inputs to move the motor forward, and mimicked the behavior on the PIC32.
Running this sequence with a short delay of 5 ms turns the stepper motor forward a step. To run in reverse, we could simply run this in reverse starting with step 4 .. 3 .. 2 .. 1 in the code. Because the load was not heavy, we were able to run the motors with no built-in acceleration time. Testing this and understanding how the steppers worked helped us throughout the project with troubleshooting and debugging, since we knew what to expect as outputs on our motor drivers. We found that on operation our stepper motors drew more than 1 A while running at 6 V. Luckily, we were able to find a surplus power supply that was rated for 2.5 A at 6 V. To make our power system even more robust, we chose in our movement algorithm to have only one motor move at a time. This helped to minimize any issues with power consumption.
One last addition we made to our design was creating the hardware bed shown in Figure 7. This bed combines our various electrical components and neatly secures them to a frame, so that they are not loosened or damaged with movement. In the design, there are holes for mounting the two motor drivers, the PIC32 and its breakout board and the Raspberry Pi Zero W. The bed was attached with Velcro onto one of the sides of the ToastBot, for easy removal for debugging and for adding features in the future.
PIC32 SOFTWARE DESIGN
ToastBot’s software runs on both a PIC32 MCU and a Raspberry Pi Zero W, communicating through a custom bit-banging protocol. The Raspberry Pi is used to retrieve data wirelessly on the user’s wireless commands and the current weather conditions, to process images, and then to relay these data to the PIC32. The PIC32 is then responsible for appropriately processing the data and moving the heat gun accordingly.
Our software for the PIC was divided into three parts: waiting for a command, manual mode and automatic mode. Before entering any of the motor-controlling code, our main function was run and the GPIO pins were initialized for the motor drivers and the Raspberry Pi data ports.
Before the motors are allowed to move, a start signal from the Pi must be received by the PIC32. To get the Pi and PIC32 communicating, we decided to implement our own version of serial communication by bit-banging the data through the GPIO pins. This was a feasible option for us because our data was only 100 bits, and the clocks on both devices were accurate enough to stay synchronized for such a short transmission.
We used one output from the Pi to signal the start of transmission and another output from the Pi to indicate “0”s or “1”s in the data array, separated by a 5 ms delay. On the PIC32 side, these data were read every 5 ms and stored in the PIC32’s memory. The biggest issue we had with this was calibrating the timing. In our first run, several pixels looked shifted one or two rows over. After measuring the signal from the Pi with an oscilloscope, we found that the delay from the Pi was actually slightly more than 5 ms. To minimize this discrepancy, we extended this delay to 20 ms and added an additional 15 ms every 20 reads, to keep both sides of the transmission calibrated. After further testing, we found that this effectively solved our calibration issues, despite being a relatively messy solution. With this in mind, the full data transmission takes approximately 2 seconds to occur (100 bits × 20 ms), which is a reasonable amount of time for operation.
After receiving the start signal and data array from the Pi, the PIC32 decides to operate either in manual mode or automatic mode. It does this by counting the number of zeros sent in the array. If—and only if—the entire 100 bits were 0, the PIC32 enters manual Draw mode. In this mode, the motors are controlled very simply by the four buttons on the wired controller. These buttons are tied low to ground over a 10 kΩ resistor. The device can move in only one direction at a time, X or Y, due to our motor power constraints. To exit Draw mode, the device can be reset to wait for a new transmission across the Pi communication lines.
If the data array received from the Pi is not all zeros, then the device knows that either an image is being printed or that the weather is being printed, and therefore, operates in automatic mode. In this mode, the PIC32 moves the heat gun in a lawnmower pattern—shifting 10 steps to the left for each of the 10 pixels, returning 100 steps to the right (giving full range of motion along the x-axis) and shifting down 10 steps. This cycle repeats 10 times to give the full range on the Y-axis as well. After completing a thorough run-through of the entire drawing surface, the motors return the device to its original zero position. While it is performing this lawnmower pattern, the PIC32 also reads the data array, checking the index of the array to see if there is a 1 or a 0. If there is a 1, the PIC32 delays for 2 seconds on its current position, which is long enough for the heat gun to toast that particular spot. If there is a 0 in the index of the data array, the PIC32 does not wait, not giving the necessary time for a darker toast. This pattern toasts the entire surface slightly, and the desired pattern is toasted more intensely. After finishing this cycle, the device is ready for its next command.
RASPBERRY Pi SOFTWARE
The Raspberry Pi is used for Wi-Fi connectivity and image processing, enabling ToastBot to be controlled and operated remotely. First, the user accesses the Pi via SSH from a host device, such as a phone or computer. Next, if the user wishes to upload an image for toasting, the image can be saved, and PSCP or PuTTY Secure Copy client can be used to send the image over to the Pi. If intending to use the device in Weather or Sketch mode, this step can be skipped.
Next, the user simply has to run the Python script over SSH, along with a keyword indicating the mode. There are three keywords associated with the modes: weather, image and sketch.
The command would look something like this:
python output.py weather
After this command has been sent, the Pi runs a processing script according to the parameter sent, updating a 10×10 array of 1s and 0s to be sent to the PIC32. If Image mode is selected, the Pi will downsample the image to a 10×10 image. Taking this down-sampled image, the Pi compares each pixel to a threshold value to decide if it is dark or light, appending a 1 or a 0 to the data array accordingly. Some examples of down-sampled graphics are shown in Figure 8.
If weather is sent as the parameter, the Pi uses a Python weather API to collect data from Yahoo! Weather, particularly noting the temperature and condition. We wrote custom bitmaps for the values of the temperature to be written on the top half of the toast, and predefined graphics to represent the conditions windy, raining, snowing and sunny. Unfortunately, the sunny condition was never used, because testing occurred during an upstate New York winter. The layout and icons for conditions are shown in Figure 8.
Finally, if Sketch mode is selected, the output data array is set to all zeroes. When this is sent to the PIC32, it is interpreted as Sketch mode, letting the user move the heat gun freely using the controller.
We were pleased with the results of our project. ToastBot was successfully operated remotely using Wi-Fi, was equipped with several modes of operation and user interaction, and produced novel and edible pieces of toast. Figure 9 shows the fully assembled ToastBot, ready to decorate some bread. You can see in Figure 10 the end products from using ToastBot operated successfully in all three modes, and the resulting images were recognizable and easy to read. We were quite proud of our mechanical design—the device looked great and felt robust.
Despite these successes, there were a few issues we would like to address in a future iteration. The main problem in the user experience was how long the device took to operate. The full data transmission stream from a host device to the Pi to the PIC32 takes only a few seconds, which was negligible for the user experience as far as we could tell. However, the time it takes ToastBot to finish a piece varies with the number of pixels that need to be toasted. For a less complex design, ToastBot could finish in under a minute, but for a denser or darker design, particularly common in Image mode, ToastBot could take up to 3 minutes to finish.
Additionally, we would like to make the user interface much more professional by making an app to connect to the Raspberry Pi, rather than using SSH. This would broaden our audience and make the device much easier and intuitive to use. Finally, we aim to broaden our data structure on an analog scale, to dictate the level of “toasted-ness” for each pixel. Rather than burning for 2 seconds over the dark pixels, the device could vary the time spent on each pixel between 0 and 3 seconds, to produce an effect of shading and gradient, thus improving the clarity and resolution of our results.
For the code, go to the Circuit Cellar code download webpage. Below you can view our detailed results and two videos where we demonstrate the use of ToastBot and show its results. The product was fun and easy to use. All you need is a Wi-Fi connected device and a dream, and you’re ready to toast.
 A small, portable computer. Specifically the Raspberry Pi Zero W, a wireless enabled computer with the smallest form factor for Pis yet, was used in this project https://www.raspberrypi.org/
PUBLISHED IN CIRCUIT CELLAR MAGAZINE • AUGUST 2019 #349 – Get a PDF of the issue