Author: tajani

WORK ACCOMPLISHED:

The major milestone we crossed since our last status report was our interim demo. We showcased all our work so far, including our mobile application enabled manual control, and script controlled return with turns to avoid a mock obstacle. We also have all parts required for GPS-RTK, and will do some quick assembly before our final demo, but our return algorithm is already implemented.

PROGRESS:

We our entering the final stages of our project and our progress reflects accordingly. We’ve largely retired the LiDAR but hope to be able to demo it attached to a laptop as an intermediate between the device and the Raspberry Pi.

NEXT WEEK’S DELIVERABLES:

• Final Demo: We need to refine and prepare for what features we will show in our final demo to remain under time and have an effective demo
• Final Demo Slides
• Final Poster
• Final Report

WORK ACCOMPLISHED:

A lot of progress was made this week, and we can confidently say that we now meet the MVP we defined in our abstract: “A fully functional electric skateboard that is controlled by a web application. You will be able to accelerate, decelerate, and reverse all with just a phone.” Sharon was able to integrate the remote control app with the defined functions for controlling the skateboard, and we’ve been able to verify that the controls are smooth, responsive and intuitive.

I began writing the return algorithm, and worked with Jason to devise a control flowchart to help us with our implementation. While the general approach to its implementation remains unchanged, I am blocked by the inaccuracy of the ZED-F9R when it doesn’t use RTK. To try and rectify this Jason and I met with members of Roboclub for help. They gave us a parts list and some sample code we’ll need. I’ve placed the orders and in the mean time, I will continue as planned and finish the code for the autonomous return.

PROGRESS:

Now that we have reached MVP for our project, I am ahead of schedule for all my non-autonomous feature related task such as writing and testing the motor command class. For the autonomous operation related tasks, I am on track, as the next few weeks are dedicated to testing and revisions.

NEXT WEEK’S DELIVERABLES:

• Completing the return algorithm: The pseudocode and flowchart are laid out, all that remains is to write the code. This can be accomplished in relatively few work hours
• Integrating RTK supporting hardware: After consulting with Roboclub we received a list of additional hardware and software to integrate to get highly accurate reading with the GPS we already have via RTK.
• Validation testing: I aim to carry out some additional unit tests to verify the performance of my contributions to the project, namely:
  • Speed test: Accelerate and decelerate on varying terrain slopes, rider weight, and motor load. Speed should remain within 14-16 mph.
  • Return to Me Accuracy: Recall skateboard over varying distances (5m, 10m, 50m, etc.) with/without obstacles. Skateboard should return to user and be retrieved within 1-meter radius of users position.

WORK ACCOMPLISHED

This week marked significant progress in multiple areas of the project. I successfully achieved individual motor control by leveraging Python’s threading module, assigning each motor to its own thread for independent operation. To test this setup, I developed a simple interface that allows motor control using keyboard inputs to simulate signals from the skateboard’s remote control app. Additionally, I implemented an emergency stop routine to ensure the motors and VESC can be safely shut down in case of unexpected issues. I also improved the motor control logic by rewriting the command structure to support reverse motion, enhancing the skateboard’s maneuverability.

With individual motor control established, we conducted our first turning tests in the space between Scaife and TechSpark. Initial results were underwhelming, but after switching to a shorter deck and tightening the trucks, we achieved consistent performance. These adjustments provided the stability needed to proceed confidently with further testing.

Beyond motor control, I integrated functionality for reading GPS data from the ZED-F9R breakout module. I also incorporated a library to convert latitude and longitude coordinates into UTM (Universal Transverse Mercator) format, enabling path-planning calculations in meters on an x-y grid. This advancement will be instrumental in refining our return algorithms.

PROGRESS

While I am on track with my software-related tasks, the overall progress on path-planning and return functionality has fallen slightly behind schedule. This delay is due to several factors, including challenges with the LiDAR integration, underestimating certain technical hurdles, and delays in part deliveries. Despite these setbacks, our motor control system and GPS integration provide a strong foundation for the next phase.

NEXT WEEK’S DELIVERABLES

Next week, our primary objectives are twofold:

1. Integrating the remote control app: This will involve syncing the app’s signals with the motor control system. To facilitate this, I’ve prepared a brief README outlining the unique aspects of our motor control setup.
2. Initiating return algorithm testing: Using the GPS and motor control framework, we will begin testing the skateboard’s ability to autonomously return to the user.

These tasks will bring us closer to achieving the project’s core functionality and ensure we remain aligned with our overall timeline.

WORK ACCOMPLISHED:

This week, I worked with Jason on the VESC, Motors and Raspberry Pi.  We spent quite a bit of time debugging the connections between the Pi and VESC. Eventually we abandoned using the GPIO pins in favor of using USB connections. We will be writing the scripting for the motors using a conjunction of the PyVESC and serial python modules. In similar fashion, we plan to forego the Qwiic connectors and use a USB cable, UBlox_GPS, and serial to manage control the GPS.

We’ve achieved individual control over the motors, but we’re still trying to execute instructions simultaneously. I plan to use Python’s multithreading features to accomplish this.

The LiDAR is not yet fully operational on the Pi. Due to its Linux environment, we have to build the SDK from its source files rather than just installing it.

PROGRESS:

I am on track with my tasks for the week, which focused on defining a Python Class for the motors entailing all the methods we will be using to control the motors. We initially planed to have return completed by this week but that was an ambitious deadline that was set to leave extra cushion time towards the end. We can slightly relax our expectations, especially because the motor commands are taking much less time than anticipated.

In experimenting with the LiDAR I’ve found that its depth camera performs very poorly outdoors. It’s RGB camera is fine however, and already capable of identifying faces and outlining them in a red bounding box. This gave me an idea to propose relaxing our vision requirements to the recognition of a single object (e.g. a traffic cone) as a proof of concept. This is fairly easy to accomplish using opencv and a public data set for recognition.

NEXT WEEK’S DELIVERABLES

• Rewrite GPS data collection on the Raspberry Pi to use USB serial ports.
• Complete the migration of LiDAR code to the Raspberry Pi environment to ensure seamless operation
• Begin testing the return algorithms once the board is fully assembled, using LiDAR data to initiate brakes.

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.

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