WORK ACCOMPLISHED:
Part Changes: Accuracy Is Improving and Costs are Going Down –The two major milestones for this week were the design presentation and filling out the ordering forms for our parts. I gave the design presentation on 10/2 and it was well received. We also had our parts finalized by then so we filled out the ordering form after class. A few changes have been made to our design. The course staff have elected to buy an RTK-GPS breakout for the course inventory, and we will be using it rather than buying one with our own budget. The model they chose was one that we initially considered but was disregarded because at $289 it would’ve taken up close to half of our budget. The SparkFun GPS-RTK Dead Reckoning Breakout – ZED-F9R that we will now be using boasts far superior precision (0.01m horizontal accuracy with a correctional stream from a base station, one of which is located atop Hamerschlag Hall). Similarly, the LIDAR we will be using also has changed. Joshna picked out the Intel RealSense LiDAR Camera L515 from the course inventory which we had not previously considered. With these two part changes, we’re saving about $140, which solves our previous concerns of going over budget. One replacement that hasn’t changed our budget was transitioning from an RPI 5 8GB to an RPI 4 8GB. This was done because of the reduced power consumption demands of an RPI 4, and our decision to power the RPI and its accessories with a rechargeable power bank over USB-C. I think we can expect to begin receiving parts next week, which might allow us to get a bit of assembly work in before Fall Break.
The UTM Coordinate System – Another promising development this week was regarding the coordinate system I mentioned in my last status update. My idea to project longitude and latitude onto a flat x-y grid like system already exists in the form of Universal Transverse Mercator (UTM) coordinates. UTM works by dividing the world into a grid, where each grid cell has a unique identifier. A UTM coordinate consists of the grid cell identifier and the “easting” and “northing” within that grid cell. The easting (x) and northing (y) are in meters, and are relative to the southwest corner of the grid cell. For example, Pittsburgh is in UTM Zone 17T, and Doherty Hall (where I’m currently typing this report has northing: 4477403.01 and easting: 589501.46). After talking to a friend in CIA that works on the buggy’s RTK kits, I found a Python library that CMU Roboclub uses to convert GPS readings to UTM and vice versa. This is a big find, as I was worried that implementing our own grid system and conversions would be fraught with error.
Tracking the Rider via their Phone – This week I explored the different alternatives for determining the location of the rider that the skateboard the user will attempt to find its way back to. So far I’ve thought of two approaches:
- Using a Wi-Fi or cellular positioning via a geolocation API: When the user decides to start the “return to me” process, the webapp makes a request for the host device’s position using a geolocation API. There are a wide array of APIs available, varying in both precision and pricing, but I doubt any are as accurate as readings from a GPS chip which brings me to our next option.
- Leveraging the single GPS chip we already have: The basic idea is that the rider and skateboard share the same location whenever the rider is on the board, so if we could detect a separation event (like the rider falling of) by measuring an acceleration spike using the IMU embedded in the GPS breakout (similar to how HDDs can detect when they’ve been dropped), then we would use the GPS chips last read before separation as its return destination. This has its own limitations though. The user would have to stay where they fell and start the skateboard callback. And it would be limited by the accuracy of separation detection. Also what if you wanted to simply come back to you from somewhere you placed it?
Ultimately I imagine some combination of these two approaches will be best.
PROGRESS:
We are back on schedule now that we’ve order parts, and I expect we will begin receiving parts next week. We’ll be able to do some early unit assembly and testing once we receive the RPi, LiDAR and GPS. Even without those parts, I am currently working on the software that will go on the RPi such as location data parsing and collation.
NEXT WEEK’S DELIVERABLES:
I main target to hit next week is to begin work on assembling the board. This is ultimately dependent on when our parts get here, but any progress we make before fall break will be a huge plus. After fall break we need to hit the ground running if we’re hoping to meet the rest our deadlines.
I am a bit concerned about a few design elements that are still up in the air. Working on the design report due next week will help us to finalize these choices and have a single reference point during all the actual implementation that will follow after fall break.