Posted on

Team Status Report for 27 April 2024

Progress

Earlier this week, we did the final assembly of the watch and brought it out to Schenley Park to do a field test:

Apart from this field test, all of our team members have been occupied with other obligations and courses wrapping up this week. We have no new risks, and no major design changes have been made.

Testing recap

We’ve done quite a few formal and informal tests throughout the development of Landhopper. Aside from our continuous basic testing of the device’s operation indoors while developing its firmware, we often made quick excursions out of the lab in order to check the GPS behavior. These were done at various times of day, and in varying weather conditions (in the first photo below, it was raining, so we placed the development board in a plastic bin to keep it dry). These tests were very informal (we rarely recorded our results other than taking photos) but they proved to be extremely effective for iterative testing of our code: we caught many, many GPS and battery-related bugs this way.

Besides these very informal tests, our formal tests were more diverse: for example, the characterization of our motor power source was one of these, and from the test we found that while mechanical energy harvesting with a motor is definitely viable energy wise, it would take much more iteration to produce a version that is small enough to fit in a watch. This confirmed our choice of the solar panel as our power source, so no design change was made as we had already designed much of the watch with a solar panel in mind.

Our aforementioned Schenley Park field test was looking for several pieces of information: how accurate our GPS logging is, how reliable our SD card saving and loading is, and how long our battery lasts. From the test, we found that our GPS logging accuracy and capacity is within our requirements and that our SD card loading works correctly and quickly. We discovered after the test that we had accidentally set the GPS to log more often than we had intended to, which definitely affected our battery life results, but accounting for this error mathematically we determined that our battery life should still meet our requirement. Design wise this test resulted in few changes, as it mainly served to confirm our requirements; however, it did lead to us correcting the GPS log interval,  along with determining that our GPS antenna should be placed on the side of the watch in such a way that it faces the sky when the user’s arm lies completely slack.

Our comfort test is our next planned formal test. We have not been able to run the test yet, but we plan to have several participants wear the watch in several environments and answer a questionnaire about it. This test will serve to check our weight and comfort requirements and also to inform any final changes to the design of the watch’s case.

Posted on

Carson’s Status Report for April 27, 2024

Progress

This week we put together the wearable version of the watch, including support for SD card point logging, map loading, and time display, and tested it on a walk through Schenley. The test went very well, though the GPS sample rate was much too high and there were a few occasions where the GPS returned a very incorrect sample point.

However, several things notably went very right:

  • The map was seamlessly loaded from the SD card as we walked, keeping our location at the center of the screen and showing nearby paths
  • The logging of the path worked, and we were able to plot the points later.
  • The watch felt fairly comfortable and stayed on the wrist even while trying to step carefully over mud, jump across rocks on a stream, etc.
  • The battery was charged from the solar panel and appeared to remain constant while in the sun.

Unfortunately, that was the only task I could manage this week due to traveling for another event.

Pacing

Most of the main functionality is worked out; though we have a lot of things to do related to the documentation (video, poster, etc).

Planning

Next week we will finish the poster and the video.

Posted on

Gary’s Status Report for 27 April 2024

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.

Posted on

Twain’s Status Report for 27 April 2024

Between last and this status report, I helped with the comfortability survey. I also started to work on the final presentation poster and the final report.

My progress is on schedule. Next week, I will finish the final design report and poster before they are due.

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