The Global Meteor Network (GMN) uses cameras distributed all over the planet to measure meteor events. The project provides detailed instructions on how to setup a system being a popular option using a Raspberry Pi 4 with either an IP Camera connected to its ethernet port or a camera attached to the MIPI (Mobile Industry Processor Interface) connector. For my installation, the camera should be very discrete so no big enclosure could be used. A small overture in the roof allows for having the raspberry pi inside the building and placing the camera outside. I chose an Arducam IMX462 camera attached to the MIPI connector by a long cable, 30 cm in my case.
Here are the main steps I followed for installation:
- Download GMN debian bullseye image and transfered it to a 256 GB SD Card. This was the distribution officially supported by both Arducam and GMN at end of 2023.
- boot the system and install and configure Arducam software:
- define camera kernel module to be loaded in
/boot/config.txtby addingdtoverlay=arducam-pivariety - coment out the assignment of ip address to an ethernet camera in
/etc/dhcpd.conf - install arducam’s modified version for libcamera:
sudo ./install_pivariety_pkgs.sh -p libcamera_dev sudo ./install_pivariety_pkgs.sh -p libcamera_apps - reboot the system (simple) or load the arducam-pivariety kernel module, and verify that the camera is recognised:
$ dmesg | grep arducam arducam-pivariety 10-000c: firmware version: 0x10002 - There is a problem when running a libcamera application:
To solve it, provide the configuration file by taking the imx290.json one:
$ gst-launch-1.0 libcamerasrc ! 'video/x-raw,width=1280,height=720' ! queue ! glimagesin ... ERROR IPAProxy ipa_proxy.cpp:149 Configuration file 'arducam-pivariety.json' not found for IPA module 'rpi/vc4' ...$ cd /usr/share/libcamera/ipa/rpi/vc4 $ sudo cp imx290.json arducam-pivariety.json # No error should be shown. $ libcamera-still --list-cameras Available cameras ----------------- 0 : arducam-pivariety [1920x1080 10-bit RGGB] (/base/soc/i2c0mux/i2c@1/arducam_pivariety@c) Modes: 'SRGGB10_CSI2P' : 1920x1080 [30.00 fps - (0, 0)/0x0 crop] $ gst-device-monitor-1.0 Video ... video/x-raw, format=UYVY, width=1280, height=720 ... video/x-raw, format=UYVY, width=1280, height=1024 ...
- define camera kernel module to be loaded in
Now the camera is available to be used by the GMN software. The meteoroid traces are recognised internally by using OpenCV. For efficiency reasons, it is good to get an image directly from the camera and avoid unneeded conversions for OpenCV. The current way to do that is by defining a GStreamer pipeline using the libcamerasrc plugin, (discussion reference).
The important parameters of the GMN software are in the /home/rms/source/RMS/.config file.
In particular, the device parameter defines the GStreamer pipeline. My pipeline configuration based on libcamerasrc is:
device: libcamerasrc ! video/x-raw,width=1280,height=720,framerate=40/1,format=UYVY
! appsink
uyvy_pixelformat: true
fps: 40 ; frames per second
framerate, set it to a higher value to detect fainted meteors, but higher means less exposure time in the sensor so fewer stars get detected by GMN. Also more data gets generated, so more burden for the system.heightandwidth, less memory size to be managed, better for performance and for later saving disk spaceuyvyraw video format, which reduces the amount of data for representing color, is supported by GStreamer and OpenCV, and GMN users claim good picture qualityappsink: supports many different methods for making the application get a handle on the GStreamer data in a pipeline
To test the camera output:
python -m Utils.ShowLiveStream
This would be the camera specific setup having the advantage that no conversion is done in the GStreamer pipeline. For this reason, no GPU memory is required, and I commented it out in `/boot/config.txt’ so the default value (72 MB) applies.
Tests on frames per second configuration Link to heading
The choice of 40 fps for the GStreamer pipeline was done to allow for enough exposure at the sensor to trigger meteor detection which requires a minium of 20 stars being detected. These two FITS files with meteor traces correspond to cases with 60 and 50 fps, FF_XX0010_20240205_185515_184_0407040.fits (60 fps) and FF_XX0010_20240206_211043_898_0736768.fits (50 fps). Those meteors where not found by the processing, but by myself looking manually into the data. The GMN log for the 1280x720 @ 60 fps case was:
2024/02/05 18:55:23-DEBUG-Compression-line:319 - Extractor started for: XX0010_20240205_185515_184_0407040
2024/02/05 18:55:23-INFO-DetectStarsAndMeteors-line:63 - Running detection on file: FF_XX0010_20240205_185515_184_0407040.fits
2024/02/05 18:55:23-INFO-DetectionTools-line:63 - No mask file has been found.
2024/02/05 18:55:23-INFO-Compression-line:332 - Added file for detection: FF_XX0010_20240205_185515_184_0407040.fits
2024/02/05 18:55:23-DEBUG-VideoExtraction-line:285 - [XX0010_20240205_185515_184_0407040] time for thresholding and subsampling: 0.14293766021728516s
2024/02/05 18:55:23-DEBUG-VideoExtraction-line:289 - [XX0010_20240205_185515_184_0407040] nothing found, not extracting anything 1
2024/02/05 18:55:23-INFO-ExtractStars-line:186 - extracted 3 stars from FF_XX0010_20240205_185515_184_0407040.fits
2024/02/05 18:55:23-INFO-DetectStarsAndMeteors-line:89 - Detected stars: 1
2024/02/05 18:55:23-INFO-BufferedCapture-line:474 - New block of raw frames available for compression with starting time: 1707159319.4512918
2024/02/05 18:55:23-INFO-BufferedCapture-line:331 - Grabbing a new block of 256 frames...
2024/02/05 18:55:23-DEBUG-Compression-line:274 - Compressing frame block with start time at: 1707159319.4512918
2024/02/05 18:55:27-DEBUG-Compression-line:295 - Compression time: 3.501 s
The maximum pixel image out of the FITS file is shown here, where the point close to the meteor trace probably corresponds to Jupiter.
.
It is clear from the log file that no meteor detection was done as the GMN 20 stars detected minimum was not achieved. There are parameters in the .config file to finetune sensitivity of the sensor but for now, my choice is to go for a lower fps value.
Debian Bookworm changes Link to heading
When debian bookworm is supported by Arducam, the module to be used for this camera seems to be dtoverlay=imx462. Also a config/tuning file might be required.
Other parameters needed for the GMN configuration are explained in GMN’s wiki. Another blog entry details further changes I made to the default GMN installation to have a headless system with less resources being used. A Raspberry Pi 3B with this configuration at 128x720 @ 30 fps processed the data during the whole night, so for me this platform could still be used.