Category: Team Status Reports

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.

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.

Significant Risks + Management
One significant risk this week was a spark that occurred when testing in tech spark. Exposed metals on the pos and neg sides of our battery connection to the VESC ended up touching by accident, creating a spark and slightly burning the wire around it. No one was injured nor were any parts damaged in any way. To solve this problem, we have heated the shrink wrap previously set in place to ensure there is no longer any exposed metal.

Another area of risk is the connection from the pi to the LiDAR. For some reason, building (running make-j1) or make-j4) takes about 45 minutes to complete when the command in the tutorials I am watching takes <1 minute. I am attributing this primarily to all the other packages we had to install to get bluetooth, pyvesc, etc to work but it is making integration and trial and error very difficult.

 

Third area of risk is the GPS accuracy as we were not able to get sufficient accuracy readings in our last meeting due to poor weather conditions. We did not want to risk damaging parts in the rain.

Design Changes

We have changed LiDAR from d515 to d455 as it is meant to be used outdoors and thus more suited to our requirements.  We have also swapped our deck to be about 4 inches shorter to allow for better turning when autonomous.

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
This week, we achieved our first succesful turn after previous failures and inconsistencies. By shortening the wheel base and decreasing the acceleration step, we are able to perform a consistent and relatively tight turn. The only asterix here is that we are noticing significant wear on the edges of the powered tires, likely from shuffling during turns. These turns also leave visible tire marks on the ground.

We also swapped our LiDAR and ran tests on the laptop. We were able to get a much clearer image and much more accurate LiDAR readings in key environments where the other LiDAR was failing (outside). This allows us to be much more accurate to our original design requirements as we begin integration/ implementation.

We also achieved our first test with a rider on board. Both Jason and Tio took a turn riding with some acceleration applied to the back wheels. The ordeal went well, the board handles well and the acceleration seems to be very smooth and controllable. The board turns very well and we have not experienced any wheel bite or speed wobbles. The next step will be to test on inclines and at higher speeds.

We also shrink wrapped a variety of loose items on the board to ensure no further accidents occur while testing or while anyone is actually riding.

We also made substantial progress on enhancing the GPS accuracy for our ‘Return to Me’ feature. We conducted extensive testing using the React Native geolocation library, comparing the app’s GPS readings to those from the hardware GPS on the skateboard, which we set as our ground truth. Indoor tests revealed some limitations in accuracy, whereas outdoor tests provided a precision of around 5 meters, aligning with our initial requirements for outdoor navigation. We are now considering snapshotting the user’s location to improve the consistency of the ‘Return to Me’ feature. Further testing and adjustments are planned to maximize GPS reliability and meet our accuracy goals under various environmental conditions.

Significant Risks + Management
One significant risk this week involved challenges with the Raspberry Pi to VESC and GPS connections. Initial attempts to use GPIO for motor control proved unreliable, so we opted to switch to USB communication, which is now working effectively. This change helped address stability issues, though it required adjusting our setup and code. Additionally, there is a risk associated with synchronizing motor commands to achieve simultaneous control, which we plan to mitigate using Python’s multithreading capabilities.

The Intel RealSense LiDAR Camera L515 also poses a challenge. The product’s discontinuation means we’re using outdated SDK versions, which introduced complications with the Raspberry Pi’s Linux environment. Building the SDK from source has proven necessary, which could further delay integration. The team is prioritizing the completion of the LiDAR setup on the Raspberry Pi to avoid future bottlenecks.

Design Changes

No major design changes were implemented this week. However, based on the LiDAR’s outdoor performance limitations, we are considering relaxing our object detection requirements. Instead of general obstacle avoidance, we may focus on recognizing a specific object, such as a traffic cone, to simplify our proof of concept. This shift would allow us to use the LiDAR’s RGB camera with OpenCV for object detection and refine our recognition parameters later if required.

Schedule Changes

The project schedule has been updated to account for the switch to USB communication for both the VESC and GPS modules. This modification may shift certain tasks, like debugging multithreaded motor control, into the upcoming week. Additionally, the timeline reflects ongoing efforts to migrate LiDAR code to the Raspberry Pi. Despite these adjustments, core tasks such as motor control development and return algorithm testing remain on track with project milestones.

Progress
This week, the team achieved individual control over the motors through USB connections, addressing GPIO-related stability issues. The plan now is to synchronize motor commands using multithreading to enable simultaneous operation. The team also began building a Python class for motor control, which will centralize all control methods.

