Installation for Linux: Difference between revisions
No edit summary |
TasmanSkies (talk | contribs) (Added draft section for multiple-camera config) |
||
Line 107: | Line 107: | ||
I find this is pretty quick and responsive even on a lowly i3 processor and running headless. | I find this is pretty quick and responsive even on a lowly i3 processor and running headless. | ||
=== Multiple Camera Configuration === | |||
'''''This section is a work in progress and until this notice is removed, should be considered a draft pending testing for verification and validation.''''' | |||
Some contributors want to run multiple cameras; this is the recommended way to achieve this on a Linux machine. | |||
'''Hardware requirements''' | |||
A Raspberry Pi 4B has insufficient resources; a mini-PC is required as a minimum platform. | |||
For the benefit of standardization for new off-0the-shelf/turnkey systems, do we perhaps suggest looking at such platforms as the [https://www.aliexpress.com/item/1005003047104953.html M1T], [https://www.aliexpress.com/item/1005003847375293.html ZX01], or [https://www.aliexpress.com/item/1005002964485725.html MeLE Quieter2] and note that use of any available PC platform is more than likely adequate? | |||
'''Strategy''' | |||
Use a single vanilla RMS install but launch the StartLiveCapture script with a '''--config <path to your stations .config file>''' This requires that you place each instances .config file into a unique directory since the filename is hardcoded. | |||
Drawbacks to this method are | |||
*There is potentially a race condition when at the start of a capture RMS looks to see if there is enough free space for the nights capture (also depending on your storage layout you may also have to increase the extra_space_gb parameter) | |||
*Not all of the RMS scripts support the --config argument | |||
*Considering that people willing to use multiple instances on the same machine should be using a HDD or SSD, putting in some extra_space_gb should work well for them. | |||
From a default RMS install, open a terminal | |||
$: ‘sudo pip3 install virtualenv-clone’ | |||
$: virtualenv-clone vRMS <new env-name> | |||
Note: the new env directory must reside at the same directory level as your base RMS install, e.g. | |||
If by default you have the initial RMS installed to | |||
~/source/RMS | |||
then create a new directory for the 2nd one as | |||
mkdir ~/source-2 | |||
$: cp -r source <source_new-env-name> | |||
$: activate <new env-name>/bin/activate | |||
$: cd source-<source-new-name>/RMS | |||
Then edit .config to reflect - | |||
* Location | |||
* 2nd camera details, ip address etc | |||
* RMS_data store directory | |||
*...and depending on your data directory if as I do, you use a separate directory on a common fileshare for storage then you might want to adjust the max-free amount to reflect the potential doubling of space free required for a successful nights capture (@25fps & 2 cameras I set this to 40Gb) | |||
You'll also need to edit any of the 2nd env's scripts you need to use e.g. | |||
Scripts/RMS_StartCapture.sh - | |||
to reflect new virtual env as opposed to the default (vRMS) and launch the script as follows to background it and detach if you wish to | |||
run the capture process headless - | |||
nohup ~/source-2/RMS/Scripts/RMS_StartCapture.sh >/dev/null 2>&1 & | |||
''Note: This feels very much like the sort of instructions a person familiar with Linux and RMS could use to get multiple cameras working - lets us imagine that the audience is a STEM class that is building a set of six cameras for an all-sky coverage station, who are coming at RMS for the first time and are relatively unfamiliar with Linux having come from an iOS/Windows world - how can we lay out the steps for converting a single camera config into a multiple-camera config in such a way that they will have immediate success?'' |
Revision as of 17:23, 8 March 2022
Installation for Linux
The scripts linked below have been tested under Ubuntu 20.4 LTS and 20.10, Debian 10 (Buster) and an additional version for Debian 11 (Bullseye) All will work fine for both desktop and server variants and likely other Debian based distros like Mint.
Because of package name differences and in Buster the broken state of the xcb-utils package the installer is hard-coded to detect either of these distro variants and install the correct packages, so if you want to install to some other flavour then you'll likely need to roll-your-own, albeit the install script will give you a good starting point.
To start, download both of the following to your home directory (~/) For 'Buntu and Debian 10 -
For Debian 11 only -
wget https://gist.github.com/edharman/2c1a74f86ca7d545dc6277498feb59f5
For all variants -
You should have 2 new files in your directory-
install.sh
opencv4_install.sh
Next -
chmod +x *.sh
You may want to edit the opencv4_install.sh to both reflect the GPU you may be using and optimise the compile time by adjusting the number of threads/cores to use whilst compiling - this is controlled by the line
make -j4 -- 4 being the No. of threads to use
If using an NVIDIA GPU you'll need to google for the device specific instructions and compile flags..
By default VAAPI support is assumed and both gstreamer and ffmpeg capture enabled, so if you are using Intel chipsets with Iris integrated GPU's you are good to go, albeit you will need to install the Intel drivers and VAAPI support Ubuntu instructions [1]
The install procedure at some point clones the opencv repository which itself contains an opencv4_intall.sh which is not optimised for Intel chipsets, however this install script will copy the one from your home directory and execute that instead.
Next execute the install script -
./install.sh
You will immediately be prompted to enter your sudo password before the procedure continues....
If you are installing on a Debian distro the script will then run without intervention to completion, if using a Ubuntu distro you will at some point be prompted to accept an EULA licence for the TrueType fonts install.
If you are installing onto a server variant and likely in an SSH'd terminal you likely have not got mouse support in your terminal window, so to navigate the EULA screens -
At the first screen, hit the tab button and the <OK> box should be highlighted red, then hit return.
At the second screen hit the tab once and the <Yes> option should be highlighted in red, then press return - the install process will then continue to completion.
The install script may take some time dependant on the hardware you have, I have tested this on an Intel i3 physical server and on an i6 running VM's under Hyper-V and on the latter with 10 threads enabled the install time is under 30 minutes, YMMV..
Upon completion (and I am assuming a headless 'server' distro install) in the shell window -
source vRMS/bin/activate # to enter the vRMS env
cd source/RMS # to enter the default working directory
Next steps are to edit and customise your .config file to reflect your station location, camera config and storage directory and any other site specific details -
nano .config
Assuming you are using an IP camera the capture device string will be something like -
1. using gstreamer with VAAPI acceleration -
device: rtspsrc location=rtsp://<camera-ip>:554/user=admin&password=&channel=1&stream=0.sdp ! rtpjitterbuffer ! rtph264depay ! h264parse ! vaapidecodebin ! videoconvert ! appsink
2. Alternatively using FFMPEG with no hardware acceleration -
device: rtsp://<camera-ip>:554/user=admin&password=&channel=1&stream=0.sdp
Save the .config and test that you can see the camera stream -
On a desktop run the ShowLiveStream script by clicking on the icon
On a headless machine (and assuming you have X-11 forwarding support and a remote X-11-Server on your desktop , more on that in another post here...
In the shell terminal -
python -m Utils.ShowLiveStream
...after a few seconds whilst cython will check it is up to date you should see a new window open showing the live stream..
Hitting CTRL-C in the launch window will kill it...
To start a capture - On a desktop install click the RMS_StartCapture link on the desktop.
On a headless system I use -
nohup ./Scripts/RMS_StartCapture.sh &> /dev/null &
This redirects stderr & stdout to /dev/null (i.e. throws it away) and the final & backgrounds the process so the you can disconnect the terminal session and leave the process running.
To run SkyFit2 -
python -m Utils.SkyFit2 <path to .fits capture directory>
I find this is pretty quick and responsive even on a lowly i3 processor and running headless.
Multiple Camera Configuration
This section is a work in progress and until this notice is removed, should be considered a draft pending testing for verification and validation.
Some contributors want to run multiple cameras; this is the recommended way to achieve this on a Linux machine.
Hardware requirements
A Raspberry Pi 4B has insufficient resources; a mini-PC is required as a minimum platform.
For the benefit of standardization for new off-0the-shelf/turnkey systems, do we perhaps suggest looking at such platforms as the M1T, ZX01, or MeLE Quieter2 and note that use of any available PC platform is more than likely adequate?
Strategy
Use a single vanilla RMS install but launch the StartLiveCapture script with a --config <path to your stations .config file> This requires that you place each instances .config file into a unique directory since the filename is hardcoded.
Drawbacks to this method are
- There is potentially a race condition when at the start of a capture RMS looks to see if there is enough free space for the nights capture (also depending on your storage layout you may also have to increase the extra_space_gb parameter)
- Not all of the RMS scripts support the --config argument
- Considering that people willing to use multiple instances on the same machine should be using a HDD or SSD, putting in some extra_space_gb should work well for them.
From a default RMS install, open a terminal
$: ‘sudo pip3 install virtualenv-clone’ $: virtualenv-clone vRMS <new env-name>
Note: the new env directory must reside at the same directory level as your base RMS install, e.g.
If by default you have the initial RMS installed to
~/source/RMS
then create a new directory for the 2nd one as
mkdir ~/source-2
$: cp -r source <source_new-env-name> $: activate <new env-name>/bin/activate $: cd source-<source-new-name>/RMS
Then edit .config to reflect -
- Location
- 2nd camera details, ip address etc
- RMS_data store directory
- ...and depending on your data directory if as I do, you use a separate directory on a common fileshare for storage then you might want to adjust the max-free amount to reflect the potential doubling of space free required for a successful nights capture (@25fps & 2 cameras I set this to 40Gb)
You'll also need to edit any of the 2nd env's scripts you need to use e.g.
Scripts/RMS_StartCapture.sh -
to reflect new virtual env as opposed to the default (vRMS) and launch the script as follows to background it and detach if you wish to run the capture process headless -
nohup ~/source-2/RMS/Scripts/RMS_StartCapture.sh >/dev/null 2>&1 &
Note: This feels very much like the sort of instructions a person familiar with Linux and RMS could use to get multiple cameras working - lets us imagine that the audience is a STEM class that is building a set of six cameras for an all-sky coverage station, who are coming at RMS for the first time and are relatively unfamiliar with Linux having come from an iOS/Windows world - how can we lay out the steps for converting a single camera config into a multiple-camera config in such a way that they will have immediate success?