Posted on

Jason’s Status Report for 10/26/2024

WORK ACCOMPLISHED:

This week I focused on starting the assembly of our parts. I soldered bullet connectors onto our VESC to allow it to connect to the motors. I soldered the VESC to the anti-spark switch which connects to our power button and prevents surging when the battery is initially powered on. I soldered the anti-spark switch to an xt60 connector which allows us to connect to the battery. Ultimately, we were able to power on the VESC, making a huge progress step for us.

PROGRESS:

We are slightly behind on tasks but should be able to make significant progress this week. I have been slightly delayed by one part taking longer than expected to arrive but have been preparing in the meantime. The next steps are to test the python code I have written on the VESC. Currently, I am blocked by a part that connects the motors to the VESC and thus I am unable to presently test the Pi-VESC communication.

NEXT WEEK’S DELIVERABLES

The missing part is expected to arrive this weekend. When it does, I will begin testing and tuning the Pi code. Next week, I expect to be able to control motors from the webapp and begin setting acceleration curves in preparation for mounting on the board.

Posted on

Tio’s Status Report for 10/26/2024

WORK ACCOMPLISHED:

This week, I focused on getting the Intel RealSense L515 LiDAR operational. Due to the product being discontinued, I faced challenges with outdated documentation. However, I was able to resolve these issues by installing RealSense SDK v2.50 and pyrealsense module v2.54, which are the latest versions compatible with the L515.

I also wrote a Python program to detect obstructions by raising a signal when a configurable percentage of the LiDAR’s view is blocked within a certain distance. These parameters will be fine-tuned during integration testing to ensure reliable object detection. In addition, I assisted Jason with soldering the battery, VESC, and power switch connections, contributing to the hardware assembly process.

PROGRESS:

I am on track with my tasks for the week, which focused on object detection using the LiDAR. However, I still need to migrate the LiDAR code to the Raspberry Pi environment, which will be a priority moving forward.

I haven’t been able to complete the motor functions for the board, because there was a slight delay in the arrival of one of our parts. The board has not been fully assembled yet.

NEXT WEEK’S DELIVERABLES

  • Set up GPS data collection on the Raspberry Pi.
  • Begin testing the return algorithms once the board is fully assembled, integrating LiDAR data for autonomous recall.
  • Complete the migration of LiDAR code to the Raspberry Pi environment to ensure seamless operation.
Posted on

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.

Posted on

Sharon’s Status Report for 10/26/24

WORK ACCOMPLISHED:

Bluetooth Functionality and Raspberry Pi Integration: This week, I focused on integrating Bluetooth functionality with the Raspberry Pi, which involved several setup challenges. Without an HDMI cable to connect the Pi to a monitor, I had to set it up headlessly, reimaging it with a specific network to enable SSH access. Once connected, I configured the Pi’s Bluetooth by enabling and testing it, then moved to set up Bluetooth on the mobile app. This required installing specific libraries and creating a BLE manager, which allowed the app to discover and connect to the Pi. Since Expo Go doesn’t support BLE, I had to split the native code for both Android and iOS, setting permissions accordingly.

On the Pi, I established a systemd service to automatically enable Bluetooth at boot, ensuring the Pi is always discoverable. After extensive testing, I successfully confirmed the app could reliably connect to the Pi. This milestone establishes a solid Bluetooth connection foundation, preparing us for future functionalities, including real-time controls.

Backend Preparation and Testing Setup: To prepare for backend integration, I continued organizing code for modularity and responsiveness, particularly for features that will connect to backend functionality. While full backend development remains pending, I focused on structuring the app’s Bluetooth connections and streamlined code for compatibility with the upcoming Raspberry Pi and mobile app control interfaces. I also started to make the API endpoints so that when my teammates are ready to connect everything system wise, they have an app to test with and connecting these two systems.

Raspberry Pi Setup: I worked on setting up the Raspberry Pi and making sure that the Github repository was on the Pi so that all my teammates can work on it without disrupting each other’s work and also be able to commit their work to Github from the Pi and so that there wouldn’t be any lost work and we are all able to see each other’s work on the Pi as well. I think something we could possibly setup is remote ssh on the Pi since only some team members need physical access to the Pi and others like me only need the remote capabilities of using the Pi to test software wise.

Code Refactoring: With this setup complete, the app is functionally ready for initial Bluetooth control testing, even though backend development is ongoing. I refined various elements across the app, particularly responsiveness and UI adjustments to enhance cross-device consistency. A systemd service ensures Bluetooth functionality on the Pi is seamless, and connection flows on the app are now stable. I also spent time refactoring code for future maintainability and responsiveness improvements.

PROGRESS:

