[M205] TOAST

Our idea for TOAST was derived through several layers of brainstorming. One theme that both of us were very enthusiastic about was creating a device that had a large mechanical hardware component and had to do with food. TOAST fit both of these categories and was both a challenging endeavor and a fun project. The device is also very pragmatic in the fact that it can combine some of our morning routines together autonomously. If TOAST is run when a user wakes 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 fun and creativity within the device including sending texts via toast, sending a loved one a picture, or another novel avenue for drawing and sketching.

TOAST takes input from a user on a host computer or phone to decide what to make. As mentioned above, there are three operational modes for TOAST: weather, image, or sketch mode. Setting the mode and processing an image/weather conditions is done via a python script hosted on a raspberry pi zero w, which then passes the information to print onto the pic32 through a makeshift serial/bit banging process. TOAST itself is an acrylic chassis with a two axis gantry system supporting a heat gun. In the two automatic modes (weather and image), the two stepper motors move the heat gun in a lawnmower pattern through a 10x10 array, either choosing to toast a point or not based on the information sent from the pi. In sketch mode, a four button switch is used to control the motors, either moving the toasting point up, down, left, or right. To toast a point, the user can let the heat gun simply remain still for a few seconds.

 

One of the main hardware limitations we had was the motor drivers we chose to operate our stepper motors. We chose to use the L298N motor drivers which were robust, affordable, and could handle the current of our larger stepper motors. However, each of these motor drivers took four GPIO pins to operate, limiting pins for other operations.

 

Another trade off we had to consider was using a Raspberry Pi or using a wifi module directly with the PIC. If we had more time to iron out the details, I believe a wifi module would have been feasible. However, the Raspberry Pi Zero W was a very cheap solution ($10) to overcome the obstacles of both the wifi connectivity and the image processing. The main challenges we had with this implementation was simply learning how to operate a Raspberry Pi and figuring out a data transmission pathway between the Pi and the PIC.

As seen below, 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, there are two layers of the chassis. The bottom layer houses one motor that moves a plate holding the bread in the y direction. The top layer houses another motor that moves a plate in the x direction with a hole in it such that the heat gun can be mounted on the device. The plates move via a laser cut rack and pinion design as seen below.

More detailed parts list can be found in the Appendices.

The majority of our pieces were designed to be made with a laser cutter. This was our prototyping method of choice due to our access to scrap acrylic in RPL and the speed of production which is much quicker compared to 3D printing. One of the first challenges we had to overcome was to find a method to join acrylic pieces together into a 3 dimensional assembly. Our first version, as seen below, was made with slots and secured with glue. However, we found that though this held well initially, it was not nearly as robust as we wanted.

Upon further experimentation, we designed our own screw joints as shown below. The design builds off of 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 including:

After designing the chassis, we then designed and printed the rack and pinion to convert the precise rotational movements of the stepper motors into lateral movement of the plates.

Our final laser cut DXF file is shown below with notes on what each part is. As seen, all of our parts fitted onto two 12” x 12” acrylic sheets. You can download them here if you want to edit or recreate TOAST.

One last addition we made to our design was creating a hardware bed. This bed combines our various electrical components and neatly secures them to a frame such that they are not loosened or damaged with movement. In the design, there are holes for mounting the two motor drivers, the PIC32 small board, and the Raspberry Pi Zero W. The bed was velcroed on to one of the sides of TOAST for easy removal for debugging and addition of new features.

Despite having most of the physical design laser cut, there were a few more complex 3D pieces that we resorted to 3D printing. The first was a simple motor holder, shown on the left, which secures the motor to the frame with M3 size screws. The second piece we designed was the heat gun mount which is screwed into the sliding top plate. The heat gun fits into the cylindrical cutout and is secured with some strong elastic bands.

 

A large part of our preparation for the project consisted of learning how both our stepper motors and motor drivers worked. Referring to the L298N data sheet and the Arduino library, we learned about how we could operate the stepper motors. Stepper motors have a magnetic core with “fingers” sticking out alternating polarity. Each of the electromagnets surrounding the core are then alternated on or off, drawing the finger to the next magnet, “stepping” it forward or backwards depending on the signal. Stepper motors are very precise compared to other motors but require quite a bit of current to operate well.

