Asteria Network

The Perseids this year were quite a spectacle! Our network is slowly growing and how we have around 10 cameras all over the World - here are images from 3 cameras in Canada and Croatia. About 300 to 400 meteors were detected per camera on the night of the Perseid maximum.

Elginfield station, Canada, IMX225 camera

Tavistock station, Canada, IMX225 camera

Hum station, Croatia, Hikvision Full HD camera

Our experimential system with an IMX225 IP camera detected 102 Lyrid meteors in the last 2 nights! The image below shows a stack of all detections.

The concentric circles are stars, the Polaris is in the centre of the image.

The Lyrids come from a long-period Comet C/1861 G1 Thatcher and they are the strongest annual meteor shower coming from a long-period comet!

Meteor showers are transient events, but Lyrids are one of oldest known meteor showers, they were first recoded way back in 687 BC. Their activity is usually low (about 20/hr), as it was this year, but sometimes we witness Lyrid meteor storms with over 100 and up to 700 meteors per hour!

Very soon we are planning to publish details about the IP camera setup and the instructions how to build one yourself. We will also describe the calibration procedure and show that our system can produce science-grade data!

Stay tuned!

We've been very hard at work in the last 2 years, and we have finally completed the first RPi meteor camera system which is plug n' play and fully automatic!

Software is thoroughly tested and fully automated, we have upgraded to a RPi3 and a very sensitive IP camera.

The starting price is only 350 CAD (280 USD, 225 EUR) and the listing can be seen on eBay and will be up for a week! Here's the link: https://www.ebay.ca/itm/173143605844?ssPageName=STRK:MESELX:IT&_trksid=p3984.m1558.l2649

After this system is sold, we'll assemble more and put them up for sale as well. This is the beginning of our dream of a truly global and open meteor network!

Here's what you get in the kit:

• Raspberry Pi 3 in a case with a fan + 3.0A power supply
• 64GB U3 MicroSD card with Raspbian OS and meteor detection software
• Low-light 720p IP camera with a 4mm/f1.2 lens (sees +5M magnitude stars) in a waterproof enclosure (heater+fan)
• Heavy-duty mounting arm
• Power-over-ethernet (PoE) injector
• Waterproof ethernet connector protector

Dear followers, it's been a long time since out last post and we are sorry about that!

Just after the last post we went to the International Meteor Conference in Mistelbach, Austria and presented this project to more than a hundred meteor enthusiasts from all over the world! We had a lot of fun at the conference and got very positive feedback from a lot of people about this project. Everybody's keen to have a modern low-cost solution for their meteor astronomy needs. During that time we have been busy with writing the conference paper for the project which you can download here.

IMC2015 participants

Shortly after the conference, classes started at our universities so we didn't have much free time to continue working on the project.

At the beginning of December we finally started to make some new progress. A lot of old codes were rewritten, and now the code is more structured, it is better documented and the most computationally intensive algoritms are rewritten in Cython. This now forms a better foundation for future work.

Also some progress has been made with the detection of fainter meteors. We still need to put a lot of work into this so the algorithm will be robust. You would be amazed by a wide variety of meteor types. And not to forget a lot of interference like birds, bats, planes and clouds.

During the following months we will put in more work into this project and keep you informed!

One of the most exciting things in meteor astronomy is the possibility to use video meteor observations for meteorite recovery. In 2011, the Croatian Meteor Network was the first amateour meteor network which achieved this by finding the Križevci meteorite.

As it is impossible to store raw video data with this kind of low-cost system, we perform a unique kind of compression (described in the previous post). As the compression stores only the brightest pixels in a 256 frame block, very bright fireballs can often badly suffer from artifacts produced by this compression method, as there are several moments when a pixel has a certain maximum value (we call the problematic frames “space invaders” - they are shown below the fireball).

Thus we needed a quick way to extract raw video frames of a fireball while they are still present in the memory. As the data is compressed in real time, we decided to use freshly compressed files for fireball detection.

Here are the fireball video extraction steps:

