Category: Weekly Status Reports

This week our focus was on completing testing for as well as validating the performance of our fully integrated system. We first tested the user-side workflow of our website. We tested upload behavior, visual feedback, and error handling. We ran thirty full cycles from the Flask interface and achieved over 90% success without getting interrupted. We also evaluated UI clarity by surveying fifteen users, all of whom gave feedback that helped improve the text instructions and responsiveness. Invalid file handling was also tested so every unsupported or corrupted PDF correctly triggered an error message.

The parsing pipeline was tested with a set of PDFs containing diagrams, text, and various line thicknesses. Conversion from PDF to PNG showed more than 80% visual accuracy, which confirmed that rasterization produces reliable and readable shapes. From there, we validated our column-splitting logic using large drawing areas to make sure that aligned with our gantry’s physical drawing width. Now the slices matches the expected boundaries. PNG to SVG conversions achieved our 90% visual match goal. Finally, our SVG to Gcode translation was verified using twenty inputs. We worked on optimizing the Gcode file that was created by minimizing redundant motor movements as well as jumps from where the pen lifts and places.

Motor testing somewhat confirmed that the system operates within required tolerances. Both wheel and gantry movement were evaluated by moving them fixed distances and measuring the real world displacement. We made some adjustments to the belt tension and our gantry movement has errors below 1% which was our goal. We did testing on our wheels and we have not yet achieved the error goal of 1%, and are hoping that maybe a slower movement speed will help us achieve that goal before the demo. We worked on validating the maximum draw speed by gradually increasing the step rate while checking for skipped steps. We are measuring the tradeoff between the speed improvements and the precision.

During full integration, we identified and resolved a significant constraint related to G-code homing requirements. GRBL firmware assumes a fixed 0,0 origin and automatically performs a homing procedure unless limit switches are installed. Since our design intentionally removed limit regulators to reduce cost and complexity, the system initially attempted to home to a position that did not physically exist. This caused the gantry to try and go out of bounds. To address this, we decided to disable soft limits and homing behavior entirely and updated our software to track and make sure Gcode commands do not go out of bounds. In addition, we refined our G-code generation to reduce unnecessary pen lifts between strokes. By optimizing stroke grouping and adjusting marker-lift timing, we increased drawing speed and reduced the risk of jitter during frequent vertical transitions.

Finally, we performed full pipeline system testing, where PDFs were drawn using horizontal and autonomous wheel repositioning. We discovered that we are limited by the cart’s ability to roll smoothly and consistently due to its inexpensive design and wheel construction. This introduces small alignment errors when the system transitions between drawing columns. This ultimately places a constraint on our maximum drawing accuracy and repeatability. Our gantry movement for the individual slices are consistent and accurate. To improve the overall drawing, we will be spending the last bit of our time optimizing the pen holder to ensure smoother drawings.

With full-system testing almost complete, we are  finalizing our project and are moving into final demo preparation. The results from this week show that our gantry is close to meeting our original requirements.

Currently, we have two main risks to focus on. The first is on the drive, the belt is currently prone to slipping which may introduce inaccurate positioning. We are currently planning on mitigating that risk by either tightening the belt, or using a larger pulley on the axle to reduce the required torque, which should reduce the slippage. The second main risk is in the software pipeline, turning images to svg format is challenging and can come out either overly complicated or inaccurate. If we cannot find a good balance of both with our current pipeline, we plan on adding additional steps to help optimize the pathing, or slightly reducing the scope so we can focus more on certain use cases.

We made one major change to the design this week, and that was adding a step of converting the PDF to a PNG before converting it to an SVG, as it allowed us to support more parts of a PDF. Since PDF’s are collections of objects on the page, turning it into a PNG reduced those vary objects to just one kind, pixels. The team as a whole is currently on schedule, and we remain optimistic that we will remain so.