Significant Risks + Management
One significant risk this week is that we’ve observed that the readings we receive from our GPS chip without RTK support are far too inaccurate for us to achieve successful autonomous returns. Accordingly we’ve sought advice from Roboclub given their experience using GPS-RTK for robobuggy. We received a list a short list of hardware we needed and have placed orders already.
Design Changes
We will no longer be buying a deck, and instead we will be 3d printing one using the printers available in Roboclub.
Schedule Changes
Core task schedule remains the same. We are likely going to have to dip into the extra testing time we reserved at the end to get through small items such as LiDAR connection and any Bluetooth mishaps.
Progress
As of this week our project has reached its MVP of being a fully functional electric skateboard that is controlled by a web application, with the ability to accelerate, decelerate, and reverse at the press of a button. Sharon successfully connected the phone applications backend Bluetooth signals to the software on the skateboard’s Raspberry Pi.
As we approach the final physical layout for electronics on the skateboard, Jason has began printing out the enclosure we will use to secure them.
Tio is working with on the location and orientation aspects of the skateboard’s autonomous return features, while Jason has put in many hours focusing on the computer vision aspect.
Sharon worked on integrating the backend Bluetooth signals from the mobile app with the Raspberry Pi on the skateboard. This involved addressing challenges with outdated libraries by utilizing a specific fork of Bleno and implementing a socket-based communication flow, which improved responsiveness and reduced latency for motor control commands. Sharon also worked on refining the GPS accuracy for the ‘Return to Me’ feature by testing various filtering techniques, including the Kalman filter, to smooth out location inconsistencies. Additionally, Sharon refined the app interface, introducing an emergency stop button requiring a double-tap to activate for added safety and removing the reverse functionality to simplify user interactions.
Verification Testing Plans
Speed Test
- Measurement: 15 mph ± 1 mph
Test Input: Accelerate and decelerate on varied terrain (flat, inclined), rider weight, and motor load.
Test Output: Speed should remain within 14-16 mph.
Risks: Failure to maintain consistent speed and reach top speed.
Battery Efficiency & Range
- Measurement: 5 miles ± 0.25 miles per charge.
Test Input: Continuous ride over varied terrain and rider loads (150-240 lbs).
Test Output: Travel 5 miles on a single charge.
Risks: Battery drains too quickly, insufficient power for “Return to Me” function.
Return to Me Accuracy
- Measurement: 80% success rate within 1-meter margin.
Test Input: Recall skateboard over varying distances (5m, 10m, 50m, etc.) with/without obstacles.
Test Output: Skateboard returned to user and retrieved within 1-meter margin smoothly.
Risks: Pathfinding issues due to GPS/IMU inaccuracies.
Obstacle Detection
- Measurement: Detect objects within 100ms, 90% accuracy.
Test Input: Set obstacle course with varied object sizes (rocks, trees, etc.).
Test Output: Skateboard successfully avoids obstacles within design requirements.
Risks: Slow or no detection at all, especially in fast-moving or small obstacles.
Latency Test
- Measurement: Command response ≤ 100ms.
Test Input: Send commands from web app (accelerate, decelerate, etc.).
Test Output: Response time should be ≤ 100ms.
Risks: Bluetooth disconnects, delayed execution of commands.
End-to-End Integration
- Measurement: No interruptions in 2+ mile trip.
Test Input: Combine all features, ride continuously for 2 miles.
Test Output: System functions smoothly for the entire trip.
Risks: Loss of connectivity or inconsistency between components - Bluetooth Integration Testing:
- Test Objective: Ensure that the Bluetooth communication between the mobile app and Raspberry Pi is responsive and reliable.
- Measurement: Command latency should be ≤100ms.
- Methodology: Use timestamps in app commands and Raspberry Pi responses to calculate round-trip latency. Test commands (e.g., accelerate, decelerate) across different distances (1m, 5m, 10m) to check for consistency.
- Anticipated Results: Latency within the design specification, with no more than one disconnect per hour.
- Analysis Plan: Compare measured latency and disconnect frequency against benchmarks. If the results exceed acceptable limits, investigate interference or library issues for optimization.
- GPS Accuracy Testing:
- Test Objective: Improve location tracking accuracy to within a 4-meter margin.
- Measurement: Distance error in meters between actual and reported locations.
- Methodology: Perform controlled outdoor tests using known fixed points as references. Apply filtering techniques like Kalman filters and compare pre- and post-filtered results.
- Anticipated Results: Average error ≤4m, with reduced noise in filtered data.
- Analysis Plan: Evaluate filtered GPS data for consistency and repeatability across multiple tests. Document limitations and refine filters or hardware configurations as necessary.