Posted on

Eddie’s Status Report 2/21

This week, I focused on beginning implementation of the Extended Kalman Filter for our positioning system. I set up the filter structure in code, including the state representation, prediction step using IMU acceleration, and covariance propagation. I also started implementing the measurement update step that will incorporate celestial position estimates to correct inertial drift. Currently, I am testing the filter framework using simulated data to verify that the prediction and update steps behave correctly.

My progress is on schedule. The main goal for this phase was to begin coding the estimation algorithm, and I now have the core filter structure in place.

Next week, I plan to complete testing of the filter, tune the noise parameters, and prepare the implementation to accept real IMU and celestial solver data once the hardware is ready.

Posted on

Team Status Report 02/21

This week, we set up the Raspberry Pi 4 which we will use as our compute module for the project and presented our design proposal, connected the camera, and set up ROS on board to stream the camera frames. Our progress is currently being limited by the arrival of all other hardware, which has been delayed from DigiKey. In the meantime, we will continue with camera calibration and image preprocessing to be ready for when weather conditions are suitable to start capturing our first camera data for feature extraction.

Posted on

Julius’ Status Report 02/21

This week, I focused on bringing up the Raspberry Pi 4 we’re going to be using as the compute module for the project. I flashed Ubuntu 22.04, installed ROS2, and connected the IMX477 camera sensor via ribbon cable to the board. I then set up a ROS node for the camera where it is now publishing the raw captured frames at a configurable rate. I ran into unexpected challenges with flashing Linux onto the board with the RPi Imager which resulted in it taking more time than expected, but it is now configured.

Posted on

Rachel’s Status Report 2/14

This week, I focused on building and validating the core algorithmic pipeline for our celestial positioning system. I implemented star detection using preprocessing, adaptive thresholding, connected components, and centroid extraction on a stock starfield image. I then plate-solved the image using astrometry.net and integrated the resulting WCS file into our Python pipeline. The system achieved a mean angular error of approximately 0.0014 degrees, confirming that our detection and pose estimation steps are functioning accurately.

My progress is on schedule, as this week’s goal was to establish a working baseline registration and attitude estimation pipeline before implementing our own star identification method. Next week, I plan to replace the WCS-based labeling with a triangle-based star matching algorithm and validate that we can achieve similar accuracy independently.

Posted on

Team Status Report 2/14

This week, we focused on building the foundations of our approach across all categories. We have initial algorithms in place for sensor fusion from sensors and visual positioning fixes as well as a pipeline to extract features to produce a global position fix from the camera. On the hardware side, we have purchased all parts except from the mechanism that would allow the camera to rotate, and are awaiting their arrival. We are working on the design presentation next week, and are also planning to gather our first data for offline testing of visual feature registration this week while the weather is amenable to doing so.

A: Our celestial positioning system improves safety by providing an alternative navigation method in GPS-denied environments, where loss of positioning could lead to crashes or mission failure. By maintaining reliable localization for drones or autonomous systems, the design reduces risks to people, property, and surrounding infrastructure.

B: Our system addresses important social factors by increasing accessibility to reliable positioning technology independent of GPS infrastructure. Many existing navigation solutions rely heavily on satellite connectivity, which can be unreliable or unavailable in remote regions, wilderness environments, or during infrastructure outages. By providing an alternative positioning method using only onboard sensors and passive observation of celestial features, our system enables individuals and communities to maintain situational awareness even when conventional systems fail.

C: The system is being constructed with low-cost mass-production in mind. All components are off-the-shelf and widely available. The camera is cheaper by several orders of magnitude than those used on aerial systems historically for celestial positioning. The Raspberry Pi provides no hardware acceleration, and is thus easily swappable for other processors which meet the memory restrictions. The sensor suite is also non-specific to the module itself and can be swapped for more expensive or cheaper sensors, potentially at the cost of performance if cheaper.

A was written by Rachel, B was written by Eddie and C was written by Julius.

Posted on

Julius’ Status Report 2/14

This week, I focused on picking out hardware for the design and thinking through an interesting design problem that has already arose.

On the hardware side, I settled on an integrated IMU, magnetometer, and barometer module and a GNSS module to be connected on an I2C bus to the Raspberry Pi. The Raspberry Pi was chosen to have 8GB memory, which should be sufficient for the software tasks we’re planning to run onboard. I chose an IMX477 camera for the visual perception, as it’s similar to the camera used in the paper we are referencing.

Since our current plan is to have the camera rotating on the module, we need to know the relative angle between the camera and the module in order to fuse IMU data with the visual camera position fixes. In fact, the visual fixes could theoretically produce an accurate heading fix, but it is useless if we do not know the relative angle between the visually perceived heading and the drone. To this effect, I considered mounting the camera on a stepper motor with an encoder, though this is vulnerable to backlash and encoder quantization drift. I am currently exploring the possibility of having small fiducials along the periphery of the camera rotation hardware that the camera could track its angle relative to, and thus know its angle relative to the drone.

Separately, I am working on preparing the design review presentation.

Posted on

Eddie’s Status Report 2/14

This week, I focused on developing the estimation framework for our celestial positioning module. Specifically, I designed the structure of our Kalman Filter based state estimator and formalized the mathematical model for fusing IMU acceleration with celestial position outputs. I worked through both 2D and 3D formulations and decided that a full 3D state representation is needed to properly handle gravity projection and tilt induced drift. I derived the continuous and discrete time process models for position and velocity propagation using accelerometer measurements.

My progress is currently on schedule. This week was intended for algorithm development and mathematical groundwork before the implementation. The derivations are complete at a conceptual level, and I am ready to begin coding to validate filter behavior before hardware integration.

Posted on

Team Status Report for 2/7

This week, most of our bandwidth was spent preparing our proposal presentation, which was presented on Wednesday. We also began preparing our parts list and our hardware layout; ordering parts and beginning software development are the goals for the upcoming week. Our team is also working to gain familiarity with requisite concepts including filtering, localization, drone controls, and vision while we wait for arrival of parts.

Posted on

Julius’ Status Report 2/7

This week, I focused on preparing the proposal presentation that we presented on Wednesday. Additionally, I began research on parts to be used for the project and producing the hardware design – as was presented in the proposal. I produced a tentative parts list for the design including:

  1. An H7 flight controller
  2. Arducam IMX477 camera
  3. RPi compute module (though this may be replaced with course inventory for cost)

The Arducam camera has a similar spec as our reference paper, but weighs only 12 grams and is considerably cheaper.

Posted on

Rachel’s Status Report 2/7

This week, I focused on completing and refining the use case and user requirements for our design proposal. As part of this process, I explored the technical implications of our requirements, particularly calibration accuracy, environmental assumptions, and realistic localization error bounds. I also began foundational work for my role by doing initial research on star detection and tracking algorithms suitable for low-light conditions.

I am currently on schedule, as this week was intended for proposal refinement and background research. In the immediate next steps, I plan to prototype simple star detection and preprocessing pipelines using sample nighttime imagery. I also plan to further explore camera calibration workflows and imaging parameter tuning to prepare for early system-level testing.