Posted on

Nicholas’s Status Report for 4/25/26

Finalizing parts of the physical housing took a lot of additional time. There was some issues with the sizing of bevel gears in the design which required some reordering of parts. Some parts of drilling holes in the umbrella as well took some additional planning and such but I managed to complete it. I was worried about the prospect of drilling centered holes into a curved surface but using the prints as guides made the process go pretty smoothly. Since then I have worked on helping integrate the motors into the final assembly and as we approach the final deadlines all that is left to do is more validation/verification testing of the motors integrated into the assembly.

In terms of unit testing, the most complete testing that I have been able to accomplish for my portion has been in terms of the IMUs which determine the umbrellas and as such the RPI’s orientation awareness, which is crucial for the control loop. At first most of the testing was just verification that the software was working, especially given that we moved to different ICs given the board failure that we had to contend with. This also required additional testing when I introduced interrupts into the orientation tracking so eliminate polling in the process. This was all to reduce the CPUs load dramatically during the execution of the position scripts. In order to test the accuracy of the orientation sensing at first I was testing things just by eye during the process of getting it working, but once that was verified I moved into using my phones compass for reference. The roll and pitch measurements were immediately already accurate (~1%) but the Yaw measurement took some more time. This mostly had to do with getting more accurate values for the magnetometer which over time continually comparing the calculated true north with the phone I was able to get ~5% accuracy there which was around what we were hoping for and good enough for the application within our project.

Posted on

Team Status Report for 4/25/26

The most significant risks to the project are delays in physical assembly and potential hardware reliability issues, particularly with motor functionality and wiring. These risks are being managed through continued subsystem testing, early integration validation, and debugging as issues arise. A contingency plan is to isolate and test each subsystem independently if full system integration fails, and to fall back on simplified operation modes (e.g., manual control) to demonstrate core functionality if needed.

No changes were made to the existing system design (requirements, block diagram, or system specifications).

Unit tests carried out include:

  • Sensor validation (IMU and sun sensor readings accuracy and consistency)
  • Motor control tests (stepper motor direction, step accuracy, and response to GPIO signals)
  • Communication tests between Raspberry Pi and individual components

System-level tests carried out include:

  • End-to-end motor–sensor integration (sensor input → control logic → motor actuation)
  • Alignment testing (verifying system response to changes in orientation or light direction)
  • Subsystem interaction testing to ensure all components function together without conflicts (outside actually panning/tilting the umbrella)

Testing helped confirm that the integration pipeline is functioning correctly, and no major design flaws were identified, so no design changes were necessary.

Posted on

Ore’s Status Report for 4/25/26

Focused mainly on preparing and finalizing the final presentation, since I was the one presenting. I also started working on the final poster early to make sure we stay on track and don’t fall behind. In addition, I helped finalize testing across all subsystems and the overall system to ensure everything is validated.

Physical assembly is slightly behind schedule. To address this, we will prioritize assembly tasks this week and ensure more time is allocated specifically to completing the hardware integration.

Plan to continue working on and finalize the poster, and help push physical assembly to completion for the demo day. Also, aim to support any remaining system-level testing once the full assembly is complete.

Posted on

Bonnie’s Status Report 4/25/26

I completed the final calibration of both vertical and horizontal stepper motors in motor.py. This involved fine-tuning step timing, direction switching delays, and enable/disable sequencing to eliminate missed steps and reduce audible buzzing.

Using ble/motortest.py , I iteratively adjusted:

  • Step pulse width and delay between steps
  • Direction settle time before motion
  • Enable pin polarity (active-high vs active-low)
  • Maximum safe stepping rate under load

I also validated consistent motion across different step ranges (1–50 steps) and ensured that small corrective movements were smooth rather than jittery. The final configuration achieves stable, repeatable positioning without overheating or skipped steps.

Integration and app controls

I polished the full system integration between the Pi, BLE server, and iOS app:

  • Added manual control buttons in the app for horizontal and vertical adjustments, allowing override of automatic tracking
  • Ensured bidirectional BLE communication is stable, with commands reliably reaching the Pi and status updates returning at ~10 Hz
  • Improved JSON payload structure to include clearer motor state and command acknowledgments
  • Verified synchronization between app UI state and actual motor state (no drift between displayed and real position)

The integrator loop now cleanly merges:

  • Sun telemetry (azimuth/elevation)
  • User detection error
  • Manual override commands

with priority handling so manual input temporarily overrides automatic behavior.

Testing

  • Unit tests
    • Sun position outputs verified against known values and edge cases (UTC conversion, sunrise/sunset)
    • Motor error → step mapping validated (scaling, clamping, direction)
    • BLE JSON structure checked for correct fields and app compatibility
  • Integration tests
    • used for direction changes, variable stepping, and long-run stability
    • Integrator loop confirmed stable at 10 Hz with non-blocking motor control
    • BLE tested for reliable command delivery and consistent status updates
  • System tests
    • End-to-end: app → BLE → Pi → motors → status → app
    • Manual override vs automatic tracking behavior verified
    • Stress test with rapid commands and reconnect scenarios

