Posted on

Zeynep’s Weekly Status Report for 9/30

 

This week, I primarily focused on designing the solenoid embossing system and working with Becky to see how it would fit within the larger x/y gantry printing system. I also incorporated the user’s feedback into my current wireframe. (digibraille_wireframe_updated).

Before beginning the design of the solenoid system, I spent a lot of time consolidating my research from the previous week to select the best solenoid for our use. I decided on using a DC 12 V solenoid with a screw insert on the iron core. This solenoid will be the best for our use case because it provides enough force to emboss the paper (20 N) and will allow for us to screw in the braille pin-head for embossing. After I decided on the solenoid type I was going to use, I was able to begin thinking about designing the circuit and how to control the solenoid. This process involved employing my knowledge from my device sciences concentration, primarily 18-220 and 18-300 . The primary issues with using solenoids are the power consumption and controlling the switching of power on and off through the solenoid. The switching problem was an easy fix through the incorporation of a flyback diode in parallel with the solenoid. I am currently using an NMOS to control the circuit.

I tested this circuit in the LT SPICE simulator to make sure it was acting as desired, and would not exceed power requirements. Based on the available datasheet for the solenoid,  I calculated its internal resistance and inductance and modeled it as a resistor and inductor in series for my simulation. I then ran simulations of this circuit on LT SPICE over a time window of 10 minutes (our predicted embossing time) to test the power consumption of the circuit. I fed in a randomized square wave to represent inputs from the RPi. Based on stimulations, this circuit appears to be stable and fits our needs. However, I may still make modifications as I continue to test.

I also began to prototype this circuit. I was able to test it using a waveform generator as displayed in the simulation and a DC power source. I hope to test it using the RPi in the coming week.

I also worked through the math for deciding how many solenoids to use and investigated the question of how the system will move (i.e. one cell at a time, one line at a time, one cell per solenoid). I calculated exact spacings between the solenoid and braille cells based on the American Society of Braille requirements and the size of the solenoid. Based on this, we decided the solenoids should move only in the x direction, embossing the braille line by line. I also calculated the time it would take for each number of solenoids to emboss based on the specific distances they need to be embossing within. Based on my results, I decided that two solenoids would be optimal, as the speed begins to plateau after two solenoids.

I also worked Becky this week on some of the design of the braille embossing system and x/y gantry. I designed an enclosure for the two solenoids in Fusion 360 that will fit into her x/y gantry design.

I also spent time working on the design proposal presentation — creating block diagrams, writing tests and requirements.

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

My progress is currently on schedule with the Gantt chart for the hardware components I have been assigned to. I am a bit behind schedule for the UI component of my role so I will devote the upcoming week to catch up on that. I aim to have the mock-up complete and some initial features implemented on the front end by the end of next week

What deliverables do you hope to complete in the next week?

In the next week, I will continue to test the solenoid circuit with the RPi. I will complete the mock-up for the front-end of the web-app and begin implementing features. I will also work on the design proposal document.

Posted on

Joshna’s Status Report 09/30/2023

Our team overall have been using classes such as 18220 as well as more advanced megatronics and device science classes my teammates have taken to develop the embossing and communication design. The software design is inspired by webhacking learned in 18330, wrappers and database/cache organization learned in 18213, and testing/verification skills learned in 18240/18341. While the actual algorithms aren’t molded around an existing algorithm, the analytical skills and practice of coming up with our own stems from all the classes we have taken at Carnegie Mellon but for me, especially 15122 and 18213.

