Category: Team 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.

This week saw us begin to implement some of the last minute design changes to our project. Firstly, the team was able to place orders for the structural materials as well as the new rods for the increased gantry length. In the back half of the week we were able to modify our gantry which allowed us to strategize how we wanted to attach the new, longer gantry to the prefabricated cart. Our current idea is to have a large piece of sheet metal that runs along the inside edge of the cart of the same height as the gantry. This piece of sheet metal will secure bolts which are fastened to the gantry to mitigate movement and vibrations. The sheet metal which is above the top of the cart will be supported by metal beams to ensure it stays upright. We plan to get an expert opinion on this structure from Ed at Techspark who may help in fabricating our design.

Additionally, we have made progress on the software pipeline. During the interim demo we had issues with the svg to gcode conversion. We have root caused the issue and have determined that the pdf to svg conversion is not always consistent between different pdfs. For example, the svg for images and text differs and our gcode conversion only currently works for some svg for images. Debugging this has been a work in progress and we are debating pivoting to other file types or trying to modify the pdf such as compressing it before converting it to svg. As the final deadline approaches the group may have to pivot to only having functionality for certain hand-selected files.

Finally, one of the comments we received from the teaching staff revolved around the speed of which the gantry draws. Currently small images can take substantial periods (4+ minutes). We look to remedy this by converting many “arc” drawing types to more “line” drawing types to increase the speed. This will have to get implemented after the svg to gcode is functioning on a more consistent basis.

Verification methods for subsystems are below:

• Website PDF to SVG: Upload PDFs with a variety of text, images, or both and view SVG output to determine effectiveness
• SVG to Gcode: Take a variety of SVG files and determine the Gcode output is viable for our system/
• Motor control: Use working Gcode files to evaluate motor precision and speed.

Validation methods:

• Run tests with a variety of pdfs with images, text, or both to determine effectiveness of the system.

This week, our team made major progress on building the gantry. Because of the interim demo, the majority of our time was focused on building the initial gantry and integrating it with the software. The build was close to finished early in the week after extensive troubleshooting, laser cutting, and 3D-printing.

On the software side, we made progress on integrating the Flask website with the motion control system. The website can now handle PDF uploads and automatically convert them to SVG files. Although we initially planned to host the site and run the converter on the Raspberry Pi 5, we ran into some connection issues. As a temporary solution, we configured the system to operate locally for the interim demo.

We also worked on the motor control to make sure that the movement of the gantry matched the actual drawing. We are planning to finalize preparations for the interim demo and then begin designing and ordering parts for the final vertical gantry structure. We had a design change for the vertical gantry structure as we decided to extend our gantry vertically enough to cover close the the height of a standard whiteboard. This makes it so that we can focus more on the horizontal movement of the gantry on wheels, as well as perhaps implementing additional features. It will also free up some budget for the horizontal movement.

We will also decide on the final SVG conversion component, comparing results between the SpirePDF and the alternative converter. We have caught up to our initial schedule and we’re confident in the progress we made this week.

Mark_My_Words_updated

This week our team moved much closer to having our gantry fully functional. We had a few challenges with the laser cut parts not matching the 3D printed parts in size. To fix this, we have started printing new parts to replaced the laser cut pieces. Our next big challenge will be integrating our software pipeline into the gantry. We will build each software piece separately and bring them together to function automatically. We plan on starting integration well in advance of the interim demo, so we should have plenty of time to fix any issues that crop up. In the event the automatic pipeline fails, we should still be able to manually activate our scripts and have the gantry fully functional for the demo.

With the issues that cropped up in building the gantry, we’re slightly behind schedule. However, not spending time on construction gave us more time to work on our software, so we should be able to get back on track easily.

Our design has slightly changed. Before, we were planning on using a wagon as the base for our system. However, we discovered that our motors would not be able to move the heavy wagon base. Instead, we are leaning more towards using a personal grocery cart as the base because it’s much lighter and should still allow us to move as expected.