For the LiDAR, we encountered difficulties due to the need to build the SDK from source on the Raspberry Pi’s Linux environment. However, initial tests with the LiDAR’s RGB camera showed reliable object detection indoors, leading us to consider narrowing our vision requirements.

We  soldered connections for the battery, VESC, and power switch, completing crucial steps toward the skateboard’s assembly. While GPS data collection has been postponed until the USB setup is finalized, we are prepared to implement the return algorithms as soon as the board assembly is complete.

We completed the backend server setup on the mobile app, enabling it to communicate effectively with the Raspberry Pi. This involved creating key API endpoints for controlling and monitoring the skateboard, as well as connecting these endpoints to the app’s frontend. This setup establishes a solid foundation for real-time interaction and prepares the app for seamless control over skateboard components.

 

 

Also, added new functionality allowing users to control skateboard actions via the phone’s volume buttons and ringer controls. By setting up listeners for these hardware buttons, we enabled alternative control options within the app, making adjustments more intuitive and accessible without relying solely on touchscreen inputs. This feature provides added convenience, especially for quick or hands-free adjustments.

Lastly,  to enhance the app’s location-based capabilities, we implemented GPS functionality using a React Native library, configuring it for accurate tracking and smooth operation. We are extensively testing by adjusting various settings within the library to improve location precision. Additionally, we set up frontend permissions to enable GPS access, providing users with a reliable, permission-secured experience during location tracking and navigation.

 

 

 

Significant Risks + Management

One significant risk this week involved challenges with the Intel RealSense LiDAR Camera L515. Since the product is discontinued, the team faced issues with outdated documentation and incompatible software versions. This risk was managed by identifying compatible versions of the RealSense SDK (v2.50) and the pyrealsense module (v2.54), ensuring the LiDAR can still be integrated into the project.

There is also a risk associated with migrating the LiDAR code to the Raspberry Pi environment. This task is currently in progress, but further delays could impact the testing schedule. The team is prioritizing this migration to avoid potential bottlenecks.

Design Changes

No significant design changes were made this week. However, the team has discussed the continued relevance of backend functionality. If backend development is pursued, it may require additional modifications to the web application and data management strategies.

Schedule Changes

The project timeline has been adjusted to reflect the delay in LiDAR migration to the Raspberry Pi. Despite these setbacks, critical tasks such as sensor integration, motor control development, and return algorithm testing remain aligned with the overall project schedule.

Progress

This week, the team successfully configured the LiDAR sensor by resolving software compatibility issues. The necessary versions of the SDK and Python libraries were identified and installed, allowing the team to write a program that raises a signal if a variable percentage of the LiDAR’s view is blocked within a specified distance. These parameters will be further refined during integration testing.

The team also soldered the battery, VESC, and power switch connections, ensuring the propulsion system is ready for assembly. While LiDAR functionality has been tested on desktop, migration to the Raspberry Pi environment is ongoing. In parallel, GPS integration frameworks are prepared to ensure smooth setup once missing components arrive.

SIGNIFICANT RISKS + MANAGEMENT:

One significant risk currently facing the project is the delay in GPS testing due to missing components, such as the antenna and Qwiic connectors. Without these parts, there is a risk that potential integration issues with the GPS module might not be identified early, which could impact the timeline for autonomous features. Another key risk is the delay in Bluetooth integration between the mobile app and the Raspberry Pi. This was caused by limited access to the Raspberry Pi earlier in the week. To mitigate this, mock data is being used to test the BLE functionality, ensuring that once hardware is accessible, the final integration can proceed smoothly.

There is also a risk with backend development—the team is still debating its necessity. If backend services are deemed essential later, it could introduce delays. To manage this, we are exploring lightweight solutions to avoid additional complexity.

DESIGN CHANGES:

So far, there have been no major design changes this week. However, discussions are ongoing about whether to implement a backend server for managing user data and skateboard status. If backend functionality is introduced, it may require modifications to both the web app and data management strategies. Additionally, the fall break adjustment in our Gantt chart has led us to focus more heavily on setting up hardware and testing BLE connections, slightly shifting the weight of certain tasks in the schedule.

SCHEDULE CHANGES:

