Image Processing

For coding samples, please visit the following link to our Google Drive. If you don't have LabView on your computer, take a look at this alternative page with pictures of our code. A description of how it all works can be seen below.

We loved the idea of a portable printer right off the bat, but we were struggling to come up with ideas of how we could code it. We were pretty close to giving up and using a two-link arm to control it using inverse kinematics, but then we made an important realization. If we used a nested 'for' loop to sort through an array of pixels, it would do so in a precise order - all we had to do to get our printer to move to the proper pixel at the correct time was to move it across the paper the same way a nested 'for' loop sorts through an array - from top left to bottom right, going row by row. Once we realized we could do this, we decided the portable printer would be our final design.

The code essentially has three main VIs that make the whole project work, with several Sub VIs built into them for modularity. The first VI is the ‘Image Processing’ VI. This takes in a 1000 x 1000 pixel image (uploaded from a computer), crops it down to a 25 x 25 pixel image (using the ‘Pixellator’ Sub VI to find the average color value of 40 x 40 pixel squares and convert all pixels to that average color), and then converts all the pixels to one of four colors that we found to be the most present in an average human portrait (these colors can easily be changed on the block diagram of the ‘Second Difference in Color Value’ Sub VI). To do this, we used code similar to the solution for the first midterm problem, which takes in four color boxes, extracts their RGB values (in the ‘Second Difference in Color Value’ Sub VI), adds them up, and finds the minimum difference between the color of the pixel in question and those color boxes (in the ‘Difference in Color Value’ Sub VI). Once the Image Processing VI has been run, the user now has a 25 x 25 pixel image of four different colors that can be used to run the printer.

The second VI is the ‘Rotator Reset’ VI. This VI is run just to reset the printer to its starting position, so that it doesn’t jerk or spin at the beginning of its motion and throw itself off course. This VI simply sends duty cycles to the rotator motor to set it at the starting angle, and sends cycles to the three pen motors to set them at their raised position.

The final VI, and the one that actually runs the robot, is the ‘Printer Mover’ VI. This VI takes in the 25 x 25 array of color-converted pixel indexes from the Image Processor VI and results in the printer moving through the entire image and drawing the correct colored points. The logic the VI follows is detailed below:

1. Receives array of pixel indexes from the ‘Image Processor’ VI. Each point in the array is a specific ‘color index’, a value between 0 and 3 for one of the four colors specified in the color boxes mentioned above.
2. Extracts the size of the array receives so the nested for loop knows how many rows and columns are in the image.
3. For each pixel, a case structure receives the color index signifying which of the four colors should be drawn. Assigns the appropriate duty cycles to the rotator and pen motors so the correct pen will be used to draw the point.
4. Sends the same color index to a second case structure. If the pixel is one of three main colors, the duty cycles selected in step 3 will be sent to the ‘Point Drawer’ Sub VI. This Sub VI first turns the motors on the top and bottom wheels on to move the printer over one unit (the next pixel in the image), stops them to stop the printer, then sends the aforementioned duty cycles to the rotator and pen so the printer rotates to the correct pen and then drops it and raises it, drawing a point. If the desired color is white, the case structure calls the ‘White Point’ Sub VI instead of the ‘Point Drawer’ Sub VI, and only moves the printer over one unit without drawing anything. This essentially ‘draws’ a white point.
5. The first case structure also contains a ‘Rotator Cycles’ Sub VI that takes the difference between the previous rotator duty cycle and the desired one, divides it into 20 intervals, and adds it it increments to the previous duty cycle value. This creates 20 different intermediate positions between the previous cycle and the desired one, which are then stored in an array to be sent to the 'Point Drawer' Sub VI so that the rotator spins much slower and doesn't cause the printer to jolt and move off course.
6. After the point is drawn, the index of the inner for loop is compared the (N-1) value of the loop (comparing the current cycle number to the number of total cycles to be ran), and if the two numbers are the same, this signifies the row is complete. The ‘End of Row’ Sub VI will thus be called, which turns the right and left wheels on and off to move the printer down one row, then turns the top and bottom wheels on for a previously calculated amount of time to move the printer back to the first column. The printer is now at the beginning of the next row, and the whole cycle repeats until the printer has gone through all 25 rows, at which point the picture is complete, and the printer stops.

And there you have it! That’s the outline of how we got our robot to ‘paint’ an image of a face! What we love about our code is that it’s extremely modular, and thus was easy to test and calibrate for our hardware implementation. Another great aspect is that it’s repeatable, and can draw any image you send it! (if the image isn’t 1000 x 1000 pixels, all you have to do is edit a few numbers in the Image Processing VI to turn it into the desired size image). In fact, given more time and resources with which to improve the hardware, we believe the code for our Rover Writer will allow us to reproduce any image back on paper with pristine accuracy!