Author: bbji

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

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.

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.

This week, I focused on refining the mobile application and completing its integration with the Raspberry Pi–based control system for the smart umbrella. I continued developing the app in Xcode and worked on improving the overall user interface and responsiveness. The control features were polished to make manual adjustments of the umbrella’s position more intuitive, allowing users to easily set the desired pan and tilt angles.

In addition to the app improvements, I successfully integrated the mobile application with the Raspberry Pi. I established communication between the app and the controller, enabling commands sent from the app to be received and executed by the hardware system. Through testing, I verified that user inputs from the app correctly trigger the stepper motors, allowing the umbrella to move as intended.

Overall, this week’s progress resulted in a functional end-to-end pipeline for manual control, where the mobile app can reliably communicate with the Raspberry Pi and control the physical system. Moving forward, I plan to enhance real-time feedback from the controller, improve communication reliability, and begin adding more advanced features such as automated tracking and preset positions.

This week I focused on the development of the iOS application that will control the smart umbrella system. I created the initial Xcode project and implemented the basic app structure using SwiftUI. The app includes separate components for models, services, view models, and views to keep the code organized.

I implemented the networking layer that will allow the app to communicate with the Raspberry Pi using HTTP requests. The app is set up to send commands such as move, stop, and mode changes, and to retrieve status information from the umbrella system.

The user interface currently includes the initial screens for connecting to the device and controlling the umbrella. These screens will eventually allow users to adjust pan and tilt angles, change modes, and monitor system status.

I also committed the initial version of the app to our GitHub repository and pushed it to a new branch (iOS-APP) so the team can review and collaborate on the implementation.

Next steps include connecting the app to the Raspberry Pi API, testing communication between the phone and the umbrella system, and improving the control interface for smoother interaction.

Weekly Progress Update

This week, I developed the basic structure of the iPhone app and began setting up communication logic for connecting to the Raspberry Pi. I researched how to obtain GPS data from the phone and worked on calculating the sun’s position based on location and time. From this, I derived the angle needed for the umbrella to rotate to provide optimal shade.

At this stage, my primary challenge is ensuring that the software architecture remains scalable as more hardware components are finalized. Since the perception system, motor control logic, and mobile app will eventually operate together, I want to make sure the foundation I build now can support added complexity later. If integration becomes more complicated than expected, I can refactor the structure into smaller, more modular components to keep the system organized and maintainable.

Over the past week, I focused on designing the structural layout for the arms and joints while also progressing on the perception and estimation framework. On the software side, I outlined the full integration workflow and implemented the initial project setup in Xcode using Swift. I established the core architecture and built the essential functions to create a stable starting point for continued development and testing.

This week, I focused primarily on researching the feasibility and technical requirements of the individual components needed for our product. I spent time analyzing the torque requirements for the motor to ensure it will be capable of handling the expected load, including estimating forces and mechanical constraints involved in the system. In addition, I worked on calculating the battery capacity we will need by considering the power consumption of the motor and other electronic components, as well as estimating the desired operating time to ensure the system can function reliably without frequent recharging. I also researched the umbrella-related mechanical components, including possible mounting mechanisms, structural support, and how the opening and closing mechanism could be integrated with our motorized system.

Alongside this research, I continued coordinating with my team to share findings and help refine our design decisions. This research was important in helping us better understand the technical feasibility of our design and in identifying appropriate components that meet our performance requirements. While much of this week was focused on research rather than physical implementation, it was necessary to ensure that our design choices are realistic and achievable within the project timeline. Moving forward, I plan to use this research to help finalize component selection, begin sourcing parts, and support the transition from conceptual design to prototyping.