The project schedule has been adjusted to account for fall break, with the understanding that fewer tasks were planned for completion during that week. This adjustment allows us to reallocate efforts toward critical tasks in the upcoming week, including sensor integration and motor control development. Additionally, the delay in Bluetooth testing pushed some BLE-related milestones into next week. These adjustments ensure that the project can continue progressing without disruptions, and all key deliverables are still aligned with the final deadlines.

PROGRESS:

This week, the team made significant progress in both hardware setup and software development. Parts from the course inventory, including the Raspberry Pi 4, Intel RealSense LiDAR Camera L515, and SparkFun GPS-RTK Dead Reckoning Breakout (ZED-F9R), were retrieved, and initial setup tasks were initiated. The Raspberry Pi environment was configured, and preliminary testing of the LiDAR sensor was successfully performed on desktop and Windows devices. This involved installing the RealSense software and exploring the Intel SDK’s integration with Linux. We also reviewed Python code samples to streamline sensor integration efforts.

In parallel, the mobile app development progressed significantly. The entire UI/UX, with animations, real-time feedback, and responsive design, was completed, and the core layout for the remote control is now ready. Foundations for Bluetooth Low Energy (BLE) integration have been established by refining connection flows. However, Bluetooth testing has been delayed as access to the Raspberry Pi was limited this week. In the meantime, mock data is being used to simulate the BLE functionality. The team is also considering the need for backend coding, which is still under discussion.

Testing of the GPS module remains pending as essential components, such as the antenna and connectors, are still on order. The design report has been finalized and will guide system integration moving forward. Additionally, we adjusted our timeline to account for fall break, acknowledging that fewer tasks were expected to be completed during this period unless necessary.

Part A: Global Factors

(Written by Tioluwani Ajani)

SkateBack addresses the growing global need for sustainable, accessible urban transportation solutions by providing a personal mobility option that is electric, compact, and adaptable to various environments. With increased urbanization worldwide, many cities face challenges related to traffic congestion, air pollution, and accessibility. SkateBack offers a zero-emission alternative that encourages individuals to reduce their dependence on fossil-fuel-powered vehicles, contributing to a cleaner environment. As governments and organizations worldwide push for carbon neutrality and improved air quality, personal electric transportation options like SkateBack align with these goals by promoting environmentally friendly travel options. This solution not only benefits cities but also applies to smaller communities where public transportation options may be limited or unreliable, bridging the mobility gap sustainably.

Part B: Cultural Factors

(Written by Jason Hoang)

a

Part C: Environmental Factors

(Written by Sharon Li)

SkateBack is designed to address environmental challenges, particularly in urban transportation and air pollution. By offering a zero-emission alternative for short-distance travel, it contributes to reducing the carbon footprint. As cities and governments push for carbon neutrality with stricter emissions regulations, electric skateboards like SkateBack enable individuals to actively participate in these global environmental efforts. With its rechargeable batteries, SkateBack minimizes the need for fossil fuels, and its compact size reduces the strain on urban infrastructure. SkateBack is designed to reduce dependency on cars and other gas-powered vehicles, thus playing a role in the mitigation of environmental impacts from transportation.

Beyond providing sustainable mobility, SkateBack encourages users to adopt greener habits. Its CO2 savings feature allows users to track how much they’ve reduced their emissions by choosing the skateboard over traditional vehicles. This raises awareness about carbon footprints and empowers users to make more eco-friendly transportation choices. As cities adopt greener transportation solutions to combat climate change, SkateBack aligns with initiatives to reduce fossil fuel dependence and enhance sustainable urban mobility.

• 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:

SIGNIFICANT RISKS + MANAGEMENT:

BLE and iOS Compatibility:

• Risk: One of the biggest risks we encountered this week is BLE (Bluetooth Low Energy) compatibility on iOS devices. Our initial plan was to connect the web app directly to the Raspberry Pi using BLE, but iOS doesn’t support this method without significant workarounds or the use of additional hardware.
• Management: We are currently evaluating two alternatives to manage this risk:
  1. React Native: This approach would allow us to build a mobile app with BLE support for iOS. However, this requires learning the React Native framework, which could slow our progress in the short term. The benefit is that this would give us more control over app features and a more integrated experience.
  2. Bluefy Browser: This is a quicker, web-based solution that offers BLE support without the need for extra Bluetooth hardware. However, the downside is that it doesn’t run in the background and would require users to download an additional app, which could impact the user experience.
