Team Status Report for 11/2/2024

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.

 

 

 

Team Status Report for 10/26/2024

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.

The team also completed the Bluetooth setup on the Raspberry Pi, enabling automatic BLE service activation on boot. This functionality was tested successfully, allowing the app to find and pair with the Pi reliably.

Team Status Report for 10/19/24

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.

Team Status Report for 10/5/24

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.

Team Status Report for 9/28/24

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.

Team Status Report for 9/21/24

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