1. The data is thresholded to extract only very bright meteors (aka fireballs) which are 4 standard deviations above the background intensity
2. The image is divided into 16x16 pixel blocks, and blocks which contain an amount of bright pixels above a certain threshold are marked as bright pixels on the subsampled (45x16) image
3. As the compressed files contain information about the time (maxframe image), meteors can be show in 3D space (X, Y, time)
4. Using our algorithm (details are given in the Appendix), lines in 3D space are found and line parameters are calculated
5. 80x80 (or larger, depending on the fireball brightness) crops are extracted from individual raw video frames and saved to the disk

The following animation shows the result of the fireball detection process.

This process enables to have raw video frames which can be used for precise fireball analysis, without saving huge amounts of raw data. We have successfully tested this method and were able to detect and extract a wide range of meteors - from high luminosity fireballs to 0 magnitude meteors. A separate detection process is preformed for even darker meteors which will be described in one of the following logs.

Appendix: Finding lines in 3D

Finding lines in 3D space in real time on a device with such a low processing power is not a trivial task. Thus we have reduced the number of search points using the 16x resampling method, which was inspired by Peter Gural’s AIM-IT system.

The main concept of the algorithm is to pair two points from the given point cloud, fit a line through them and see how many points are there in a given cylindrical volume around the line. The best solution is taken, its points are removed from the point cloud and the process continues iteratively while there is still a significant amount of points left. The solution is evaluated based on the following criteria, each with their own weight:

• how many points are there inside the cylinder
• how distant are the points from the fitted line
• how distant are the adjacent points

If the adjacent points are too far away, the solution is discarded as this means the gap between them is too large to form a plausible meteor path.

As the search space consists of both spatial and time components, and it can be assumed that the meteors are transient events which progress in time, the algorithm is optimized to pair points which are not in the same time plane or the ones before.

The algorithm is currently implemented in Python and limited to 200 points per one image. When there are more than 200 points in the point cloud, 200 are chosen at random. The C implementation of the algorithm would surely be several orders of magnitude faster - we leave this for some later versions of the software.

The algorithm is quite robust, insensitive to outliers and noise. It can even detect meteors which are partially obscured by trees!

Now that the question of capturing the data with the RPi2 is resolved, a question of data compression arises. If you were to save uncompressed video on a disk using the current setup (720x576 @ 25FPS), during an average night of 12 hours you would end up with >400GB of raw data.

So it is clear that some kind of compression should be used. Usual lossy video compression methods are trying to reduce redundancy in video data to suit human vision. Regarding video meteors, the problem is more complex - you need to do your best to preserve meteor features (spatial and temporal resolution and pixel intensity) so you can do meteor detection later.

Usual video meteor setups have wide-angle lenses and relatively small resolution cameras. Our setup has a 64°x48° field of view and 720x576 camera resolution, which gives a plate constant of about 5 arc minutes per pixel. If you consider that an average meteor is at about 100km distance, one pixel corresponds to ~150m at that distance. This means that the real position of the meteor is actually quite uncertain and you shouldn’t compromise the spatial resolution any further.

The method we use was first developed by Mark Vornhusen for his Skypatrol software, and later extended by Peter Gural for use with NASA CAMS meteor network. In essence, you are taking 256 raw video frames (10.24s at 25FPS) and saving only the brightest pixels as you can assume the meteor was the brightest event in that portion of time. In addition, you track when the brightest pixel occurred (coded as an 0-255 intensity which corresponds to the frame number), the average pixel values and their standard deviation.

compressed image of a fireball

reconstructed video from compressed image

Thus you have reduced 256 frames to just 4 images (1:64 compression ratio) which you can use for meteor detection as the standard deviation can help you determine what is a meteor and what is the background.

tresholding (used for detection)

Having a $100 meteor station in our hands (check out our first log), we realized there is a broader issue with meteor astronomy that could be solved. Currently, there are many separate meteor networks, often on national levels. Each one uses different combinations of software, data reduction routines and storage format. Paradoxically, data is often shared by amateur networks, while government funded (with public money!) networks keep their data as a hidden treasure.

Meteor radiants plotted on a map of the whole sky (SonotaCo and CMN data). Meteor showers are represented by high-density areas of the same color (Perseids are the orange blob at the upper-center).

Regardless of what we humans think, universe doesn’t care about national borders. If we were to set out to understand meteors, and through them our Solar System, these limitations cannot get in our way. A truly global network is needed. Such large network raises problems that can only be solved with community effort and open solutions. We are strong proponents of open data, which is still a taboo topic in meteor science.

