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

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

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.

Posted on

Team Status Report for 4/4/26

The main risks at this stage are mechanical stability and system integration. As more components are added, the arm must support increased weight and handle external forces like wind. We are managing this by testing the structure under load and evaluating reinforcement options. If needed, we will strengthen the arm or adjust the design, even if it slightly increases weight. Integration is another risk, so we are beginning full system testing early to catch issues.

The project is on schedule with a revised version; the physical design and assembly were the main things keeping a lot of things behind, but with almost all of the major subsystems now functional, we’re more effective in parallelizing testing and validation. We are moving into integration.

We have several working components, including BLE-based motor control, a functioning user detection system on the Raspberry Pi, and a semi-completed physical assembly.

For validation, we are running end-to-end tests from user detection to motor movement and will measure tracking accuracy, response time, and system reliability against our design requirements.

Posted on

Bonnie’s Status Report 4/4/26

At this stage of the project, development has moved into the verification and validation phase. I developed an iOS application using Shifted that communicates via Bluetooth with a Raspberry Pi, which is connected to a motor step driver controlling a motor. This subsystem allows wireless control of the motor through the mobile app.

For verification, I focused on testing the functionality and reliability of my subsystem. I tested Bluetooth connectivity to ensure stable pairing and consistent communication between the app and Raspberry Pi. I also verified that commands sent from the app (such as start, stop, and speed changes) were accurately received and executed by the motor system. Motor behavior was observed and compared to expected outputs to confirm correct operation. Additionally, I tested the user interface to ensure all controls function properly and respond as intended.

For validation, I evaluated the complete system to ensure it meets the overall project requirements. This included end-to-end testing from user input on the app to motor movement. I measured response time and checked system reliability during continuous use. I also tested the system in realistic scenarios to confirm that it meets the intended use case of simple and effective remote motor control.

To analyze results, I compared measured performance (such as response time and accuracy) against the design requirements. I also conducted repeated tests to ensure consistent performance and monitored for errors such as missed commands or delays. Overall, the system is functioning as expected, and continued testing will focus on improving stability and performance under more demanding conditions.

Posted on

Team Status Report for 3/28/26

One of the most significant risks to the project at this stage is the mechanical integrity of the system, particularly the weight constraints and the strength of the arm supporting the umbrella. As we continue assembling the physical structure, we are evaluating whether the current materials and design can reliably support the motors and canopy under expected loads, including environmental factors. To manage this risk, we are testing the structure incrementally and assessing whether reinforcement or material changes are needed. If the current design proves insufficient, our contingency plan is to adjust the arm design by using stronger materials or modifying the geometry to better distribute load, even if this slightly increases weight.

Another potential risk is ensuring smooth integration between the hardware and software subsystems. While major components such as user detection and BLE-based motor control are now functional independently, integrating them into a cohesive system introduces complexity. To mitigate this, we are prioritizing early integration testing as soon as physical assembly allows, so that issues can be identified and resolved well before final demonstrations.

There have not been major changes to the overall system architecture or high-level design requirements, but minor adjustments are being made to the mechanical design as we better understand real-world constraints. These changes are necessary to ensure the stability and durability of the system in a beach environment.

The project schedule remains largely on track. While some time was spent resolving hardware setup and debugging issues, progress in parallel across mechanical assembly, vision, and communication subsystems has kept the team aligned with key milestones. As integration begins, we will continue to monitor progress closely and adjust task distribution as needed.