The motor drivers have four data inputs, three power pins, and four data outputs. Since we were choosing to operate at 6V, we did not need to supply an additional 5V line to the motor driver (there is a built in voltage regulator built for up to 12V). The ground line was common grounded with the PIC and the Pi. Reading further on the Arduino stepper.h library, we found the sequence for the four inputs to be:

 

Running this sequence with a short delay 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. Testing this and understanding how the steppers worked really helped us throughout the project with troubleshooting and debugging as we knew what to expect as outputs on our motor drivers.

Finding a power supply that fit our needs was a very unexpected hardware problem that we ran into early on. We found that on operation, our stepper motors drew more than 1 A each running at 6V. Running both together therefore would draw more than 2 A - more than even our power supply at the bench could supply. Luckily, we were able to find a power supply in Professor Land’s spare parts cabinet that was rated for 2.5 A at 6V. We were able to slice off the connection and attach our own headers to connect the power supply to our system. To ensure that we did not run into power problems, we made sure to limit our device’s operation to just one motor at any given time.

Our software for the PIC was essentially split up into three parts: waiting for a command, manual mode, and automatic mode. Before entering any of the code, our main was run and initialized the GPIO pins as follows:

 

Output:

 

B0, B1, B2, B3 - Top motor

B7, B13, B9, B11 - bottom motor

 

Input:

 

A3 - start signal from pi

A2 - data signal from pi

A4, B5, B14, B15 - signals from controller

Before the motors are allowed to move, a start signal from the pi must be received by the PIC32. We first tried to connect the pi and PIC32 through UART serial. Following instructions both on the ECE 4760 website and on online forums, we were able to successfully connect each of the devices individually to our laptops’ serial monitors. Unfortunately after several hours of work, we were not able to connect the two devices together through serial. Rather than struggling through this, we decided that we could implement our own version of serial by bit banging the data through the GPIO pins. This was a feasible option for us because our data was only 100 bits.

 

We used one output from the Pi to signal the start of transmission and then another output from the Pi to indicate zeros or ones in the data array separated by a 5 ms delay. On the PIC side, this data was read every 5 ms and appended to the PIC’s memory. The biggest issue we had with this was calibrating the timing. Our first run had several pixels that looked shifted several 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 data array from the pi, the PIC 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 entirety of the 100 bits were 0 does the PIC then enter manual draw mode. In this mode, the motors are controlled very simply by the four buttons on the wired controllers. These buttons are tied low to ground over a 10 k Ohm resistor. To prevent the device from drawing too much current at the same time, we limited the movement to only one axis at a time, with priority in the y axis moving forward or backward over moving left or right. To exit draw mode, the device can be reset to wait for a new transmission across the pi communication lines.

After receiving the data array from the pi, the PIC 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 entirety of the 100 bits were 0 does the PIC then enter manual draw mode. In this mode, the motors are controlled very simply by the four buttons on the wired controllers. These buttons are tied low to ground over a 10 k Ohm resistor. To prevent the device from drawing too much current at the same time, we limited the movement to only one axis at a time, with priority in the y axis moving forward or backward over moving left or right. To exit draw mode, the device can be reset to wait for a new transmission across the pi communication lines.

As mentioned before, the raspberry pi is used for wifi connectivity and image processing, such that TOAST can be controlled and operated remotely. Currently the process is slightly convoluted because we did not have time to implement an app as originally planned.

 

First, the user SSHs into the pi from a host device such as a phone or computer. Next, if the user wishes to upload an image for toasting, they can save the image and use pscp, PuTTY Secure Copy client, 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, 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 10x10 array of “1”s and “0”s to be sent to the pic.

The pi will downsample the image to a 10x10 image, and will then go through pixel by pixel to decide if the pixel is dark or light, setting 1s or 0s accordingly. An example of two images are shown below.

The pi uses a python weather api to collect data from Yahoo weather, namely the temperature and condition. We wrote predefined conditions 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. The layout and icons for conditions are shown below.

The array is set to all zeros, which the pic will then read and interpret as sketch mode, letting the user move freely.

 