This week was all about overcoming challenges. We finalized the pre-fabricated cart that we will use for the base of our structure. That cart is not perfect due to our budget constraints and will need some modifications such as removing the upper cage and creating attachments for the vertical T-slot beams. Additionally, the original plan to 3D print many gantry parts was changed due to budget constraints. The team opted to go for laser cut parts instead which took longer than it should have to get cut due to many attempts on a faulty laser cutter.

In more positive news, all of the parts for the motors (power supply, steppers, etc) have arrived and code has started being written. We hope to have the motors functional for the gantry system when it is built, which hopefully this week. This would allow us to focus on the pathing and conversion scripts. Our plan for the interim demo is to showcase the fully working gantry system with some standalone horizontal and vertical movement and begin integration after.

Other than finalizing the cart, there are no large design changes this week. We are a little behind our schedule, but if the gantry is able to come online this upcoming week, we think we are still in a decent spot to have our goal for the interim demo achieved.

This week’s focus for us was to incorporate the feedback we received from the design presentation. We decided to refine our system design. The significant thing that we decided to change was adding the wheels back into our gantry design so our gantry can move horizontally. Before this week, we had taken out the wheels since we had a budget constraint. After some research, we potentially found a more affordable option by using a premade wagon base.

Progress was made on both software and hardware this week as well. On the software side, we continued to work on the file upload and parsing. We were able to continue testing the PDF conversion to G-code. On the hardware side, the part orders were finalized and  we began preparing for motor setup and control testing. Most of the ordered components have arrived. As a result, next week will focus heavily on system integration.

We plan to get the motors running. We will also begin integrating the software upload with the hardware control system to start full end-to-end testing. While we’re slightly behind schedule due to the design revisions, but hopefully the updated plan puts us in good position to catch up quickly.

Part A was written by Alex

Our project has the potential to create impact on a global scale. For one, it has potential for use in any academic institution around the world. The technology would be easily adaptable and can theoretically transcribe any PDF, meaning regardless of language or location, it would still work. It is also cheaper and more transportable than the systems it replaces, like classroom projectors. It also integrates well with whiteboards or chalkboards, which are common around the world. We also hope to make it easy to use, meaning anyone, even those with limited technical knowledge should be able to make use of it.

Part B was written by Ethan

The project at a glance does not seem to have any major cultural considerations, but even at a small scale any sort of automation can have a cultural impact as to some extent, someone’s job is being done by a machine. Our intentions with the project is not to automate someone’s job, but instead be a tool to help teachers, presenters, and companies focus on the important parts involving putting text or diagrams on a whiteboard, getting the their point across and having the content being easily editable.

From a larger perspective this project strengthens the wider movement of automation in many aspects of industry. The subject of automation is still quite divisive to many, and our project further encourages using machines and to an extent, robots, in front of a very impressionable group, children.

Part C was written by Andrew

From an environmental standpoint, our gantry will be drawing directly on whiteboards and other reusable surfaces, in classrooms and meeting spaces, so that means there’s no need to use paper copies of diagrams, which helps reduce paper waste over time. The hardware also runs on low power with the Raspberry Pi and Arduino using potentially less energy than a projector would. We also will be 3D printing some of our own parts in Techspark which helps limit shipping and packaging waste.

Unfortunately, as we have yet to receive feedback from the design presentation, we weren’t able to make an adjustments to our design plans this week. We did add some items to our BOM, such as power supply units. Because we removed wheels from our BOM, these costs can be easily absorbed into our remaining budget.

Our main risks going forward are centered in the structural section and motor control section. For structure, it’s unclear if our current setup will fully support the gantry weight, but we are planning on mitigating this risk by building and testing it early enough that we have time to add additional supports. For motor control, we may need some more parts or attachments to make the motors function correctly. Again, we are mitigating this issue by finding these flaws as early as next week.

Next week the team will complete the design report, website, and CAD, and will work on motor control, planning, and construction.

