Posted on

Gary’s Status Report for 20 April 2024

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.

Posted on

Team Status Report for 20 April 2024

This week, we acquired the final PCB, soldered all of the parts onto the board, and created the case for the watch so that it is wearable. We did more work on the firmware as well, adding the ability to load map data from the SD card on the fly. Aside from our design tasks, we also created our final presentation for next week.

We have no new risks that we are worried about, nor are there any changes we have made to the design of the system.

Posted on

Twain’s Status Report for 20 April 2024

Between last and this status report, we got our final PCB layout, and I put solder paste onto the board and then used the pick and place machine to put all of the small pieces onto the board, as seen in the last attached picture. Additionally, I worked on the final presentation.

My progress is on schedule. Next week, I hope to finalize the watch and work on the final design report and poster.

Through this project, I have found myself needing to learn how to program in Rust better than I could before, and I used the Rust documentation and my friends who know Rust to learn it better. I learned more about designing hardware systems, which was mostly through my teammates, as well as some online resources. I also learned how to use the pick and place machine just this past week, which I figured out through the help of my teammates and a bit of experimentation. Throughout this project, I made much use of my human resources, ie friends of mine who had more experience than I did with the various aspects of my project, as well as online resources such as forums and videos online.

Posted on

Carson’s Status Report for April 20th, 2024

Progress

This week, I got numbers on the energy output of the motor, and we assembled the final watch.

After many difficulties trying to get the tolerances correct and having to adjust the gear ratio, I finally was able to attach the motor to my arm and collect data on its energy output. The data was very noisy due to the imprecision of my own motion, and I could only record for short periods of time due to the fact that I could not find the set of ball bearings I needed to keep the two halves of the gearbox in line. However, when the parts were aligned correctly, it swung very well and yielded 1-2mW of power output at what felt like a running pace. This is comparable to the power output of the paper we were referencing; the 50% loss in efficiency is likely due to problems with my mechanical design. With some refinement, this means the motor could be a viable energy source for the watch. However, the main issue is size; the current gearbox is the same as the size of the entire watch body, and to get it smaller would require integrating the rotor, stator, and gears into a single custom assembly. This could be interesting for further research, but for now it just isn’t viable.

Just yesterday we were able to assemble the final revision of the PCB. I did some modifications to the case design to make the PCB fit, assembled a small “debug header” with pogo pins to program the new board, and also ported over our code to work with the new pin layout. Amazingly, everything worked:

Learning

Over the course of this project, I had to learn many new things: low power circuit design, gear manufacturing, GPS protocols, SD card interfaces, debugger setup…

Many of the “formal” aspects of implementing these ideas came from reading research papers and datasheets—in particular, this is how I would get equations, design parameters, and circuit layouts, for determining at a high level how I should accomplish a task. Then, inevitably, while trying to do most tasks I would find that the high-level overview leaves out several steps, or doesn’t quite work in practice. This then usually lead me to Google, where I pieced together forum and blog posts from people with vaguely similar problems  to see how I could solve my own. And, finally, I would sanity check my ideas with people I knew had knowledge–first my team members, and then my friends (in particular, it was quite hard to get mechanical engineering advice anywhere other than in-person).

Pacing

The only remaining item is the firmware, which is a little bit behind where I’d like it to be but is very much doable now that we have two sets of real hardware to test with.

Planning

Next week I will:

  • Implement actual menu navigation
  • Find a way to display the path the user has taken on the map
  • Determine if there’s an easier way to use the USB bootloader on our final PCB
Posted on

Gary’s Status Report for 6 April 2024

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!

Posted on

Carson’s Status Report for April 6th, 2024

Progress

This week I made the system fully energy-independent, able to power itself from its own battery. This involved a lot of tuning of the resistor values for the ADP5090 boost converter, to avoid accidentally setting the LiPo battery on fire. I also conducted some preliminary tests on how much energy we could harvest, and the results vastly exceeded my expectations. With a partially-overcast sky, the solar panel yielded about 0.6mA-1mA of current. This is already very impressive, consdering our quiescent draw of only 0.3mA. In direct sunlight, I observed up to 15mA of current from the panel, easily enough to charge the battery even with all the components active. This far exceeds any expectations we had of how much energy we could obtain, and gives us very strong evidence that we should use the panel.

Pacing

With most things working, we now just need to integrate the components into the firmware. This is taking longer than expected, but given that I have now completed my most time-intensive outstanding task (Robobuggy) I should much more time available to focus on finishing that up.

Planning

  • Confirm that the motor is not nearly as viable as the solar panel
  • Fix loading map tiles from the SD card
Posted on

Team Status Report for 06 April 2024

We have no new risks that we are worried about, nor are there any changes we have made to the design of the system.

We have run some tests on GPS location accuracy, walking around CMU campus in various conditions and testing to see how long it takes to get a lock and how accurate this lock is. For accuracy, we will compare Landhopper’s location fix against a known-good and known accurate position source, a U-Blox ZED-F9P (which we will borrow from Roboclub). The ZED provides very high-accuracy and high-precision RTK-GPS position fixes, accurate down to a few centimeters, so it is an ideal “ground truth” for comparison.

As for actual cases we will test, we want to experiment with various positions for the antenna on the wearer’s wrist to determine which results in the most accurate fix. Simultaneously, we hope to test the amount of battery taken to get a fix, as well as the amount used in typical usage by logging the battery levels along with each location store. We hope to be able to analyze both of these results in order to meet our use case requirements of a week-long hiking trip with high-fidelity tracking, by synthesizing the position data from Landhopper with the power consumption data and visualizing it with QGIS.

Through the course of the project, we have done much analysis to see what energy harvesting source we should use. Though we tried several times to figure out the best way to attach the piezo tiles to a metal band, they always popped off of the band when it was bent to the necessary curvature. We’ve gone through a few versions of the gearbox for the motor generator option, but all of them have either. At the current stage, we’re thinking of cutting our losses on the piezo option, but we’re still going to give the motor option one or two more iterations. If we get it to the point of generating any amount of useful power, we’ll definitely give it a proper comparison against the solar option by determining which harvests the most energy in both indoor and outdoor scenarios.

Solar harvesting is showing to be very fruitful so far: the 15mA we have achieved from full sunlight far outpaces the maximum power generation given in our referenced papers for the piezo and motor techniques (the most given was around 9mA). We will further test with different orientations and positions of the solar panel on the watch case (like with the antenna) to determine which results in the most power generation outdoors. We’ll visualize this data alongside the position and other parameters to make sure we’re meeting our planned requirements.

Posted on

Twain’s Status Report for 06 April 2024

Between last and this status report, I helped with attaching more pieces to the circuit board, and I also soldered together resistors to be fine tuned for our energy harvesting purposes.

My progress is on schedule.

Next week, I hope to help with the firmware more.

Posted on

Carson’s Status Report for March 30th, 2024

Progress

This week I was very busy with preparing Robobuggy for rolls, so I didn’t have much time to spend on this project. I mostly made some tweaks to the map and worked on updating the HAL (hardware abstraction layer) library we use to a later version so that it was compatible with the SD card library, so that we can start working on adding map tiles.

Pacing

We are somewhat behind on overall progress, but we have a really strong set of features for the demo. Fortunately we can have some asynchronous tasks (i.e. having the next PCB be ordered while we work further on firmware).

Planning

Next week we will do final preparations for interim demo (real energy harvesting numbers, demo firmware, etc).

Posted on

Gary’s Status Report for 30 March 2024

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.