DESIGN CHANGES:
- Shift from Web App to React Native Mobile App: Initially, we considered using a web app with Bluefy Browser to connect to the skateboard, but the lack of background functionality and the need for users to download an additional app posed significant limitations. We decided to switch to React Native, which provides better BLE support despite requiring us to learn a new framework.
- Cost Implications: While the learning curve for React Native is a consideration, we expect it to be more efficient in the long term. The upfront time investment in learning will save us from potential issues down the road, particularly in handling BLE communication more smoothly.
- RTK-GPS Breakout: We’ll now be using the SparkFun GPS-RTK Dead Reckoning Breakout – ZED-F9R from the course inventory, replacing our previous option. This is a great improvement, offering far better precision (0.01m horizontal accuracy) and saving us around $70.
- LIDAR Change: We also decided to use the Intel RealSense LiDAR Camera L515 from the course inventory, which we hadn’t initially considered.
- Raspberry Pi Change: We opted to switch from the Raspberry Pi 5 8GB to the Raspberry Pi 4 8GB, primarily to reduce power consumption. We’ll be powering the RPi and its accessories with a rechargeable power bank using USB-C, which helps manage our power needs better.
- UTM Coordinate System: We learned we could use the Universal Transverse Mercator (UTM) system to project GPS coordinates into a flat grid format (x, y coordinates). I found a Python library from CMU Roboclub that will handle the conversion from GPS to UTM and vice versa, which simplifies what could have been a tricky task.
SCHEDULE CHANGES:
- We’ve pushed back backend development to next week after the frontend is mainly complete but remain on target for the overall timeline.
- The goal for next week is to begin assembling the board, depending on when our parts arrive. Any progress we can make before Fall Break will be a bonus. After Fall Break, we need to move quickly if we want to hit the remaining deadlines
PROGRESS:
- Finalized the GitHub repository setup with a clean folder structure and environment configuration.
- Progress on coding the UI components, including the welcome screen for pairing, remote control layout, interactive map, and stats page layout.
- Parts list completed and submitted for ordering.
- We were able to find a Python library that will make converting GPS readings to UTM coordinates much easier, which will streamline our location tracking process.
- We’ve been exploring two ways to track the rider. The first is using geolocation APIs via Wi-Fi or cellular positioning, which is easy to implement but less accurate. The second approach involves using the GPS chip we already have to detect when the rider falls off via acceleration spikes. This method is more accurate but has limitations, like needing the rider to stay in place after falling.
- We’ve started working on the software for the Raspberry Pi, focusing on parsing and collating location data. Once we get the parts, we’ll be able to start assembling and testing.
SIGNIFICANT RISKS + MANAGEMENT:
- Risk of Part Delays: Timely arrival of parts is critical for us to stay on track. Any delays in shipping or sourcing key components could significantly impact our progress.
- Management: We’ll closely monitor shipment updates. The design adjustments we’ve made have already reduced our reliance on high-budget items, helping to mitigate this risk.
- Uncertainty in Rider Tracking Method: Both rider tracking methods (geolocation API vs. GPS chip separation detection) have their limitations. The geolocation API may not be accurate enough, while the GPS-based method requires certain conditions, such as the rider staying in place after a fall.
- Management: We plan to prototype both methods and evaluate them in real-world scenarios. We’ll likely combine both approaches for better accuracy and reliability.
- Power Consumption Issues: While switching to the Raspberry Pi 4 should reduce power consumption, there’s still a risk that the power bank might not provide enough battery life for extended use.
- Management: We’ll run power consumption tests once the system is assembled. If necessary, we’ll explore adding a secondary power source or upgrading the capacity of the power bank.
- Integration and Software Bugs: Integrating the hardware components and developing the necessary software could pose challenges that may delay us.
- Management: We’re already working on the software components that don’t depend on hardware, such as location parsing. This early work should give us a buffer in case integration takes longer than expected. We’ll also test individual components incrementally to catch issues early and address them promptly.