Overall, I’m on track with Bluetooth integration, and the core Bluetooth connection functionality is operational. I overcame challenges with the headless Pi setup, expanding skills in network-based configurations and system services. While backend work has been delayed and I have been working on it still, foundational steps for future app and Pi interaction are complete, including BLE manager setup and systemd service automation. This enables us to move forward with Bluetooth-based features as scheduled in our Gantt chart. My next steps focus on backend setup and enhanced functionality for a polished user experience.

NEXT WEEK’S DELIVERABLES:

Next week, I aim to complete the following:

  • Finish setting up the API endpoints for button control and defining the acceleration curve as well by speaking with my teammates.
  • Once my teammates have been able to control their specific parts, I need to set up WebSockets and the backend on the Raspberry Pi to get the streamed data onto the app.
  • There’s some things that still look a tiny bit off on different screen sizes so need to make more dynamic.
  • Continue improving the visuals and animations for a more polished user experience.
Posted on

Jason’s Status Report for 10/19/24

WORK ACCOMPLISHED:

I dove back into VESC software and realized we may not be needing it but will likely instead be replicating the functionality. 

One crucial component when using VESC software is motor configuration. Above is a screenshot of the VESC software. When setting up the VESC with this software, we are setting important things such as Voltage Limits, Current Limits, Motor RPM Limits, Temperature Limits, Motor Tuning, Startup Boost, and Regenerative breaking. In the absence of a VESC, my plan to tackle each of these is as follows:

Voltage Limits/ Current Limits: We will calculate our battery and VESC’s voltage limit and place ceilings on the speed of the motors relative to the cap we impose to make it physically impossible to exceed our limits, even at maximum motor speed. In the case where this is not possible or does not prove to be effective, we will add external current-limiting circuits with a current/voltage sensor.

RPM: We will use Hall sensor data to keep a close watch on the RPM and throttle if we exceed a certain limit we will impose. This can be done through RPi packages.

Temperature: Similar to RPM, our hall sensors will allow us to understand the temps of our motors at any given time. We will have a circuit-breaker esque trip system that will cause the board to slowly come to a stop if we exceed same measurements.

Motor Tuning: We will likely have to measure the motors with an LCR to determine the resistance and inductance to help define how we will set our acceleration curves.

Startup Boost: When in the initial phase of the motor, we will supply slightly extra current to avoid dead-stop stalling.

Regenerative Breaking: We will not be incorporating this feature.

 

PROGRESS:

I am on track with my goals as set out by the Gantt chart. I am somewhat blocked in waiting for the VESC to arrive to begin applying the theory and ideation to a practical and testable environment to begin making adjustments as necessary. When we return to school, I will be able to work on this in a much more effective and efficient manner.

 

NEXT WEEK’S DELIVERABLES:

  1. Assemble as much of the board as possible.
  2. If the VESC is here, begin running tests and playing around
    1. Specifically decide concretely about UART vs PWM.
  3. Ensure we are able to read data from the Motors and send it back to the RbPi.
Posted on

Tio’s Status Report for 10/19/2024

WORK ACCOMPLISHED:

The initial parts required for SkateBack have been procured. Before the break, I picked up key components we ordered from the course inventory, including the Intel RealSense LiDAR Camera L515, Raspberry Pi 4, and the SparkFun GPS-RTK Dead Reckoning Breakout (ZED-F9R).

I began the initial setup for the Raspberry Pi 4. Additionally, I tested the LiDAR sensor on my desktop computer and installed the RealSense software on a Windows device to familiarize myself with its operation. I also explored how to run the Intel-provided SDK in a Linux environment and reviewed sample Python code to understand how to interface the LiDAR with the Raspberry Pi effectively.

Unfortunately, I was unable to test the GPS module as the required antenna and connectors to interface it with the Raspberry Pi or other computers are still pending. However, this hasn’t affected progress, as I have continued studying GPS operation and preparing code frameworks to interface with it once the missing parts arrive.

Additionally, we finalized most of our system design in the design report, which now serves as a critical reference document moving forward. The decisions documented there will guide component integration and help align all team members on the project’s direction.

PROGRESS:

I am currently on track with my tasks for the week, focusing primarily on setting up the Raspberry Pi environment and experimenting with sensor data collection. The initial tests with the LiDAR have provided insights into its data streams and will inform the next phase of development.

Moreover, I received notification that additional parts from our order have been delivered. This will allow us to begin assembling the physical skateboard and integrating components next week. With more hardware in hand, the team can shift attention toward building the board and testing individual subsystems.

NEXT WEEK’S DELIVERABLES:

My deliverables for next week are as follows:

  • Test data collection from the sensors (GPS and LiDAR)
  • Define a library of motor functions for the motors
  • Work on sending object presence to the Raspberry Pi
  • Work on the back up algorithm for obstacle avoidance
Posted on

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.

Posted on

Sharon’s Status Report for 10/19/24

WORK ACCOMPLISHED:

UI Layout Finalization and Enhanced User Experience:  

