Posted on

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.
Posted on

Sharon’s Status Report for 10/5/24

WORK ACCOMPLISHED:

Technology Decisions:  I decided to proceed with React Native for our mobile app, despite having to learn it, instead of using the Bluefy Browser, which offers BLE functionality but has limitations like no background running and requiring an additional app download. Although Bluefy would have been faster to implement, it posed too many unknowns and potential problems in the long run. React Native, on the other hand, has better BLE support, and though it involves some learning, it’s a well-documented and familiar technology for our team. I also debated using Flutter since it could offer more efficiency, but given my experience with React JS and TypeScript, React Native would be better and the advantage that Flutter offered was a higher efficiency of loading the app and its components.

GitHub Project Setup: This week, I set up the GitHub repository for our SkateBack project, creating an organized folder structure to manage the code. I also configured the necessary dependencies and environment for the project. I added a .gitignore file to exclude unnecessary files like node_modules/ and log files, ensuring the repository stays clean.

Project Environment Setup:  I researched the best tools and frameworks for our project and decided to use Expo for React Native, which eliminates the need to deal with both Android and iOS native configurations. I spent some time playing around with the Expo app example (still in the repo) to get familiar with its structure and capabilities. I also ensured all necessary tools, including Node, Watchman, CocoaPods, and the Xcode Simulator, were installed and configured, making sure all versions were compatible. I ran into a few compatibility issues that required specific versioning:

  • Tailwind CSS had to be downgraded to version 3.3.2 for compatibility with Expo.
  • TypeScript was adjusted to version ~5.3.3 to align with Expo’s requirements.
  • Updated expo-module-scripts to resolve a missing tsconfig.base error.
  • Had to use Node Version 20.

Initial UI Implementation:

I made progress coding the foundational UI components based on the Figma design:

  • Finished the welcome screen for pairing.
  • Created the initial layout for the remote control (without battery and gauge components).
  • Developed the interactive map for the ‘Return to Me’ page, with distance calculations included and a recenter button.
  • Completed the layout for the stats page with predefined values.

Parts List:

  • Helped find some parts and submitted the ordering form!

PROGRESS:

With the GitHub setup and project architecture finalized, I am on track with the tasks outlined for this week. The UI layout is progressing well, and I’ve begun implementing key visual components, such as the interactive map, stats page, and control interface. I had to push back coding the backend a little more but will still be on target. The schedule is below for my progress (my tasks are colored in orange):

 

NEXT WEEK’S DELIVERABLES:

Next week, I aim to complete the following:

  • Continue coding the remaining UI pages and components specifically finish the remote control. Also, need to make the rest of the connection pages as well.
  • Refactor the code to make it more reusable especially for the coming pages.
  • Start working on the backend and integrate functionality to the buttons.
  • Hopefully, we can start integrating the BLE functionality and connecting the Raspberry Pi to the app since we are waiting for that part.
Posted on

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.

Posted on

Sharon’s Status Report for 9/28/24

WORK ACCOMPLISHED:

Figma UI Design:

  • Completed the UI design for the SkateBack web app, focusing on skateboard connection, control interface, and the real-time data display.
  • Prototyped the design in Figma to visualize the app’s flow, making it easier for my teammates to understand how each component functions and how users will interact with the app.
  • Incorporated feedback from my teammates to ensure the design is functional and user-friendly (Figma feature to make comments directly on the UI interface).

Parts List:

  • Helped in finding more cost-effective alternatives for parts to save room in the project budget for additional purchases.
  • Looked into the feasibility and cost of 3D printing components using our school ($0.48/g)–considering buying our own filament as a cheaper alternative.
    • For two trucks, it would be around 200g-300g ($96-$144).
    • Buying own filament and printing it ourselves costs around $0.03/g (>$6).

Discussions: We found that BLE isn’t supported on iOS devices to be able to connect the web app to the Raspberry Pi and we would need extra Bluetooth module hardware to do so, so we’re exploring two alternatives:

  • React Native: Would support BLE but requires learning the language.
  • Bluefy Browser: Offers BLE to connect Pi and webapp without extra hardware but doesn’t run in the background and requires an additional app download.

React Native is more integrated but slower to implement, while Bluefy is quicker but has limitations like no background functionality so we are still considering which option to go with.

PROGRESS:

I’m currently on schedule with the tasks for this week since the Figma UI mockup was finished and reviewed. As for the project environment, it was extended to next week when coding starts since we had some obstacles detailed above and had to mitigate. The schedule is below for my progress (my tasks are colored in orange):

 

NEXT WEEK’S DELIVERABLES:

Next week, I aim to complete the following:

  • Set up the project environment, ensuring all necessary tools, libraries, and dependencies are properly configured
  • Define the project architecture and establish the initial frontend of the web app, laying out the skeleton of the UI.
  • Begin coding the UI components, focusing on building the visual elements like buttons, sliders, and real-time data displays, without implementing any functionality at this stage.
Posted on

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
Posted on

Sharon’s Status Report for 9/21/24

WORK ACCOMPLISHED:

Requirements Document: I compiled a comprehensive requirements document that outlines the functionalities for the skateboard control and real-time data components of the web app. I detailed the design, functionality, data sources, and any additional features for the following:

  • Skateboard Control:
    • Designed buttons and sliders for Accelerate, Decelerate, Reverse, and Recall features.
    • Included considerations for visual feedback such as acceleration curves, braking indicators, and pathfinding warnings.
  • Real-Time Data:
    • Designed the UI for battery life, speedometer, trip details, and environmental impact metrics.
    • Outlined how data is retrieved from hardware components like the Battery Management System, GPS, and motor encoder.
  • Connection Page Design:
    • Created a section for connecting the skateboard to the app via Bluetooth/Wi-Fi, including a flow for scanning and selecting devices, displaying connection status, and offering auto-reconnect functionality.

UI Design:

  • Started designing the mobile UI for the web app in Figma.
  • Focused on mobile-first design since the app will be primarily used on phones.
  • Began thinking about how to create a fluid design that works smoothly on mobile but doesn’t break on desktop screens.

Discussions:

  • Talked to group members about having a simple backend server to store user data–keeping this optional for now.
  • Discussed the feasibility of designing and laser cutting the CAD of a skateboard deck in terms of budgeting and if it is the most financially smart decision for us compared to buying a premade one.

PROGRESS:

I’m currently on schedule with the tasks for this week. The requirements gathering was completed within the expected timeframe, and I was able to start on the initial UI design to which I have a clear plan for the next steps, which will involve finishing and refining the design. The schedule is below for my progress (my tasks are colored in orange):

NEXT WEEK’S DELIVERABLES:

Next week, I aim to complete the following:

  • Finalize the UI design for the mobile web app. I’ll refine the Figma design, adding more details and interactivity to better visualize the user experience. I will aim to make a prototype that we can use to see how the connections and flow of the web application will be.
  • After completing the design, I will ask for feedback from team members and adjust the UI based on their suggestions to ensure usability and functionality.
  • Set up the project environment for the web app. This will include configuring the development environment, installing necessary dependencies, and establishing version control.
  • Start coding the frontend for the web app and creating the simple components and setting up all the pages as well.