Friday, April 17, 2015

The computer network in space - Part 1!

First in flight


First in flight is the (unofficial - official is "Esse quam videri") North Carolina motto.

Our launch is not a first in flight from a HAB (high altitude balloon) perspective (see also: "Rocket man and the Near Space Circus"), but the mechanical aspects (see also the article on our self-leveling rigging: "learn from the past - 103 years old technology in space"), hardware and network topology and innovations packed in the software will definitely be first in flight.(Launch is now D-1, April 21st from Mocksville)

Team Near Space Circus HAB "NSC01" ready to launch

Done

  • Sending micro controllers into near space to take measurements? Done.
  • Sending a raspberry pi with a camera module into near space? Done.
  • Sending multiple gopros into near space? Done.
  • Taking pictures from near space? Done.
Anything left to do that hasn't been done?

Genesis of NSC01


One would think there is nothing left to do that has not been done before. Really, launching weather balloons for gathering data and taking high altitude pictures has been done many thousands of times before, even well before the age of the digital camera.

In fact, in NASA technical memorandum TM X-2208 published in 1971, it covers flights done in the later part of 1969 by the Langley Research Center in Virginia. This served as inspiration as to part of the payload for our own launch, an homage if you will. In this flight, they used medium format film cameras, both in the visible spectrum and the infrared.

So we started with that concept, we will have a Raspberry Pi with an infrared (PiNoir type) camera, and another with a regular CSI camera. Plus a very analog tech which I'll cover in Part 3.

And we quickly realized that we just opened Pandora's box... Innovation was possible everywhere we looked.

Eye in the sky


In my collection of Raspberry Pi related stuff, I had a few cameras already, including one infrared with an S-mount and lens. For a first flight, we could have simply gone with that and a regular raspberry pi camera (with its neutral lens which is not bad at all quality wise; neutral lenses are relatively easy to make compared to wide or tele lens). But we really wanted a wider shot, particularly as the 1080p video is cropped and gives even less coverage.

I didn't want to destroy the other modules to add the S-mount (commonly used on CCTV cameras), so I opted instead for a magnetic mount with a conversion lens. That way the camera can be used without conversion lens, or with a telephoto, wide or even a fish eye conversion lens.

Fish eye, wide, S-mount and magnetic mount RPI cameras

Of course, most people discard conversion lens as junk. And optically, they are terrible, with lots of barrel distortion and other issues. In fact, barrel distortion is easy to see on videos on youtube taken with wide (it is the built in lens actually) lens "extreme sports" type of video cameras that are so popular. The closer to the edge, the more it distorts.

But this was not going to be a show stopper for us. With the right software, I was convinced we could get some really decent shots. So I mounted a camera with a wide angle lens on top of the raspberry pi case, powered the pi with my phone spare battery pack (with a micro USB lead) and took pictures to calibrate my software (written in Python) and then went downtown Winston Salem to take pictures of buildings with lots of horizontal and vertical lines. Distortion is easily seen there.

And the results were quite nice:

Raspberry Pi camera with low cost wide angle, software corrected



What is left is the normal angling of lines due to perspective, but barely any lens distortion. Nice. Now let's move on to the computer.

Like groceries


So, a HAB with a few computers is like doing groceries for a family with a few kids. The more kids, the more expensive it gets. A single Raspberry Pi model A+ is only $20 plus shipping. And we knew from day 1 that we would use two of them. At a minimum.

Then we started looking at options to mount 4 cameras on the payload. For 360 panoramic pictures... Well, with the wide angle lens we used we'd need 5. But 6 is a nice round number, and due to crop factor of the 1080P mode, just making 360 degrees. How to connect 6 CSI cameras to 2 Raspberry Pi?

Plan A was building or buying a multiplexer. But time ran out for building, and we couldn't buy a real multiplexer. We did have a CSI switcher (made for 4 cameras per board) that I had ordered from Turkey. I had it in hand, but it never did work. I tried to get a replacement but the vendor never contacted me back. Caveat emptor.

Plan B was 1 Raspberry Pi per camera. And we had 6 regular cameras for the 360 panoramic, and 1 infrared CSI camera facing downward. So 7 Raspberry Pi it is...

Imagine your grocery bill with 7 kids...

Micro SD in their numbered SD adapters to avoid confusion

And so it went for our project. 7 Pi, 7 cameras, 7 micro sd memory cards (a mix of 32GB and 64GB cards), enough battery power for all of that. Oh yeah, power...

12V != 5V


We figured that for all the gear we would have onboard (7 Raspberry Pi, 7 CSI cameras, 1 USB camera, 2 GPS, sensors, 1 APRS transmitter doing 10W bursts every 2 minutes), we would use 3S (3 cells is series) Lithium Polymer batteries, commonly used in RC and drone applications.

Two 3S 4000 mAh LiPos with XT60 connectors; cameras

We went with two, in order to make it easier to distribute the weight and redundancy. But that meant connecting them together in parallel. This was perfect for the APRS transmitter (transmitting our location, voltage and temperature every two minutes) as it expected a 12V source.

The two LiPo batteries connect on this side

But the Raspberry Pi expect 5V, not 12V. So we added two UBECs. These are switching voltage regulators. They are not really designed to run in parallel, but we ran them for 12 hours straight many times with no issues. Look on RC forums, people say you cant do it. Well, you can. They do lose some of their efficiency that way, because they use PWM to regulate their output and measure their output as part of that. When 2 are in parallel, the output of one interferes some with the feedback loop of the other. Still, we were ok to lose some efficiency for redundancy.

5V UBECs (switching, not linear)
And we needed an octopus loom with 7 microusb to distribute the 5V to the 7 Raspberry Pi. It's about as light weight as we could make it... We did try to connect directly to GND and 5V on the GPIO header, but when it came time to network the 7 Pi together, it caused some issues. I'll talk about that in Part 2.

Power distribution to 7 Raspberry Pi

Where is the network?


I did say we had a computer network we were sending into space, didn't I?

Raspberry Pi #1, 2 and 7

And I'll leave you today in conclusion of part 1 with a shot of the 7 Raspberry Pi networked inside the payload.

All 7 Raspberry Pi before the power wiring harness is put in place


Part 2 will go into the details of the network itself (article is now up: http://raspberry-python.blogspot.com/2015/04/the-computer-network-in-space-part-2.html), the master/slave component and the deadman's switch (now up, also) and part 3 will talk about the data gathering aspects. And in the interim, try to guess how we are networking the 7 Raspberry Pi.

And you can track our first launch progress (and real time data on the day of the launch) by keeping an eye on #NSC01 on twitter, following @pyptug or myself.

Francois Dion
@f_dion

[Update: added links to part 2 and to the deadman's switch]


1 comment:

Unknown said...

How did you get linear velocity? Did you take angular velocity from the gyro and convert that to linear velocity? If so, can you explain how you did it or give a link?