Findings

  • High step rates caused occasional missed steps → required increasing delay between pulses
  • Rapid direction changes introduced small positioning errors → fixed with added direction settle time
  • BLE message bursts could temporarily desync UI → improved by adding lightweight acknowledgment logic
  • Small error values caused jitter → resolved by enforcing minimum step threshold and smoothing

Design changes

  • Adjusted motor stepping profile to prioritize smoothness over speed
  • Added minimum step threshold to avoid micro-jitter
  • Introduced manual override priority in integrator logic
  • Improved BLE protocol with clearer state reporting and synchronization handling
  • Refined threading model in motor.py to ensure safe concurrent execution
Posted on

Ore’s Status Report for 4/18/26

Worked on full sensor integration, debugging, and testing with the motors. This included verifying that sensor outputs (e.g., IMU, sun sensor data, user detection) are correctly read by the Raspberry Pi, processed into control signals, and then used to drive the stepper motors. Specifically, I tested the full pipeline from sensor readings → control logic → GPIO signals → motor actuation, ensuring that the motors respond correctly to changes in sensor input (e.g., adjusting position based on orientation or sun alignment). Ran into an issue where the motors stopped working, which required debugging and rewiring parts of the system. After we fixed the issue, I continued motor–sensor integration and testing, which is now almost complete.

Slightly behind schedule due to the time spent debugging and rewiring the motors. To catch up, I will focus on completing real system testing (moving the canopy) and prioritizing integration validation.

I plan to complete real system testing with canopy movement and finalize motor–sensor integration testing in the next week.

I learned more about motor control and interfacing with the Raspberry Pi 5, building on my previous basic understanding. Used online videos, Raspberry Pi tutorials, and posts from past ECE capstone groups working on similar projects. I also relied on prior knowledge from past courses and projects for some of the user detection methodology.

Posted on

Bonnie’s Statues report for 4/18

I had to pick up BLE peripheral work on the Pi (GATT characteristics and a simple JSON protocol to the phone), threading/async so motor stepping did not stall the main loop, and stepper basics with lgpio—timing, enable polarity, and why the motor sometimes buzzed instead of turning. I also learned enough time and location handling (ISO timestamps, UTC) to compute sun elevation and azimuth on-device and keep it in sync with what the iOS app sends. To learn it, I mostly read library docs and datasheets, used targeted web searches and forum threads when I hit hardware or BlueZ errors, watched a few short setup videos for wiring and drivers, and relied on small test scripts and lots of print logging to isolate BLE vs motor issues before wiring everything into the full app.

This week I focused on getting the sun location, testing, and calibrating the motors:

Sun location — I added on-Pi sun position in sun_location.py. It takes latitude, longitude, and an ISO-8601 time (from the phone over BLE, stored in shared BLE state), converts time to UTC, and computes elevation (degrees above the horizon) and azimuth (0° north, clockwise) using standard solar-position steps (Julian day, declination, equation of time, hour angle, then zenith and azimuth). If GPS is not available yet, it uses a default Pittsburgh coordinate pair and sets source to default_location; otherwise ble_location. integrator.py calls this each loop, treats azimuth/elevation like the old alpha/beta “sun sensor” outputs, and ble_server.update_sun_status pushes sun_azimuth, sun_elevation, sun_source in the JSON the iOS app decodes. Important: automatic shading still follows user-detection errors, not the sun vector; the new work is mainly accurate sun telemetry and a clean base for future sun-aware control.

Motors and smooth motion — motor.py drives vertical and horizontal steppers over lgpio (BCM pins per PINOUT.md), with direction settle time, enable sequencing, short step pulses, and non-blocking moves via a background thread so the 10 Hz integrator loop does not stall. Without GPIO, it logs simulation lines instead of pulsing pins. In integrator.py, send_motor_commands maps tracking error to a bounded step count (roughly proportional to |error|, clamped between 1 and 50 steps) so motion is less jerky than a fixed huge step every tick, and it calls stop_all when there is no command. Calibration in the repo means hardware tuning: ble/motor_test.py is the tool to adjust step timing, optional active-high enable, and slower stepping when drivers buzz or skip steps.

Testing —

Sun: I compared the Pi output to known times/locations or the older logic/sun_calc.py script (pysolar-based prints).

Motors: motor_test.py is the main integration test on real hardware (sudo, Pi). Sensors: small scripts under sensor/ exercise IMU reads.

I plan on adding a few pytest cases for sun math and a smoke test for JSON status fields before demo or handoff.

Posted on

Nicholas’s Status Report for 4/18/26

This week as well as part of the last was the final push for completing CAD designs as well as IMU debugging/integration. Starting with the IMU I had some pretty bad circumstances to overcome. When coming in to tune the current 9-DoF LSM9DS1, I found that the RPi was not able to talk to it over I2C like it was previously. I tried to debug the hardware for hours over 2 days but nothing was working and I came to the conclusion that the board must have failed somehow maybe due to a short but I never came to a definitive answer. Given the short deadlines an also that that particular breakout board was out of stock from Adafruit I had to quickly pivot. Luckily enough I remembered I had some leftover boards from a previous course/project which combined had all the sensors I needed to compute absolute orientation. So I reworked all the code to work with the new boards as well converting the system to use interrupts to remove polling from the code. After some additional testing I was able to get the tolerance to ~1 deg.

