Progress

This week, my primary work on Landhopper consisted of helping with our field test in Schenley Park. I did the data processing afterward: using QGIS, I created a visualization of Landhopper’s logged path and our “ground truth” path, along with circular markers to demonstrate the difference between the two:

Aside from the field test, I helped with our final assembly and finishing up our slides for the final presentation. Aside from those, I have not had time to work on the project due to this being a huge crunch week for Computer Architecture.

Pacing and Planning

I’m on track with my tasks: we’re going to start on the poster and paper ASAP and I plan to make sure we have a better time with typesetting the paper this time compared to the design report.

Progress

Over the past 2 weeks, most of my work pertained to our final PCB: I finished routing the board, did a design review with Carson, ordered the boards, and worked with Twain and Carson to assemble the board. Here’s what the back of the board looks like in KiCad vs real life.

In addition to the PCB design, I did most of the CAD for our initial case design.

Learning

This project has been a huge learning experience for me: nearly every component of the watch which I’ve contributed to has led to me encountering something new. For example, many of the components on our final PCB were not built-in to KiCad’s libraries, so I needed to create custom footprints for them. While I’d used KiCad’s footprint editor before, it wasn’t until this project where I really got adept at creating and customizing footprints. On the firmware side, I learned far more than I wanted to about how to safely manage peripherals in Embedded Rust, in order to integrate several of the libraries which we’re using.

Pacing and Planning

Pretty much the only tasks remaining on the design front are finalizing our case and finalizing our firmware: Carson’s mostly been doing the mapping-related stuff, but I would like to improve our time handling and add some nice-to-haves like alarms. However, there’s also some non-design tasks which need our attention too, such as the looming presentation and reports. Tomorrow I will focus on making sure we have gathered all of the data we want for our final presentation, and over the next week I plan to come up with a solution for how we’re going to typeset our final paper: for our design paper, our final cleanup and typesetting turned into a torturous fight against Google Docs’ layout engine, so I’d like to find something better.

Progress

This week, in the run-up to our interim demo, Carson and I got the SD card and location logging working. I used QGIS to put together this very neat visualization of our first logging test: the size of each dot indicates the detected accuracy of GPS fix, and the color indicates time (blue->red).

For the GPS accuracy test, I should be able to use QGIS to generate a visualization of the deviation of Landhopper’s detected position from our “known good” RTK-GPS signal (from the U-Blox ZED-F9P which we’ll borrow from Roboclub).

Planning and Pacing

I’m pretty on pace currently. With Carson’s help, I finished pretty much everything I wanted to get done this week. For next week, the plan is to get the final PCB design done as soon as possible, since that’s the most time-critical part currently pending  which a whole load of stuff depends on (design -> manufacturing -> assembly -> debugging -> testing). Best case is I get it done tomorrow or Monday, but that’s pretty tight since I also have CompArch homework pending. Here’s what I’ve gotten done on the layout so far, though!

Progress

This week was yet another firmware refactoring adventure, this time in pursuit of getting the SD card working. The reason this required refactoring was because of how Rust handles sharing of objects, specifically sharing the SPI interface handle. Previously, the entire SPI bus was a single struct which was solely owned by the Display struct, but the issue is that this provides no way for the display to share the SPI bus with the new SD card handler, which also needs to use the same bus. The solution to this comes in the form of a whole lot of refactoring: Carson ported the hardware abstraction library to a newer version of the standard HAL interface which will allow (somewhat clunkily) sharing the SPI bus, and I began working toward integrating this with our code, which ended up requiring modifying several of the libraries we use (the reason for this mostly boils down to the libraries using an old implementation of Mutex which had been superseded).

Planning + Pacing

Tomorrow, the plan is for me to work (possibly with Carson) on finally getting the SD card working. I don’t have any other homework urgently pending so I think this is totally doable to get it done by the interim demo. Adding the SD card will allow us to demonstrate location logging and dynamic map loading: those features should be straightforward to implement once the memory card itself works.

Progress

This week, I helped Carson and Twain assemble our dev board (I mainly did the through-hole components), and spent a while working with Carson to get that board working as well as our breadboard prototype. I also worked on getting our microcontroller’s real-time clock working, and got it to the point where we have a working clock and calendar but was unable to get the wakeup timer working… this should be fine, but it’s a bit irritating (the library we’re using follows the wakeup timer initialization routine listed in the manual to a T, but it loops endlessly waiting for something to start).