• Contingency Plan: While there is no immediate need to invest in extra Bluetooth hardware, we will continue to evaluate both options based on development time and usability. We are confident that either React Native or Bluefy will work for our requirements.

DESIGN CHANGES:

• Connection Method:
  • Change: We’re reconsidering our connection method due to BLE not being supported on iOS.
  • Why: This is necessary to ensure iOS users can connect to the skateboard without needing additional hardware.
  • Cost Impact: Learning React Native could slow development, while Bluefy’s limitations might affect user experience.
  • Mitigation: We’re still evaluating which option will have the least impact on project timelines and functionality.

SCHEDULE CHANGES:

• The project environment setup and architecture definition were extended to next week due to time spent researching BLE alternative.

 

PROGRESS:

• Completed the design for the skateboard connection, control interface, and real-time data display. Prototyped the app flow in Figma, making it easier for the team to understand the functionality. Feedback from teammates was incorporated using Figma’s comment feature.

 

 

Part A: Public Health, Safety, or Welfare

(Written by Tioluwani Ajani)

The SkateBack project is designed with a focus on enhancing public safety and personal mobility by providing an electric skateboard that can autonomously navigate and recall itself to its user. This feature addresses the need for improved safety in situations where users might become separated from their skateboard, especially in busy urban environments or recreational areas. The SkateBack system minimizes the risk of accidents or loss by using a combination of GPS and obstacle-detection technology (LIDAR) to ensure that the skateboard can safely navigate back to the user without colliding with pedestrians or obstacles. This greatly reduces the chance of skateboards becoming hazards on crowded sidewalks or streets.

Part B: Social Factors

(Written by Sharon Li)

The SkateBack project is designed to align with a growing social movement towards environmental sustainability and urban mobility. In many communities, there is a strong interest in adopting greener modes of transportation that reduce reliance on gas-powered vehicles. This product caters to those social groups that prioritize environmental responsibility, as it allows users to actively participate in reducing their carbon footprint through a cleaner, electric mode of transportation. SkateBack helps users organize around social interests like climate change, eco-conscious living, and promoting a more sustainable future.

In addition, the project encourages a shift towards a more active and outdoor-oriented lifestyle, which is increasingly valued in many social and cultural settings. As cities become more congested, urban communities are looking for convenient, eco-friendly alternatives to traditional vehicles, and SkateBack provides an innovative solution for short-distance travel. By offering a compact, efficient way to move through urban spaces, it promotes social interaction and engagement with the local environment. The product also supports a sense of community by fostering shared interests in technology, sustainability, and mobility.

Part C: Economic Factors

(Written by Jason Hoang)

SkateBack is a product driven by many economic factors. The first is cost-effective transportation. Especially in very urban areas, having a car is both expensive and impractical. For a fraction of the cost, SkateBack can bring you to and from work often faster than a car would. In an age where vehicle costs and maintenance grow, SkateBack provides a logical and cheap alternative.

The second factor is reducing traffic and hitting environmental goals. From a city perspective, less cars means less carbon emission, less road maintenance, and a reduction in many other costs. Lower infrastructure costs can mean more money goes back to helping the citizens in other ways. Outside of the classroom environment, scalable production means the cost of SkateBack gets dramatically reduced, making it more accessible for everyone.

SIGNIFICANT RISKS + MANAGEMENT:

DESIGN CHANGES:

• Adjusting the Skateboard Deck Manufacturing
  • Why: After reviewing the budget and discussing the pros and cons of designing vs. purchasing a premade skateboard deck, we opted to go with a premade one to reduce costs and speed up development time.
  • Cost Incurred: Decrease in cost–we save on time and manufacturing resources (laser cutting, materials).
  • Mitigation: By purchasing the deck, we avoid delays in custom fabrication and ensure more time for integration of components.

PROGRESS:

• Completion of Requirements Gathering for Web App
  • The requirements for the Skateboard Control (Accelerate, Decelerate, Reverse, Recall) and Real-Time Data (Battery Life, Speedometer, Trip Details, Environmental Impact) components have been thoroughly documented.
  • Defined both the UI design and functionality for these components, including how data will be retrieved from the skateboard’s hardware.
• Figma UI Design Mockups
• Initial design for the mobile-first UI, showcasing design choices of color palette as well as home page and connection page.
• Decided on Raspberry Pi model for the board
• Narrowed down to two choices for the IMU and GPS
• Performed an early cost estimate for parts