Feature #743
closed
Add PiSentry system: a webcam meta build
Added by Hammel over 4 years ago.
Updated over 3 years ago.
Description
This is just a modified version of the PiBox Media System that contains only the following packages.
- appmgr
- launcher
- mjpg-streamer
- monkey
- omxplayer
- piboxd
- piboxmediaserverui
- piboxwww
- picam
- psplash
- videofe
The UI should just have the network and picam app displayed. This allows a console view of the camera. It also allows network configuration from the console. However, the main purpose is to provide a web based interface only. So this also needs to have an AP mode that allows configuring the network for the system. This would require a variation of Ironman's imwww interface. This can be in a different subdirectory and launched separately depending on the mode the device is in, which can be handled with GPIO pins.
This build should also provide Ironman functionality by allowing the Pi to register as a sensor device.
As a bonus: add an option to make PiSentry a USB UVC gadget, allowing it to stream data to a USB host. This would allow a set of PiSentry's to be managed by a single host, albeit only if they are hardwired.
- Description updated (diff)
- Subject changed from Add webcam meta build to Add PiSentry system: a webcam meta build
Possible recommended cameras:
Microsoft Lifecam HD-3000
Microsoft Lifecam HD-5000
Microsoft Lifecam Cinema 720p HD webcam
Microsoft LifeCam Studio 1080p HD
Logitech Webcam C250 1.3 megapixel webcam
Logitech QuickCam® Sphere AF. Motorised 2-megapixel HD sensor webcam with Carl Zeiss® optics.
Logitech Webcam C270
PAPALOOK PA150 / PA150S
- Priority changed from High to Immediate
- Severity changed from 01 - Critical to 03 - Medium
- Description updated (diff)
- Severity changed from 03 - Medium to 02 - High
- Severity changed from 02 - High to 03 - Medium
- Status changed from New to In Progress
- % Done changed from 0 to 10
Now that I have piplayer and pinet I think a better solution for doing this without a display is:
- Add a headless (daemon) mode to pinet
- If pinet gets a SIGUSR1 then it toggles state.
- Initial state is non-AP mode.
- AP state starts imwww and blinks an LED slowly.
- SIGUSR1 toggles back to non-AP mode and blinks an LED fast 5 times when the network has restarted.
The camera works independent of Ironman (for now, I'll add registration stuff later). It's a stand alone solution.
I need a momentary push button that ties the GPIO pin to vcc and an led on a different GPIO pin.
Pinet can either read the GPIO pin in a thread using libgpiod (which would need to be an added package or Buildroot package) or use Ironman's gpio utility. The latter would require popen/system and probably isn't the best option, though that utility could be updated to generate a library that pinet could use.
This changes the metabuild to the following apps:
- mjpg-streamer
- monkey
- piboxd
- piboxwww
- pinet
- imwww
pinet gets launched in headless mode at boot time via an init script. It watches the GPIO pin for state changes and acts accordingly.
monkey and piboxwww should always be running and allow only user management and webcam viewing.
This also needs to disable X.org so it doesn't try to boot up. Firstboot should recognize there is no display connected.
- Severity changed from 03 - Medium to 01 - Critical
This requires a new app - pisentrycfg. This will disable some features of the development platform like X.org and SMB that are not required for the camera.
- % Done changed from 10 to 40
pisentrycfg created and added to metabuild.
piboxwww updated to support HW=pisentry to remove network config option.
This is basically working on the touchscreen hw. Now I need to try it on the true headless hw.
The biggest problem is that the network restart is not working well. I might want to switch from network restart to node reboot from the restart script. This might help prevent getting stuck in AP mode on failures.
- % Done changed from 40 to 70
Much of this is working now but there are problems with wifi. The USB dongle is mostly stable but has problems that can leave things in a bad state. So there is work (RM #826) that will handle recovering on reboot.
The brcm drivers are also having problems, likely due to a firmware bug. This may require a kernel update. See RM #817.
Once I have the recovery bit in place I can close this issue after a full rebuild and test. Other issue will be tracked separately.
- Status changed from In Progress to Closed
- % Done changed from 70 to 100
The metabuild works and the system installs cleanly.
All changes committed and pushed.
Closing issue.
Also available in: Atom
PDF
Updated by