Also, I worked with Carson to get a very basic map drawing program working! This uses data we processed from OpenStreetMap, and uses the standard Web Mercator map projection. The projection of the lines from lat/lon into Web Mercator coordinates happens when we process the raw data, and then the watch just transforms this to screen-space coordinates. Currently the map data is just stored in flash, but this is temporary (I’m gonna get the SD card working soon)

Pacing

I’m about on pace.

Planning

Next week, I want to improve the mapping mainly: goals are getting the map to center on the current location (and show a marker), and get the SD card working for logging and loading map data.

Progress

This week, I mainly focused on improving and refactoring our existing firmware code. The core of this was additional improvements to the serial handler: as it’s the only communication channel with the GPS, I want to make sure that channel is as simple reliable as possible. I had several frustrations with the implementation of the channels implementation we previously used for the UART communication… the most severe of these was the fact that it provided no way of “pending” (triggering) the UART interrupt handler while writing a buffer, which is necessary in order to actually get the chip’s UART to transmit from the buffer. To solve this, I worked with Carson to totally re-implement the ring buffer-based channels that are used to communicate between the UART handler and the GPS task. The new implementation provides a clean asynchronous interface to the channel which allows me to move more of my lower-level boilerplate logic out of the main code.

Pacing

I’m a little behind now, since I was planning to start on the mapping this week. However, with the overall codebase improvements I made this week I think that task should go smoother now.

Planning

Next week I plan to finally take my first stab at the map interface, and also to work on improving the firmware’s date/time handling.

Progress

Over the past 2 weeks, I’ve made a huge amount of progress on the firmware. I created a proper watch UI which displays the time and location, and I did a very rough preliminary test to see how quickly the device acquires a GPS fix after a cold start: in my testing, it was around 10-20 seconds, which is even better than the datasheet claims. After doing that, I implemented a proper buffering solution for the serial data, and expanded the capabilities of the GPS configuration system by rewriting the packet generator.

Pacing

I’m around on schedule for my tasks. Our original schedule had me not really working on the firmware for a little while after getting it to the state it’s at, but I enjoy adding features so I will probably work ahead while also working on the originally planned tasks.

Planning

This upcoming week, I plan to work with Carson and Twain to ensure that our PCB design is finalized and ordered, and then to start on the minimal street map that we plan to have displayed.

Progress

This week I finalized the barebones breadboard prototype of the GPS watch: a lot of the time was spent on debugging the UART failing to connect (the issue was that the baud rate I configured the GPS to had been reset, as the GPS doesn’t actually have persistent settings). In the end, we have a GPS setup that’s printing the coordinates out to the screen!

Pacing

I’m about on pace for my tasks: by the end of this week I was scheduled to be done with the firmware needed to get GPS data on the screen, which is what I’ve done.

Planning

Next week I plan to work on more of the firmware functionality, mainly the timekeeping via the RTC. I’ll also help Carson and Twain iterate on the energy harvesting after the success we had this week with the motor-based design.

Progress

This week, I made more progress toward writing the boilerplate firmware needed to get the microcontroller to communicate with our various peripherals. This includes another pass at the SPI transaction handling for the display, and a preliminary serial setup for receiving GPS data.

Here’s a screenshot of my newly rewritten function for efficiently updating the display by sending only changed lines:

Pacing

I’m a bit behind schedule in terms of producing our actual prototype board, but I have at least shown the fact that the various hardware we’ve been planning to integrate will work together, which was needed in order for Carson to start designing the board schematic.

Planning

Next week our GPS module should arrive, so I can actually properly do GPS integration rather than sending test data. After that point, I should finally be done with our “breadboard prototype” step, at least in terms of firmware.

Earlier this week, I worked with my teammates to review possible paths to follow for our energy harvesting design, and also worked on composing a purchasing list for our initial prototypes.

Later in the week, I started working on the breadboard prototype for the watch, along with the firmware: most of this time (around 9 hours) has gone into setting up our build environment and debugging the peripherals we need to use in the firmware. So far the display is implemented, and I’m also currently working on the UART for the GPS and the real-time clock. I am a little bit behind schedule as we had originally planned for me to finish with the breadboard prototype this week, but we’d failed to account for when we’d be able to order parts. However, I don’t think this should be an issue since I’ve been using my time to get ahead on the firmware (my task for next week), and progress should be faster on said firmware with Twain helping next week. Once the remaining parts we need for the breadboard prototype arrive (mainly the GPS), it should be pretty quick to finish the prototype (the wiring is pretty much just a few UART lines) so we can start testing the power systems.