After last week’s presentations, we wanted to incorporate the some of the feedback we received. Firstly, we decided that some of our requirements we somewhat unreasonable such as having 95% accuracy and precision for drawing strokes. We reevaluated some of these requirements and decided on figures that were reasonable and justifiable.

Next we finalized our bill of materials (BOM) and while doing so we realized that we were going to be overbudget. The primary source of our spending is on structural and mechanical parts such as motors, rails, and wheels. In order to maintain the most functionality we decided to remove the wheels and the automatic horizontal adjustment functionality from our design for the following reasons:

1. We plan to showcase our design on the moveable whiteboards found in the 1300 hallway of Hamershlag Hall. These boards are much taller than they are wide. Therefore during our final presentation it would be unlikely that we’d be able to showcase the automatic horizontal movement.
2. Re-adding the wheels/horizontal movement would be a lot easier than trying to re-add rails/vertical movement. In the case where we end up under budget, it would be impossible to add the rails at a later date. However, wheels could be added later as they would be attached to the existing structure with only minimal changes.

Our final change this week was ditching the ultra sonic sensors used for dynamic dimension allotment. We decided that adding the sensors would be too bulky and a better alternative could be a basic monochrome camera which detects lines drawn by the user as bounds. However, we are still determining if this idea is worth implementing now that we no longer have horizontal functionality.

Looking toward next week, we plan to work on the following:

• Finish the website where the user will upload their PDF
• Get feedback from the Design Presentation to incorporate into our requirements and structure
• Place the remaining orders for materials on our BOM

Below are our answers to the questions outlined on Status Report 2:

A was written by Andrew
Our project is designed with user safety in mind. Since it involves motors and other moving parts on the gantry system, we are ensuring that those components are shielded or enclosed to prevent accidental injury during operation. The system will be designed so that users do not need to physically interact with the gantry once it begins drawing, minimizing the risk of harm.  Our project will be used for teaching, presenting, and collaborating. It reduces the time and effort required to manually copy diagrams onto a whiteboard which makes tasks less tedious and more reliable. It also gives users the chance for make quick edits. From the welfare perspective, this contributes to user well-being by streamlining preparation and letting people focus on the task at hand such as teaching rather than on repetitive manual work.

B was written by Alex

The robot particularly helps support teachers and students by automating the whiteboard writing process. This could help support underfunded schools by giving them access to a technology similar to smartboards or projectors that they may be unable to afford. It’s a mostly lower cost design that could be used throughout a building. These underfunded schools are often home to communities that are often underserved or underrepresented. It can also help aid in communication, as the whiteboard medium is one of collaboration, and this device would only make that easier.

C was written by Ethan.
We designed our project to be customizable and usable anywhere. Specifically we were targeting school teachers. This could have economic implications as we envisioned our project to be used on any type of whiteboard. Therefore schools would only need one gantry system that could be shared in the building. This would ultimately save money in schools since teachers would be more productive and thus a higher percentage of their salary would be spent on teaching. This could have a similar economic impact in other industries if used before meetings to save the setup time for the presenter.

This week was our first full week working on our new project direction after pivoting from our original idea of building an automated stroller last week. The change meant we had to spend a good amount of time brainstorming. Once we had the the idea, we worked together to define the requirements as well creating the proposal presentation together. The presentation itself went well, and it gave us a solid chance to talk through the system as a team.

Since we changed directions last week, we were a bit behind where we had liked to be. Despite this, we worked efficiently, and are planning to lock down the Bill of Materials quickly so parts can be ordered.

Plans for Next Week:

• Finalize the BOM and place part orders.
• Start CAD modeling for the gantry.
• Build an initial upload page for file submissions.
• Set up the Raspberry Pi and Arduino so they’re ready for hardware testing as soon as parts arrive.

Even though the pivot put us under some pressure, this week felt productive. We came together on the new idea, got through the proposal presentation, and set ourselves up to move forward.