As the goal price of a single system is very affordable, we hope that many amateur astronomers, hackers, citizen scientists and students will be interested in the project. The system is envisioned to be very simple to install, use and maintain, with minimal knowledge of astronomy and computer use. We aim to expand that knowledge and introduce people to science and show them the importance of meteor astronomy and foremost - programming.

We want to provide every high school or university that is interested one or more of these systems, and form a student science team which will work on data collection and processing. As the data will be shared via a central data hub, groups will be encouraged to cooperate with other participants on the project.

… that never was the question. Rather, the question was which SBC shall it be?

During the last year we have tested quite a few Single Board Computers, as our project has specific requirements. During that time, SBCs have evolved enough to satisfy our needs. In this post, we’ll try to chronologically document our experiences with different boards.

Raspberry Pi B

Being the most popular SBC at the time, it was obvious we had to test it. Unfortunately, RPi still had serious USB issues and fairly limited computing power (700MHz single core CPU, 512MiB RAM). With that hardware, we couldn’t reliably capture video with USB frame grabber device nor perform real-time compression. Although there is powerful GPU present (24 GFLOPs), there was no way to utilize it.

Banana Pi

Shortly afterwards, Banana Pi came out. The same price range as RPi B, but with a 1GHz dual core CPU and 1GiB RAM. Also, there was a SATA port for HDD. We thought that it will surely be able to do capture on one core and compression on the other. If we could just get that USB frame grabber to work…

Raspberry Pi 2

After some time, RPi2 came out. With 900MHz quad core CPU, 1GiB RAM and most importantly a strong community, it caught our attention. This time, we tested it with different USB capture hardware, finally finding an acceptable solution. At that moment software development started and software is growing rapidly ever since. Not only that we had to settle on the capture and compression solution, which would still require us to do detection on a separate machine, but it was possible to completely match capabilities of desktop machines with previous software solutions. Furthermore, we still had enough processing power left to implement new features.

Same powerful GPU as on RPi B (VideoCore IV) was still used on new board. Turns out that it it’s possible to do some general purpose computations on it, certainly it’s not an easy task. Raspberry Pi Trading: please include OpenCL in next generation RPi! :)

Odroid C1

Although we were already deep into development with RPi2, we still wanted to test other available hardware. With same price of $35, but 1.5GHz CPU, Odroid C1 definitely was worth a shot. Amount of available RAM is equal as in RPi2 (1 GiB), but divided across two chips.

Surprisingly, our compression timing tests showed that it’s actually slower than RPi2 (we’re running RPi2 @ 1GHz). We guess that this is caused by different core (A5 versus A7) or RAM frequency. Another issue is that the very moment when RAM fills up over 512 MiB, it suddenly crashed. The problem here is most certainly in 2 RAM chips and bad memory management between them.

Orange Pi Mini 2

$25 for a quad-core Cortex A7 @ 1.6GHz CPU?!? We had to try it. It crashed as soon as we started our timing tests and CPU core went to 100%. Turns out that placing your finger on SOC is same as touching a hot oven. Coolers didn’t help. We didn’t found a way to limit the CPU freq. We’ll post an update when we get our hands on liquid nitrogen…

Conclusion

We decided to use Raspberry Pi 2 as the heart of our station as it ticks every single box on our requirements list. Our software will perform faster on next-gen SBCs, but for now we’ll stick with RPi2.

Linux-suxi project seems promising, but the list of officially supported hardware is quite small, with devices mostly having a higher price and lower processing power. Banana Pi M2 and Banana Pi M3 might be interesting with OpenCL, but community support is nowhere close to the RPi.

Our friends at American Meteor Society have made an excellent poster explaining different terms used in meteor science:

At Croatian Meteor Network, we have always strived for a meteor station to be as cheap as possible. By doing so, network quickly grew to over 20 stations. Having multiple stations covering same volume of Earth’s atmosphere allows precise orbit calculation. Over the years tedious task of manually examining and processing each image was replaced by automated software. Thus, focus has changed from data collection to data analysis. This has led to more than 100 new meteor shower discoveries.

But, there has never been complete satisfaction with capture hardware nor software. Current software solutions are often expensive and/or supporting only specific hardware. Most of the software is written for Windows machines, with few exceptions. Almost certainly, software is closed-source, no matter how advanced.