In the past week the CAD was fully finished in terms of the umbrella assembly and the parts were 3D printed. The design as mentioned later ended up being much more complicated than initially anticipated and required ordering additional hardware to make work. With the design I also tried to optimize it for 3D printing meaning minimizing overhangs.

Due to my delays in finishing the design I have been slightly behind where I would have liked to be in terms of building the umbrella assembly out with enough time for testing.

Next week will be left for any additional testing/validation that needs to occur before the Final Demo. Due to falling behind schedule in areas, particularly when it came to the assembly mechanical design. Particularly, I just haven’t had much time to consider the ingress protection of the parts. Due to either failures or other things I will likely design 3D print new revisions hopefully with parts that we can fully test for the standards we would like to hit for our use-case requirements.

As you’ve designed, implemented and debugged your project, what new tools or new knowledge did you find it necessary to learn to be able to accomplish these tasks? What learning strategies did you use to acquire this new knowledge?

We recognize that there are quite a few different methods (i.e. learning strategies) for gaining new knowledge — one doesn’t always need to take a class, or read a textbook to learn something new. Informal methods, such as watching an online video or reading a forum post are quite appropriate learning strategies for the acquisition of new knowledge.

Definitely the hardest learning curve was working with Fusion360. I chose the software over Solidworks (which I have worked briefly with previously) because I perceived it as being easier to use and simpler. I have also had limited experience using it, but the design requirements of the project required me to quickly gain experience with it. The biggest help in the process was looking at free released other 3D models with similar design goals to gain inspiration, as well as lots of youtube videos. I definitely learned a lot, and there is still a lot I would like to improve, although the timeline of the project did not afford much wiggle room.

Posted on

Team Status Report for 4/18/26

The main risks at this stage remain mechanical integration and timing. While most subsystems—including user detection, Bluetooth control, and sensor integration—are functioning well, the primary challenge is completing the physical mounting of all components onto the umbrella. Delays in mounting have pushed back some integration testing. To manage this, the team is prioritizing final assembly tasks and distributing the workload to accelerate completion. If delays continue, we will rely on our existing testbench to continue validating motor control and subsystem interactions and perform incremental integration as each component is mounted.

There have been no major changes to the overall system architecture or design requirements. Any additional cost or time impacts are being mitigated by leveraging existing materials and optimizing assembly processes.

The project schedule is largely still on track, with some delays in physical assembly. However, progress in sensor integration and motor control testing has continued in parallel, allowing us to maintain momentum. As assembly is finalized, we expect to quickly transition into full system testing and validation without significant impact to final deadlines.

Posted on

Nicholas’s Status Report 4/4/26

This past week I completed work on the sensory and motor foundations for the project. I programmed a full inertial orientation tracking system based on the RPI’s connection to the LSM9DS1 IMU and helped in setting up basic motor functionality the rest of which was completed by my project partners.

Working with the LSM9DS1 9-DOF IMU required communicating with the device via I2C using python libraries. Once all the raw data could be processed I implemented a Mahony AHRS filter which combined the data from the three sensors on the breakout I was using. Combing those three readings can give accurate readings for the absolute orientation of the sensor relative to the earth. This will enable the umbrella to understand where it is relative to the sun and the user which is tracked through the camera. I now need to finish up with the assembly manufacturing that will go on the actual umbrella as we move into the final phases of the project.

The verification that will come later is testing the stability and truthfulness of the LSM9DS1 IMU. Its orientation should not only be accurate but be resilient to motor noise and tuned to the local magnetic interference. The bias values which control its ground truth also nee to be tuned and verified.

In terms of the motors as we complete the final assembly the main verification that will be required is testing of the PID of the motor system. If we were to give the motors a specific orientation to turn to which marking to denote where it should be we can measure the error of how far it is away from its desired orientation and as well how long it takes.

Posted on

Ore’s Status Report for 4/4/26

This week, I focused on progressing toward full system integration. I worked on motor debugging and connecting the user detection pipeline with the rest of the system, specifically preparing it to interface with the Bluetooth control pipeline and motor subsystem.  I also began structuring the integration logic that combines inputs from the vision system, Bluetooth app commands, and solar positioning into a unified control flow.

My progress is on schedule with the revised Gantt chart. With the major debugging issues resolved and subsystems I’m dependent on now functional, I am able to move forward into integration.

For verification of my subsystem, I am testing the user detection pipeline by measuring detection latency and stability. I also verify that the computed position error responds correctly to user movement in the frame.

Next week, I plan to complete the full integration script that combines the Bluetooth app, user detection system, and solar positioning logic. I will begin end-to-end testing by feeding detection outputs into the motor control system and measuring how accurately and quickly the system responds. To analyze results, I will compare measured latency, responsiveness, and tracking accuracy against our design requirements to ensure the system meets both engineering design and use-case requirements.