Caption:
Reworking our connectivity plan as a team to ensure reliable performance across locations.
Description:
On Monday, our group regrouped to address a major connectivity challenge after realizing that the school computer Hansika brought home could not properly connect to WiFi outside of school. Instead of treating it as an individual issue, we worked together to evaluate how this limitation could affect testing, development time, and performance during the showcase. As a cohesive team, we discussed our options and carefully considered what type of device and network setup would allow consistent WiFi access both at home and at school. We focused on creating a long-term solution rather than relying on temporary fixes, making sure our system could function reliably in any testing environment. This collaborative discussion showed strong coordination within our group, as everyone contributed ideas and aligned around a clear, practical plan moving forward.
PLTW Step:
Identify Problem and Plan because we collectively recognized that inconsistent network access was limiting progress and developed a unified strategy to ensure stable connectivity across all working environments.
Outcome:
By reconnecting as a team and creating a clear plan, we strengthened both our workflow and communication. This allowed us to confidently move forward with testing, maintain steady progress, and ensure our carrier will operate reliably during the showcase without unexpected connection issues.
Caption:
Testing Arduino Cloud on a Chromebook to improve WiFi connection stability.
Description:
On Monday, we tried using Arduino Cloud on a Chromebook as a new way to fix our connection issues. Our idea was that since Arduino Cloud runs through a browser, it would allow the carrier to connect more easily to WiFi both at school and at home without needing different setups. We were able to open Arduino Cloud and begin the setup process, which made it seem like this solution might finally solve the connection problems we had been facing. However, as we continued, access was blocked because of school restrictions placed on the Chromebook. This showed us that the problem was not with our hardware or code, but instead with device permissions and network limitations. Realizing this helped us understand that sometimes engineering challenges come from the environment we are working in, not just the design itself.
PLTW Step:
Identify Problem and Plan because we tested a new platform to improve connectivity, discovered that Chromebook restrictions were preventing progress, and began planning to move forward using devices that allow full access.
Outcome:
Even though Arduino Cloud could not be used on the Chromebook, we eliminated another possible issue and avoided spending more time trying the same unsuccessful setup. This helped us stay organized, better understand our limitations, and continue working toward a reliable connection without delaying our timeline.
Caption:
Testing the original app to verify whether connection errors were software-related.
Description:
After finalizing our updated connectivity plan, our group continued troubleshooting by returning to the original app to determine whether the issue was caused by the application itself. Working together, we carefully tested the connection process and checked all required settings, including confirming that our IP and IPv4 addresses were entered correctly. Based on our configuration, everything appeared to be set up properly, and we expected the system to connect without problems. However, despite using the correct addresses, we were still met with repeated errors during connection attempts. This helped us recognize that the issue was likely deeper than simple setup mistakes and required further investigation into how the app and carrier were communicating. Our team approached the testing process methodically, making sure each step was verified before moving forward.
PLTW Step:
Test and Evaluate because we intentionally tested the existing app under correct configurations to determine whether software malfunction or communication errors were preventing successful connection.
Outcome:
Although the connection was still unsuccessful, we confirmed that incorrect IP configuration was not the source of the problem. This narrowed down possible causes, allowing our group to move forward with clearer direction and continue troubleshooting efficiently without repeating unnecessary steps.
Caption:
Exploring an alternative app to test carrier connectivity and expand troubleshooting options.
Description:
While continuing to explore the carrier’s website for troubleshooting support, our group noticed that there was another compatible app available that could potentially be used to control and connect with the carrier. Recognizing that our current app continued to produce errors, we decided as a team to test this alternative instead of remaining stuck on the same platform. During the entire period, we focused on downloading the new app, setting it up correctly, and learning how its interface and connection process worked. We carefully compared its setup requirements to our previous app, checking network settings, permissions, and communication options to see whether this version would better recognize the carrier. As we experimented, we adjusted configurations, retried connections, and discussed what each result meant so we could understand whether progress was being made. Rather than randomly testing, our group approached the process strategically, using each attempt to gather information about how the carrier responded under different conditions. This exploration allowed us to better understand the range of software options available and how different applications handle device communication.
PLTW Step:
Test and Evaluate because we actively tested a new application, analyzed how it interacted with the carrier, and evaluated whether it provided a more reliable connection compared to our previous setup.
Outcome:
By dedicating time to testing an alternative app, we strengthened our troubleshooting process and avoided limiting ourselves to a single solution. Even while still determining full functionality, we gained important insight into compatibility and connection behavior, helping our group move forward with clearer direction and increased confidence in selecting the most effective control system.
Next Week’s Focus
Our main priority is finishing the mobile app and restoring full communication between the carrier and robot.
We will focus on identifying and fixing any remaining connection or configuration errors.
The goal is to make sure the carrier can consistently connect and respond through the mobile app without interruptions.
Krishwa will lead app testing by verifying network settings, permissions, and communication setup.
Hansika will monitor how the carrier responds during connection attempts and document any repeated errors.
Julia will confirm that all hardware connections match the app configuration to rule out wiring or device issues.
By the end of the week, the mobile app should be fully functional and reliably control the carrier.
Following Week’s Plan
We will carefully take apart the carrier to reassess the placement of materials and components.
The team will reorganize structural parts to improve balance and ensure mounting points align with the robot frame.
Krishwa will oversee reorganizing the structural components and mounting alignment.
Hansika will check placement to prevent instability or interference with movement.
Julia will reorganize internal components and wiring so everything is cleanly and securely positioned.
After reassembly, all parts will be in the correct positions to create a stronger and more efficient carrier.
Post-Adjustment Improvements
We will test the updated carrier together with the completed mobile app.
Controlled driving and response tests will confirm stability and communication.
Adjustments will be made if movement causes stress or instability.
We will improve responsiveness and consistency across multiple test runs.
At this stage, the focus is on refining performance and ensuring reliable operation every time.
Expected Evidence
Next review: working mobile app with confirmed carrier connection.
Following review: disassembled, reorganized, and correctly reassembled carrier.
Later review: stable driving performance with reliable app control.
Challenges We Are Preparing For
Remaining app errors may require repeated troubleshooting and testing.
Incorrect reassembly could affect balance, so placement checks are critical.
Material adjustments may change weight distribution, requiring stability testing.
Maintaining strong communication between hardware and the mobile app is essential throughout integration.