Skip to main content

Week 9 (Oct. 24, 2018): Presentation #2 (Primary & Alternative Design Concepts) Reflection & Eliminating GPS as a Possibility

Earlier this week, to prepare for our presentation on October 24, I looked into different GPS modules. Unfortunately, I concluded that it was not possible to implement one. Recently, I learned in my ME 190 class (Mechatronics System Design) that GPS is not very accurate, as it does not have a fine resolution. Within a 10-meter radius, the satellite cannot distinguish whether the object is at the 1-meter mark or if it’s at the 9-meter mark; in other words, the object that the GPS is attached to will just be a big dot on the map. To illustrate my point, a map is shown below. The top image depicts the position of the GPS user represented by a large dot. That dot covers 10-meters, as the bottom image shows smallest measurement that that can be achieved by zooming in is 10-meters. After travelling nine-meters in one direction, the GPS has not updated the location of the dot. Additionally, the object would have to be travelling faster than 1 m/s; we aimed to have the podcar travel at around 1 m/s, so there is chance that the moving object will still not register on the GPS. Thus, while implementing the GPS would have solved both the collision-avoidance and the location tracking issue, it would not be a viable option for the small-scale model, as the entire track is about two-meters end-to-end.

 

Instead, we will be resorting to using one of the three options: (1) adding a second ultrasonic sensor to the front corner of the podcar, in addition to the sensor that is already on the front of the pod car; (2) installing an IR sensor array; (3) or using a time-of-flight sensor mounted on top of a servomotor to act as a makeshift lidar. Another thing to note is that, currently, the podcars act separately, with each podcar having their own Arduino to control it. If we were to install a centralized master control system that would control all the podcars, this could possibly solve both issues of collision-avoidance and location tracking. The centralized control system would be placed on a tower in the center of the track. A lidar, or if we’re resorting to the time-of-flight sensor mounted on top of a continuous rotation servomotor, would be connected to this central tower to continuously rotate 360 degrees and keep track of all the podcars’ locations. This is something to discuss about with the Small-Scale Track Team, and, should we decide it to be a good idea, possibly ask Dr. Furman about. 

Comments

Popular posts from this blog

Week 30 (May 8, 2019): Prototype Evaluation Day, Final Circuit, Incorporating 3D printed parts, Final Presentation, Posters, & Maker Faire

Today, we held Prototype Evaluation Day. Like the rest of the senior project classes, the advisor walks around the classroom, evaluating the senior project apparatuses, asking the student teams to demonstrate their devices, and explain their design, though processes, and results. Dr. Furman and Ron examined and inspected the Full-Scale model, then the Half-Scale model, and lastly, us, the Small-Scale Team. We had completed our circuit to power one pod car and one of the two induction charging stations prior to Evaluation Day, so we were able to successfully demonstrate the pod car driving around the track as well as the induction charging. While we were still troubleshooting issues with the tablet’s Raspberry Pi communicating with the Arduino, the Arduino is still capable of operating on its own, so we could at least demonstrate the motor driving the pod car around the track and through the offline stations. Depicted below is our final circuit that powers the pod car: Dep...

Week 28 (Apr. 24, 2019): Final motor selection – Mini-Stepper Motor

Since last week, we have been trying to run the new brushless DC motor; however, it is still difficult to control, let alone its speed. Therefore, we had to pursue our alternative motor, the mini-stepper motor that runs at 5V. Found in Arduino starter kits, this mini-stepper motor is accompanied by its dedicated motor driver board, the ULN2003, which is a chip containing a series of Darlington pair transistors. An image of the stepper motor and the ULN2003 board is shown below:   Sources: https://www.adafruit.com/product/858 https://www.amazon.com/gp/product/B01CP18J4A/ref=ppx_yo_dt_b_asin_title_o03_s00?ie=UTF8&psc=1   We were able to successfully run the new mini-stepper motor with the sample code included with the Arduino starter kit. One benefit to using the sample code is that it utilizes the Stepper library’s functions. One use function is the setSpeed( ) function, which allows the user to set the RPM speed of the stepper motor. We found that the ma...

Week 27 (Apr. 17, 2019): ME 195B - Presentation #2 (Prototyping Stage Continuation) Reflection

Today, we completed Presentation 2, which is our 5 th  presentation overall, throughout the entire length of senior project, since last semester. Please refer to our Presentation #2 slides, embedded below. Covering the continuation of our prototyping efforts, we discussed progress on hardware acquisition, integration of components into a working circuit, and programming. Regarding programming, we were still working on the communication between the Raspberry Pi and the Arduino. And while the circuit is also coming together, there was one piece that gave us problems yesterday: the gimbal motor broke and so we had to order another motor that is not a gimbal but is still a brushless DC motor. An image of the new motor is found in our presentation slides below. While this was disheartening at first, we found that the gimbal is not intended for continuous rotation, but instead for precise movement, as they are used for cameras on drones. However, this was still a setback...