At the beginning of this week, I created a github (https://github.com/joshna-ii/digibraille) to help keep track of my progress and allow my teammates to work with my code, especially for when Zeynep develops the frontend further. I spent quite a bit of time later in the week working on the ReadMe and making it as easy to understand and use even in these early stages in order to set a precedent.

The main frontend file is called webapp.py, and I spent the first half of the week using the Flask library in order to create a website which is currently hosted locally (127.0.0.1:5000) when you run the python program. This is an example output and handler:

In general, I have been able to handle the different types of non edge-case inputs and a couple edge case inputs (non-input. poor web link formation) from the website post stage to the string that needs to be translated.

Based on the html user input, I had the webapp.py frontend handling file call the run_backend function in main_backend.py. This next file’s brings together the different parts of the backend: rpi_handler.py, translation.py, websearch.py, and soon a database file.

Websearch.py does the actual webscraping and queries depending on if main_backend.py received a link or a product name. I have a function called google which returns the first link for a google search given the keywords.

I have also created a function that handles direct links that are inputted as well as a function that finds matching keywords in all the pages of websites such as directionsforme and backoftheboxrecipes using the requests library and beautiful library.

The bulk of the execution code (outlined functions are still connected clearly everywhere) for the third function is currently in my temp_code.py file because I have been doing some unit tests, edge cases, and one-off tests. While I have been able to improve efficiency by tenfold by only accessing certain attributes of the webpages, it is still way too slow so my plan is to spend the beginning of next week transferring data from these websites to an internal database by modifying the function I created this week in order to make this process faster. If sufficient results have not been found with the internal database, main_backend.py will use the google function I worked on earlier and mentioned above and webscrape directions off of that.

I also spent a couple hours learning how to work with the raspberry pi yesterday after receiving it.

I am having trouble communicating with it as my laptop does not seem to recognize the device when I ping localhost so I am getting an ethernet cable today to try it that way and if that doesn’t work, I will go to campus and try to connect it to one of those computers. I am spending today working on rpi_handler.py in order to host the basic website through that and get the basic framework down for how the python files will communicate signals on location and movement of solenoids+motors to the raspberry pi post translation through the gpio pins.

I have also spent time this week working on the design presentation for next week including creating block diagrams, scheduling, designing algorithms, figuring out interactions between components, and calculating quantitative expectations.

While I did not achieve the reach goal I set last week of getting 50% of the webscraping done due to this method turning out to be innefficient, I am still on track with our expected schedule with the webscraping, website, and integration files so I do not have to reorganize the schedule.  My goal for this week is to get the basic rpi – python script communication down, get 50% of the webscraping done with databases and creating said database, and start the braille translations while making a more detailed schedule based on the different rules braille follows. I plan to translate the current string output I create to a list of a set of 6 signals with some of the more general braille rules after learning Braille even better myself as a person since there isn’t a 1:1 mapping between the english alphabet and braille characters.

Posted on

Team Status Report for 9/30

What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?

This week, we worked on finalizing the design of the solenoid embosser, designing the x/y arm system to move the paper, setting up the web-app, and began working on the web-scraping algorithm.

These are the primary risks we identified for this week:

  • The linear bearings of the x/y gantry must be manufactured to high spec. If they are not, this could impact the mechanical functioning of the braille embosser to not work as well.
    • Mitigation: Source parts carefully and make proper cost benefit analysis of cheaper parts.
  • Proper functioning of tensioning system for y-axis printing motion
    • Mitigation: modularizing design such that size of enclosure can be remanufactured/re-designed as needed
  • Lack of control over solenoids may cause complications with embossing because only have control over voltage variable
    • Mitigation: Designing effective control circuit. If solenoids fail, use motors (however cost of time)
  • For backend, considering the kinds of keywords people would use since we’re finding the website and not searching is a risk
    • Mitigation: In worst case scenario allow users to do a google search
    • keep researching websites to source from
  • Frontend accessibility and usability
    • Mitigation: planning user tests and debugging with apple accessibility debugger

Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?Provide an updated schedule if changes have occurred.

This week we made a few small components to the design. This however does not set us off track according the schedule.

  • Downsized number of solenoids to a total of two solenoids. This change was made because after the number of solenoids passed 2 solenoids, the amount of time it took to emboss a single character begins to plateau. We chose 2 solenoids because it is most manageable without slowing down the overall system
  • A large component of our design decisions was whether to couple or decouple the x/y gantry. We decided to decouple the gantry because it will be a simpler design overall, and will give us a bit more control and create a more stable system. Decoupling will reduce mechanical failure points and increases accuracy. It also appears to be cheaper than a non-decoupled system.
  • We have also modified the webscraping methods. We will now only be webscraping from a select number of websites that already have products listed. This decision was made because of lack of supporting libraries in python.
Posted on

Joshna’s Status Report 09/23/2023

We spent most of this week developing our design and practicing for the presentations. We honed down our use case to specifically help visually impaired people by allowing them to either enter notes and print that on our website or enter a product and print the instructions for using that product. We also figured out what tools we want to use and how to divide everything up. Our current plan is to use Python and HTML to develop the frontend, use Python for webscraping and databases and communicating to hardware, host our webpage on a CMU server, and use gcode instructions to control a RAMP board which controls the solenoids and the motors that move the solenoid system across the page.

I also started working on the webscraping portion since we were told to work from the most difficult part outwards. I have tried working with many Python libraries including googlesearch, requests, urllib, mechanize, and more in order to figure out how to make google queries in the easiest way. After a lot of debugging, I am only able to get the first google result. There isn’t much information about the generator object type for webpages and it appears like I am getting 0-1 results when I shouldn’t be. I also received a lot of errors with actually accessing a website to begin with but I believe that is because I am accessing the browser directly through code and so google treats me like a bot. I am looking into using other websites/browsers for searching.

I am able to get the first website from google now but I began to wonder what I would do if I were to get more than one result because there isn’t a standard to figure out what would be the best website for each product. I have started implementing using a website like directionsforme that already has lots of product compiled like a database while also using the first google search for any product that is not listed on this website. The webscraping should be easier for products on directionsforme because it is relatively standard so I am focusing right now on the best method for finding the information I want to scrape from each of the websites google returns. I am also considering whether or not I should have a feature that reads back the result and confirms with the user if that is what they want to be printed.

Another thing I have started to think about is how we will send instructions to the embosser. Since we are trying to make this as accessible as possible, we have to make sure that the embosser is an easy set up and that the website can actually send the instructions to the embosser. Wireless printers work by connecting to the same WiFi network as the device that will be printing. There is a RAMPS WiFi adapter so we might think about using that so we can continue with this design. I don’t have experience using gcode but Becky does so I did more research in how it works and it is common to send gcode wirelessly to 3D printers by connecting both to WiFi by using a WiFi SD card. I still have a lot more research to do on the interfacing between the webpage and the gcode output across WiFi.

Since we are still at the beginning of our project, we are on track. My goal is to make the webscraping algorithm work for 50% of the top product searches by the end of this next week. I also plan to get some of the basic html framewok up and running because neither Zeynep or I have much experience with actually building a website so it would be better to start earlier so we have more time to resolve issues. Lastly, our team also needs to make sure we understand the communication between our parts both because that will help define each of our “inputs” and “outputs” but also because it might require us to buy additional components.

Posted on

Team Status Report for 9/23

What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?

The most significant risks to the success of our project will be integrating all of the components and ensuring that they can communicate over wifi. The most integral component of our project is the user being able to connect to the braille printer with their phone, so it is important that we ensure the communication between each component runs smoothly. We are thinking about managing the risks of communication between components and communication on wifi by possibly  using a WIFI sd card and sending the g-code instructions wireless through this way. We are also considering using a wifi adapter for ramps boards. If this doesn’t work we may consider having the user plug their phone into the braille embosser. 

Another risk is the power management of the solenoids and ensuring that they don’t generate too current. We are managing this risk by including flyback diodes for each solenoid and separating the control of the solenoids (arduino) from the power source of the solenoids.

Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?Provide an updated schedule if changes have occurred.

During the design proposal, we presented a 6 solenoid system. After doing more research on the solenoid mechanism and the mechanism of our braille printer, we decided that a 3 solenoid system would work better under the constraints without compromising timing requirements. This however, does not alter the design and will lower the cost. It also will not impact the schedule.

 

Posted on

Becky’s Weekly Status Report for 9/23

What did you personally accomplish this week on the project?

This week I met up with Alycia to get feedback on the design direction we should be going in for the Braille embosser. I asked her about how she can distinguish between different sides on a box, because we will need to be able to load paper in a specific direction on the printer. She mentioned different way of adding tactile information like adding an arrow to where the embosser needs paper inserted.

She also gave us the opportunity to use her different accessibility tools on her iPhone, and I have to say I’m pretty impressed with how easy it is for her to navigate around on her iPhone with her braille input device. She was able to navigate around Wikipedia and search up information about Beyonce no problem. She also showed how certain menu displays are not accessible to her, and aired some grievances about the Dunkin Donuts app and their inaccessible app.

I learned so much from Alycia this week, and I think her involvement in the project will steer us towards making a project that is actually useful to blind users. She took the time to show us the different tools she uses in her day-to-day life and that gave us some ideas on things we can integrate into the software side of the project. Specifically, she showed us these glasses she uses to read text, and detect scenes, which integrate already into her phone and could be a cool tool to integrate into our project because she could take a box with instructions, look at it with her glasses, and then take the text output from the glasses, and convert it into braille. Here’s a pic of me trying these glasses on at Panera Bread this week.

Me wearing the glasses that read text and detect scenes.

I started exploring how the gantry system was actually going to get constructed, and realized very quickly that designing our own system from scratch would be really expensive in terms of time, effort, and money to create, and that it would be a better use of time to buy a x/y system that was already built. I ended up finding a 3D printer for 135$ on Amazon that would have all of the mechanical parts we would need to print braille, and most of the electronics already included. When I looked into 2D plotters they were more expensive, and also may not be the best choice because we want to be able to control the amount of tension we have between the paper and the embosser.

I think using the 3D printer kit would come with many advantages including:

  • X/Y mechanical movement already figured out (saves time & $$$ on prototyping)
  • Electronics have JST connectors we can plug into our control board for easy wiring
  • We can control the Z-height of the embosser, which will be good for finding optimal tension between the paper and the embosser. It also gives us a lot of flexibility when designing the embosser
  • Parts already integrate into the RAMPS based control system we plan on using.

Like any other decision, using this kit will have its’ drawbacks.

  • The z-height is much taller than we need it to be. We can cut this piece, but that will require us to disassemble and reassemble the x/z gantry
  • We will need to figure out a way to make it easy to register the paper (consistently place the paper in the exact same location)  in a way that is accessible to our user. I think we can accomplish this by creating a easy to use slot based system.
  • We will need to modify the slot where the extruder goes to fit the solenoid.

If we were to source our own parts, it would be so much more expensive to build, to the point where it wasn’t worth finishing the spreadsheet.

DIY assembly Cost Quan Total Link
Nema 17 motors 8.99 3 26.97
Linear slide + mount 37.99 3 113.97
limit switches
tensioner
t slot
Nuts & screws
T-Slot Brackets
ETC
ALT TOTAL 140.94

Using the 3D printer kit will take some work to modify. We will need to do the following to create a system that meets our requirements:

  • Creating a mount for the embossing solenoid to go on the X/Z gantry
  • Making an accessible registration system
  • Creating an enclosure for the 3D printer so it is safer to use
  • Integrate the electronics to the ramps board
  • Figure out how to control the solenoids on the ramps board
  • Figure out how to communicate with the software portion of the project

I started exploring how we will control the system as a whole, and there is a way to control the 3D printer using G-Code on the RAMPS board. We will be able to modify the firmware to meet our hardware needs, as they have a way to add solenoids. I think we will be able to also add a setting to keep the embosser head at a specific height, depending on the tension that works best for printing.

I also started exploring how to communicate with the RAMPS board over Wi-Fi, and there is this software called Octo-Print that runs on a raspberry pi can control a 3D printer. I will need to do more research to see how we can integrate it into our software system, but it is a good sign that this exists.

Is your progress on schedule or behind? 

I feel like I’m making good progress on the project, and I think this week we can actually make some tangible progress if we can get the 3D printer ordered this week.

What deliverables do you hope to complete in the next week?

  • Order the 3D printer kit, and RAMPS Controller
  • Put in a request for a raspberry pi
  • Come up with a specific plan to communicate with the 3D printer over wifi
  • Design PCB’s that make connecting the limit switches, solenoids, and any other auxiliary hardware easy to plug into the ramps board.
Posted on

Zeynep’s Weekly Status Report for 9/23

What did you personally accomplish this week on the project? Give files orphotos that demonstrate your progress. Prove to the reader that you put sufficient effort into the project over the course of the week (12+ hours).

This week, I began researching UI considerations for the web-app of our project and began familiarizing myself with JavaScript. I read through the Apple Accessibility Software Kit documentation, which informs developers on how to make design decisions that are compatible with the Apple accessibility features.  I researched design decisions that can be made (ex: color, font choice) that make a site more reasonable to users who are not completely blind. I also tested websites that are popular amongst blind users, such as directionsforme.org and experimented with Apple’s accessibility features to better inform the design of our web-app. Based on this research, I drafted the wireframe for our web-app, outlining its basic functionalities.

digibraille_wireframe

This week, I also had the opportunity to conduct a user interview. I learned about different technologies that blind users already use in their daily lives. This will inform the design of our website as we aim to make it compatible with existing technologies.  Some examples of this being a braille display keyboard that allows her to type and glasses that scan text and convert it to speech. From the user-interview, I also learned about examples of bad design and apps that were not compatible with accessibility softwares. I conducted a user interview and received feedback on the usability of the web-app’s interface based on the wireframe I designed.

I also researched existing braille embossers and their mechanisms to better inform the design of my team’s solenoid system. This includes looking into different embossing mechanisms and different types of solenoids. Some design questions I considered include: how many solenoids should our system use, what does the x-y motion look like, and which solenoids provide enough force to emboss the page. I also researched into fly-back voltage considerations when using solenoid systems, and began modeling/drafting the circuit diagram and calculating which solenoids will satisfy the considerations of the embosser.

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

My progress is currently on schedule with the Gantt chart.

What deliverables do you hope to complete in the next week?

In the next week, I will incorporate the user’s feedback into the wireframe of our web-app, complete the user-flow, and  begin designing the mock-up of the site. I will complete modeling the solenoid system and create a full schematic diagram.