Introduction: Wireless All Sky Camera
An all sky camera is a device designed to take pictures of the entire sky over a certain amount of time, usually to monitor meteor showers or other astronomical phenomena.
I built mine to monitor the northern lights. I live in the Yukon and we sometimes get beautiful aurora displays during the night. However, I also have a day time job and I need my 8 hours of sleep. I created this camera to record a movie of the entire night. That way, I can replay the movie in the morning and never miss any aurora night.
Step 1: Requirements and Materials
My requirements for this camera are the following:
- needs to photograph most of the sky
- needs high sensitivity to low light
- should be weather proof
- no wires should run to the house
- needs to be autonomous
- needs to create a movie from pictures and upload it to the internet
- needs to start at dusk and stop at dawn
After thinking about it for a while, I decided that the device should include its own computer and send the pictures using wifi. As for the camera, I decided to use an astronomy camera that would be small enough and was powered over USB.
Here's the list of materials:
- ASI224MC camera from ZWO (ASI120MC or MM works too and is cheaper)
- wide angle lens Arecont 1.55 (It gives a wider field of view than the lens that comes with the camera)
- Raspberry Pi 2 (or 3)
- 64 GB micro SD card
- Wifi module (no need if Raspberry Pi 3)
- Short right angle USB cable
- 4" ABS pipe with end caps
- Acrylic dome
I thought about adding a dew heater but after a few month of testing, I never got any frost on the acrylic dome. This is possibly due to the heat produced by the raspberry pi itself.
Step 2: Wiring
In this instructable, I will assume that you already have raspbian installed on the SD card.
The wiring is relatively easy. Plug the USB cable to the camera on one side and the raspberry pi on the other. Plug the wireless dongle into one of the 3 remaining USB ports of the pi. Insert the micro SD card in its slot and plug the raspberry pi to its 5V adapter.
In order to keep things tidy, you can fix your camera and computer onto a plywood board like I did on the picture.
Step 3: Build the Enclosure
The enclosure is made of a 4" ABS pipe, a flat end cap and a threaded end cap with its lid.
The flat cap goes on top and is drilled to the diameter of the camera. The threaded cap goes at the bottom and a hole (for the extension cord) is drilled in the centre of the lid.
The acrylic dome can be fixed onto the top end using weather proof silicone. I used an acrylic ring but it makes things more complex than they need to be.
You can now fix the enclosure onto your deck, your roof or any other location with a good view of the sky.
Step 4: Software
Update: If you need to change the way the capture works, you might have to make changes to the C++ source and compile it on your Raspberry PI. To do this, follow PeterD192's detailed instructions in the comments.
Update 2 (Nov 11th 2016): I have set up a GitHub page with an install script to make things easier for everyone: https://github.com/thomasjacquin/allsky If you use it, you shouldn't have to use any of the following instructions.
In order to capture images with the camera, we need to run a program in the terminal. ZWO provides an SDK in order for developers to communicate with the camera. Using this SDK, I modified one of their C++ example and compiled it for the raspberry pi. Here's a list of dependencies that need to be installed in order to get the program running.
- OpenCV to capture the image of the sky (You can get a compiled version here)
- Sunwait to calculate the civil twilight of your location. There is a compiled version in the archive. Make sure you copy it to your path:
sudo cp ~/allsky/sunwait /usr/local/bin
- Required dependencies:
sudo apt-get update && sudo apt-get install libusb-dev libav-tools gawk lftp entr imagemagik
To make things easy, I have attached an archive. Extract it at /home/pi/allsky.
From the lib folder, you will need to run this in order to use the camera without being root:
sudo install asi.rules /lib/udev/rules.d
You will also need to add libASICamera2.so to your library:
sudo cp ~/allsky/lib/armv7/libASICamera2* /usr/local/lib
Another thing you will need to do in order to automate everything is to run the main program on startup of the pi. You can open ~/.config/lxsession/LXDE-pi/autostart and add this line:
@xterm -hold -e ~/allsky/allsky.sh
Remember to set your wifi connection in order for the pi to upload videos.
allsky.sh contains all the parameters you might want to play with: GPS coordinate, white balance, exposure and gain.
Step 5: Collect Images
Now that the raspberry pi is ready, you can plug your all sky camera. The startup script should call allsky.sh which in turn calls the binary file named "capture". It will determine if it's day time or night time. In case it's night time, the capture will start and take a picture every 5 seconds (or whatever value you set in allsky.sh). At the end of the night, the capture will stop and avconv will stitch them together and upload a video to your website using FTP.
Step 6: Watch Your Time Lapse Videos
The video produced by avconv should weigh between 30 and 50 mb depending on the length of the night (here in the Yukon, we can get from 18 hours to 0 hours of night time) and should be viewable on any web browser.
In the event that you find something interesting in the video, you can access the individual images on the raspberry pi. They will be in a folder named after yesterday's date.
Here's a page showing my own videos with almost all night archived starting January 18th 2016. Some have beautiful northern light, others have clouds, snow or rain.
First Prize in the
Space Contest 2016
13 People Made This Project!
We have a be nice policy.
Please be positive and constructive.
Hi, Thomas. Great share of info.
I am using asi120mc, downloaded allsky.git. followed all through your instruction.Key in Lat Long number. Key in ftp server login . choosen GUI
rebooted. screen showing allsky.sh running. detected asi120. saving 5s exp image every 10ms. press Ctrl C to to stop. and cd '..allsky/' [connecting....]
i go to my ftp server. i didnt se any images uploaded. i go to var/www/html/images or img , also no new image file being uploaded or created
i am lost. please kindly help . thank you
Hi Louis, the images are saved in the following directory: /home/pi/allsky/images/
If the image wasn't uploaded to your server, it's probably an FTP configuration issue. Have you connected to this server before? If not, try to ssh to it in order to add it to the known hosts:
Run ./allsky.sh again and wait for the ftp debug information to show up in the terminal. It will tell you if the transfer worked or failed.
Setting up a second (colour) unit based on 178MC. Everything seems to be working fine except the timelapse creation is not working (creates 0 length mp4 file). If I run avconv command manually, I get this error:
frame= 42 fps=1.8 q=0.0 size= 0kB time=00:00:00.00 bitrate=N/A speed=
frame= 43 fps=1.8 q=0.0 size= 0kB time=00:00:00.00 bitrate=N/A speed=
frame= 44 fps=1.7 q=0.0 size= 0kB time=00:00:00.00 bitrate=N/A speed= x264 [error]: malloc of size 20515824 failed
Video encoding failed
[libx264 @ 0xceda40] final ratefactor: 30.79
This is the manual command I am using:
pi@allsky:~/allsky $ avconv -y -f image2 -r 25 -i images/20180410/%04d.jpg -vcodec libx264 -b:v 2000k -pix_fmt yuv420p images/20180410/allskytest-20180410.mp4
individual images did get numbered sequentially and there are no 0-size files. They are all jpg's.
I'm still trying to figure out how the instructables comments threads are organised. I think my answer is still here but kind of hidden. I had to expand an arrow to see it.
Anyway, yes you can resize the images using the Image Magick's 'mogrify' command. Instead of creating a whole new set of scaled down images, it overwrites them. Here's the doc:
You could probably call the command at line 17 on timelapse.sh
Hmmm, Thomas's answer from yesterday seems to have disappeared? Anyway, you were right on the money Thomas. Images are the full 3096x2080 (~1.8M files). And the memory does drop from around 700MB to about 30MB before error (usually gets to about 40+ frames). Interestingly, when I watch the memory use on my 290MM based unit (smaller sensor/file sizes), the free memory also drops from 600-700MB down to 20-30MB (and stays in the range) , but it does not error out.
I found these references:
So I tried increasing the CONF_SWAPSIZE from 100 to 1000 (swap space on SD Card) and it worked. However, the timelapse creation takes much longer to complete (3-4 hours). Not a problem for me as my Pi has nothing else to do during daylight hours!
However, downsizing the images before timelapse processing might be a more elegant solution (as you suggested). Any suggestions on how to downsize images on-the-fly before being fed into avconv? Perhaps an imagemagik command?
I am having a similar issue; real long time to make movies, sometimes works, sometimes it just hangs. I am using an MC120 so my image size is only 1280x960 but still have issues. I am using the same code as above. I get a warning "deprecated pixel format used. make sure you did set range correctly" but it gets past that. It starts running frames and starts to hang around 50-60 frames into the process. I will try running 'top' in another terminal.
I did a reboot on the RPi and it seems to be running better. I am actually running avconv while I am remote desktoped (xrdp). TOP says avconv %cpu 392 (?) %mem 37.9 The CPU chart at the top is mosly maxed out. the %cpu line in TOP - 2nd line
$cpu 32.5 us 0.6 sys 65.9 ni 0.1 id 0.0 wa 0.0 hi 0.2 si 0.0 st
meanwhile it avconv task completed in a couple of minutes, so I am not sure what the issue was?
Hey Dave, What's the size of an individual image? Is it the full 3096*2080?
It seems like a memory allocation issue. There's 1GB Ram total on a RP3. I'm wondering whether avconv is trying to use more memory to build the timelapse than there's left in RAM. You can run the command 'top' in a terminal and run avconv in another. Look for the memory usage.
One way to check would be to scale the images down and try running the ./timelapse.sh script manually again.
Hello Thomas, finally it is working, I face only the high CPU load when I am running the graphical interface and having too short timings, so far I did test the camera having too much light, so it was not representative. I addition, I set more appropriate settings for the camera. the latest problem is with FTP, I get a message telling that the name could not le resolved, I did set the IP address, now I change it by the server name, I will see if it works. Using intercatively the ftp client it is working. I will tell you if I face other problems. So next step, is to build the enclosure, once done, I will install it outside.
I let you know when is works so you can add one more location on your map.
Thank you very much for your valuabe support and best regards.
The cpu is going to more than 80%, all is slow. I test the ASI102Mc with OACapture installed in PI 3, working more or less fine, sometimes the picture in unstable, I would like to know if thos eproblems are only with the ASI120MC, what you write is that with the ASI224MC it is working fine, if it is the case I purchase the other one. I juste want to have the AllSky camera working and user what you have so well developped. Thank you for your feedback. Best regards. Daniel
I will check my CPU load tonight. In the meantime, you can type "top" in a terminal to see which process is taking all the cpu.
Dear Sirs, I have finaly get some images using the ASI 120MC, but the PI3B I am using, is sometime overloaded, what is not a good sign, is the problem only with the model 120MC or is it with all ZWO models? I test on the RPI3B an ATIK GP camera, it was working fine without any problem, Could this camera be used for the AllSky application? Thank you very much, I am not a Linux specialist, so some question I can have will sound basic. Best regards
When you say overloaded, what do you mean exactly? I do not own an ASI120MC but I know it works fine with a P3 and ASI224MC. In theory, the ATIK camera could be used but it would require a custom capture.cpp using ATIK's SDK. Currently, the app is only using ZWO's SDK.
I've installed on a Pi 3 with the latest version of Stretch. I'm getting nothing but black images. Not even sure where to start troubleshooting. Camera is a ASI120MM-S
Hi, the logic for day and night behaviour is in capture.cpp between lines 483 and 502.
You can copy lines 484 to 492 into the DAY conditional statement. That way it will save both during the day and at night. However, it will use the same exposure.
ZWO provides 2 functions in its SDK. The first one is the single exposure mode which is the one I'm using. It doesn't have an auto-exposure feature. The second mode is the video mode which has auto-exposure. I haven't tried it yet but I am planning to. It will require a few changes to the .cpp file.
disregard. there is a default image preview and since it was daytime, it wasnt updating the image. Ok, next question, any way to do auto exposure so I can capture during the day? Not too important, but nice to have, and then how do I override the daytime no save?
I've got a pi 3B setup as described in the git readme, all seems to be working for the most part. Poking around I noticed dmesg showing a lot of USB device resets - about every six seconds for device 4 and my exposure time is 5 seconds with 10ms delay. Just wondering if anyone else is seeing these? I haven't tried a different USB port on the pi for the camera yet since it's currently mounted outside.
[Mar19 21:06] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.910084] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.910069] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.900074] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.919992] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.900148] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.910138] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.909947] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.910164] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.910020] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.900001] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[Mar19 21:07] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.910126] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.910071] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.910010] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.910070] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.910099] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.910067] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.910105] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.900006] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.910110] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[Mar19 21:08] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.910023] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.880182] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.909952] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ +5.910091] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
pi@allsky:~ $ usb-devices
T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 1
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=1d6b ProdID=0002 Rev=04.09
S: Manufacturer=Linux 4.9.59-v7+ dwc_otg_hcd
S: Product=DWC OTG Controller
C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 5
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=02 MxPS=64 #Cfgs= 1
P: Vendor=0424 ProdID=9514 Rev=02.00
C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=2mA
I: If#= 0 Alt= 1 #EPs= 1 Cls=09(hub ) Sub=00 Prot=02 Driver=hub
T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=ff(vend.) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0424 ProdID=ec00 Rev=02.00
C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=2mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=ff Driver=smsc95xx
T: Bus=01 Lev=02 Prnt=02 Port=04 Cnt=02 Dev#= 4 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=03c3 ProdID=120a Rev=00.00
S: Manufacturer=ZWOptical company
C: #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=500mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=00 Prot=00 Driver=usbfs
I am also running the120MC camera, I do have those messages but I believe each one has a timestamp and there are so many only after so many times of accessing the camera. Stop the allsky program, and clear the messages with sudo dmesg -c. then start the program again and you will see a reset for each camera access (even if you are not capturing images due to daytime). I have not tried to track this down in the code but I am sure it is there somewhere. It does not seem to effect the performance as far as I can tell
I believe it's happening once per capture cycle (exposure time + delay time), and they are still occurring during daylight hours because the capture code is still doing a capture, it's just not saving the captured image during the daytime. The message is coming from the kernel, and I believe the dwc_otg is related to the pi's USB driver. I also have a ASI290MC and it puts the same messages in the dmesg log. I agree - it doesn't seem to be affecting performance/function other than filling up /var/log/messages.
Thanks for checking - I wonder if anyone else that has a 120MM/MC is getting these? I still need to try a different USB jack an a different pi.
I checked on my camera and I couldn't see any messages like that in dmesg. Does it seem to impact the performance?