The Pi then uses a custom digital interface between the pic and the pi to let the pic know we are ready send data, and then transmit bit by bit the 10x10 array.

 

 

Further detailed commented code can be found in the Appendices

As seen in the videos and images above, TOAST was able to operate very successfully in all three modes. The toasted images were very recognizable and the text was legible. We were quite proud of our mechanical design as the device looked great and felt very sturdy.

 

One of the first things we tested before building our chassis was the distance the heat gun needed to be from the toast. To test this, we held the heat gun at different heights from the toast and measured the time until just before burning, and the radius of the toasted area.

As seen in the figures above, there was a balance between how long it took to toast and the radius of the toasted area. We wanted “pixels” of toasted areas to be close enough to form a roughly cohesive image without overlapping. We found that 2 cm provided the best balance of pixel size and time to toast; with closer heat, the pixels tended to burn unreliably, and further away took far too long.

 

Another issue we had to consider was how long the device took to operate. As mentioned previously, the data transmission stream from a host device to the pi to the PIC takes a few seconds to fully send the data over. This was negligible for the user experience as far as we could tell. However, the time it takes TOAST to finish a piece varied with the number of pixels that needed to be toasted. For a less complex design, TOAST could finish in under a minute but for a denser or darker design, particularly common in image mode, TOAST could take a few minutes to finish. If all 100 pixels are to be darkened, then the design will take about 3 minutes and 30 seconds. Though this time was not too long for a user, it proved to be a difficulty for our very cheap heat gun to handle. In testing, as we toasted several pieces in succession, two heat guns overheated and stopped working. Resultantly, we resorted to utilizing a higher end heat gun found in the lab that was able to reliably sustain the hot air for much longer periods of time.

 

The product was fun and easy to use for anyone - all you need is a wifi connected device and a dream and you’re ready to TOAST.

 

Overall, we built a very impressive product given our constraints. We were able to successfully build a gantry chassis that worked well, connect it to the internet, and have it effectively toast images and words on toast.

 

However, there are many improvements that we could make if we were to work on this project more. We could have added auto calibration, attaching touch sensors at the “zero” position such that the device could automatically reset itself after draw mode. Additionally, we could have increased the resolution of our drawing screen or even implemented an analog drawing method using methods such as Bresenham's line algorithm. Another improvement that could be made is changing our data structure to take values of 0-255 rather than 0 or 1. We could then correspond this value in each location of the data array to toast for a shorter or longer duration to achieve different levels of “toasted-ness”. This would not only give us more flexibility to what we draw but offer smoother images compared to our current binary toasting methods. Lastly, we would want to create a more streamlined and easy to use app to interface better with the pi. Currently, SSH works well and is quick but unfortunately may prove difficult for a beginner to use. Making a better user interface will make TOAST more accessible to the general public and maximize the user experience as well.

 

We learned a lot working together on this project. From getting familiarized with the Raspberry Pi to operating stepper motors to mechanical synthesis, I think we had a project with great breadth and a plethora of problems to be solved.

Safety was heavily taken into consideration in the development of TOAST. The most dangerous component by far in our design is the heat gun. If left unattended, there is the possibility of the heat gun sitting still for too long on top of a piece of toast and starting a fire. We tested several cheap commercial heat guns that we bought online and luckily we found a failsafe system; when they get too hot, they shut off. However, after operating these cheaper heat guns on several pieces of toast in rapid succession, these heat guns broke. We then began using a higher end heat gun, which had dials for toggling the air and the temperature. This was much safer manual operation as we could control how fast the toast was toasting and shut off the device very easily. Regardless, TOAST currently cannot be left to operate unattended as the potential for burn TOAST could lead to burnt mouth roofs and burnt houses.

 

TOAST also aims to create edible toast so we need to consider FDA regulations. We chose to use a heat gun rather than a direct-contact heating element because this way, we would not have direct contact with the food. As long as the air quality in the environment we are working with remains safe (which should be the case in our area), the bread will be safe for the user to consume.

The group approves this report for inclusion on the course website.

The group approves the video for inclusion on the course youtube channel.

PIC32 Code