[Feature] replace gpiozero with direct lgpio calls

[peteattayek]

Description

Remove gpiozero from strobe calibration and use lgpio direct calls instead. This PR DOES NOT update test_strobe_calibration_manager.py. This must be addressed in a future commit/PR

What does this PR do?

strobe_calibration_manager.py was changed to remove the gpiozero-based DIAG pin control and replace it with direct liblgpio calls via ctypes. Instead of relying on gpiozero backend selection, the code now opens and claims the DIAG GPIO line directly, tries gpiochip4 first for Pi 5, and toggles the line with lgGpioWrite. This was needed because the previous Python GPIO path depended on gpiozero/Python lgpio runtime behavior that caused failures under the web service, while the direct liblgpio approach avoids the the need for write access to the working directory and better matches the existing C++ strobe implementation.

This PR DOES NOT update test_strobe_calibration_manager.py

Why is this change needed?

This was needed because the previous Python GPIO path depended on gpiozero/Python lgpio runtime behavior that caused failures under the web service, while the direct liblgpio approach avoids the the need for write access to the working directory and better matches the existing C++ strobe implementation.

Related Issue(s)

#186

Changes Made

• Remove gpiozero from strobe_calibration_manager.py and replace it with direct liblgpio calls
• remove gpiozero from requirements.txt
• remove installation of gpiozero dependencies from pitrac-common-functions.sh

Testing Performed

Test Environment

• Pi Model: Pi 5 8GB
• Camera Type: None
• OS Version: Trixie 64 bit
• Installation Method: Source

Test Results

• pitrac test hardware passes
• pitrac test camera passes (if camera-related)
• pitrac test pulse passes (if strobe-related)
• Simulator integration tested with:
• Performance metrics:

Test Commands Run

# Paste the actual commands and output

Performance Impact

• Before:
• After:
• Impact:

Breaking Changes

• This PR includes breaking changes
  • What breaks:
  • Migration steps:

Dependencies

• No new dependencies

• [ ] New dependencies added:

• [x ] Updated dependencies:
  • remove gpiozero and python dependencies

Hardware Compatibility

• [ x] Tested on Pi 5
• Tested on Pi 4
• [x ] Tested with single Pi setup
• Tested with dual Pi setup

Documentation

• [x ] No documentation needed
• Documentation updated in this PR
• Documentation PR to follow
• Updated relevant sections:
  • README
  • Hardware guide
  • Software guide
  • Troubleshooting guide

Screenshots/Videos

AI (Vibe-Coded) Content Description

Code was reviewed by AI and some error handling was suggested

Checklist

Code Quality

• [x ] Code follows existing patterns and conventions
• [ x] No unnecessary comments added
• [ x] Error handling implemented appropriately

Build & Test

• [x ] Successfully builds with ./packaging/build.sh build
• All existing tests pass
• New tests added for new functionality
• Tested on actual Raspberry Pi hardware (not just CI)

Submission Requirements

• Commits squashed if needed (git rebase -i HEAD~n)
• CLA signed
• PR title follows format: [PR TYPE] Brief description
• Branch is up-to-date with main

Additional Context

---

[peteattayek]

@connorgallopo I did not make any changes to test_strobe_calibration_manager.py. If you like this change, I can take a stab at it.

[connorgallopo]

Hey @peteattayek - appreciate the effort on this but I don't think we should go this route.

gpiozero is the official Raspberry Pi Foundation library - it ships pre-installed on Pi OS and has ~227k weekly downloads. Replacing it with 60+ lines of hand-rolled ctypes calling liblgpio directly is a lot of surface area to maintain for something that has a known one-line fix.

The actual issue is that lgpio tries to create a named pipe in the working directory and the web service doesn't have write access there. This is a gpiozero/gpiozero#1106 and the fix is just:

import os
os.environ.setdefault('LG_WD', '/tmp')

before importing gpiozero. That's it.

Going the ctypes route means we own all of this now - chip candidate lists, ABI declarations, handle management, error handling - stuff that gpiozero already handles and will continue to maintain upstream for future Pi hardware.

Also re: "better matches the existing C++ strobe implementation" - that's not really a win. The whole point of using Python here is to leverage higher level abstractions. If we wanted to match the C++ path we'd just write it in C++.

I'd rather we keep gpiozero and just set the env var or handle it similarly. Way less code, way less risk.

[peteattayek]

This sounds good - closing this PR in favor of using a tmp working directory for gpiozero to have write access to