This week, I finalized the UI layout for all the key pages in the app, with a particular focus on setting up the connection flow. Now, users can seamlessly navigate through the process of pairing their skateboard, selecting devices, and managing connection success or failure.  The connection pages are fully designed and functional, including the welcome screen, device list, search, and both success and failure outcomes. For this, I just used mock data for now. I also added animations to enhance user interaction, making the overall experience smoother and more intuitive. With these components in place, the frontend is now in a solid state, ready for backend integration. The UI is responsive and visually polished, laying a strong foundation for future development. 

Additionally, I implemented a progress bar animation for the “Return to Me” feature, providing real-time feedback as the skateboard gets closer to the user. I also added a warning visual to alert the user if the skateboard is more than 5 meters away, enhancing the safety and usability of the feature.

Stats Page and Calculations: On the stats page, I calculated the equation for CO2 saved to provide users with meaningful feedback on the environmental impact of using the skateboard (the average passenger vehicle emits about 400 grams of CO2 per mile). This data is visually represented to engage users in tracking their sustainability contributions.

Remote Control Enhancements: The remote control page was improved with the addition of battery calculations and a corresponding visual to show real-time battery levels. I adjusted the battery percentage visuals to ensure accuracy and readability, which is critical for the user experience.

Responsive Design: To ensure the app looks good across different devices, I adjusted styles to be more responsive to various phone sizes. I also refined the tab bar styles, making navigation more user-friendly.

PROGRESS:

I’m on track with the progress made this week, particularly in finishing the entire UI/UX with animations, real-time feedback, and responsive design. The core layout for the remote control is complete, and I’ve laid the groundwork for future BLE integrations by refining the connection flows. Since I haven’t had the chance to work with the Raspberry Pi yet, it has pushed back my schedule for Bluetooth connectivity and integrating it with the mobile app. However, I have set up the proper libraries and will try testing it with mock data for now. Also, backend coding is still pushed but still debating the necessity for that. Also, for our gantt chart, we didn’t take into consideration that we had fall break and we were only going to complete additional tasks during that week if necessary. The schedule is below for my progress (my tasks are colored in orange and my shared tasks in yellow):

NEXT WEEK’S DELIVERABLES:

Next week, I aim to complete the following:

  • Finish integrating BLE functionality and begin testing with the Raspberry Pi.
  • Start coding the backend for the skateboard control interface.
  • Continue improving the visuals and animations on the control and stats pages for a more polished user experience.
  • Refactor code as needed to prepare for backend integration. Also, refactor the code to make it more reusable and responsive. There’s some things that still look a tiny bit off on different screen sizes.
  • Test the GPS module on react native.
Posted on

Jason’s Status Report for 10/5/24

WORK ACCOMPLISHED:

Part list changes: We elected to convert from our existing GPS IMU selection here: https://www.sparkfun.com/products/16329 to this one: https://www.sparkfun.com/products/22693.  The course staff chose to buy this and it outperforms our old pick significantly. The last option provided 2.5 meter accuracy and the new one is 0.01 meter accuracy, which allows us to meet our user requirements. The only consideration here is that the data output is slightly different so we will have to adjust our method of processing. This also frees up more budget to allow us to get closer to the $600 mark. We also swapped to a new LiDAR that the course staff provides. The new LiDAR does not connect directly to our Qwiic parts so we will be swapping to a USB-C to connect.  This also saves us significant budget.

We also solidified a number of connections and finished ordering parts. Once the parts arrive, we will be able to further solidify the designs. I plan on tinkering with all the parts in the lab to get a better understanding of how each one works and the data output we can expect from each one. The finalized parts list is here: https://docs.google.com/spreadsheets/d/1ouYsHj6s2zO1oddGNwvI4KCI4vJLrQ7ma_3bCsAnZ94/edit?gid=0#gid=0

The last major design change was a transition to a external battery pack to power the Raspberry Pi. We are concerned about splitting power from the huge pack so we are using an external pack. We could not find a 5v/5a external pack so we converted to a Raspberry Pi 4 instead of 5 to make it more accessible for common power packs. The only concern here is we will have to drill an additional hole in the enclosure to allow for charging. In addition, having 2 chargers is a little bit of an inconvenience.

I also did a preemptive diagram of all of our connections and the ports to ensure each one is compatible and able to transfer the data and power that we need.

PROGRESS:

I am on track on progress despite taking longer than expected to finalize the parts list. We went through a number of iterations including frequent group meetings, a meeting with Joshna, and frequent discussions with professors after class.

 

NEXT WEEK’S DELIVERABLES:
The next step for me is to receive the parts and start piecing things together to get closer to the final product. I will continue to help my team with app design, LiDAR sensing, and GPS mapping. The biggest task next is to figure out the autonomous steering mechanism and the communication method between the RbPi and the VESC. Before the parts arrive, I will familiarize myself with the open source VESC software to be prepared to jump in when all parts are here.

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.