rumfart på den anden måde cs banner bloghoved

Sådan sender vi live video fra HEAT2X

Kære læsere,

Hermed en dansk version af Alex Csete's blog om videosystemet på HEAT2X.

Rocketcam 1 er HEAT 2X's on-board kameraprototype. Det er en fugleredeopstilling med tilstrækkelig funktionalitet til at afprøve såvel video optagelses- og kodningsmekanismer som visse aspekter af den trådløse videotransmission. HEAT 2X vil blive udstyret med 3 on-board kameraer, som skal filme henholdsvis motorens udstødning, separationen og Jordens horisont.

At vælge det rette kamera

Én af de største udfordringer i designet af on-board videosystemet er at finde det rette kamera. Ligesom det meste andet i vores projekt er begrebet "rette" et dilemma, hvori indgår flere forskellige faktorer såsom ydelse, pris og størrelse. Heldigvis har vi et sæt kravspecifikationer at holde os til, når vi leder efter det rette kamera:

  • Live output af H.264-komprimeret video. Dette er formentlig det vigtigste krav. Ukomprimeret video i HD-format indebærer flere hundrede megabits per sekund og er ikke videre praktisk at sende via et trådløst link. Med H.264-kompression kan vi pakke det ned til nogle få megabits per sekund og alligevel bevare den gode videokvalitet.
  • Lille størrelse, som er egnet til integration i HEAT 2X. Til trods for størrelsen på HEAT 2X er der i realiteten ikke megen plads. Eller rettere, der er masser af plads; men der er også masser af elektronik, som skal integreres, så vi har virkelig brug for at holde kameraerne så små som muligt.
  • God billedkvalitet. Det er jo et ret subjektivt krav, som er vanskeligt at kvantificere; men vi kan definere god kvalitet som det, vi er vant til fra almindeligt tilgængelige kameraer i lav- og mellemklassen. Alt på samme niveau eller bedre end "YouTube HD quality" vil være acceptabelt.
  • Let at arbejde med. En åben arkitektur med god software og community support vil kvalificere som noget, der er let at arbejde med.
  • Lav pris. Dette krav ligger lige for. Så længe vi flyver med eksperimentelle raketter, må også elektronikken regnes for engangsartikler. Det sætter en naturlig øvre grænse for, hvor meget vi er villige til at bruge på komponenter, som ikke er missionskritiske.
  • Udskiftelig optik. Et nice-to-have-krav, som tillader os at tilpasse kameraet til dets opgave.

Givet disse krav kan vi ret sikkert forkaste specialfremstillede kameraer (dyre), professionelle kameraer (store og dyre) og almindelige forbruger camcorders (intet live H.264 output). Vi står da tilbage med valget mellem IP-kameraer, webcams og såkaldte devcams.

IP-kameraer er kameraer med indbygget netværks stak, hvor styring og video kan tilgås via en almindelig IP-protokol som HTTP eller RTSP. De går fra simple WIFI-baserede baby-alarmer til overvågningskameraer i industrikvalitet. Desværre er den type IP-kameraer, som kunne være interessante til vores brug, både for store og dyre til HEAT 2X-missionen.

Webkameraer er simple og billige kameraer, som man forbinder til sin PC f.eks. mhp. videoopkald med Skype til sin mor, far, hund, kat osv. Webkameraer er udviklet enormt i de allerseneste år. Det har ført til webkameraer, som kan levere H.264-kvalitetsvideo via en standard USB-forbindelse.

Vi har faktisk brugt den slags kameraer til live streaming fra begyndelsen, og vi har opnået betydelig erfaring med dem. På den negative side er de fleste webkameraer optimeret til nær-fokus og deres video engines optimeret til indendørs belysning.

Navnet devcam refererer til forskellige udviklingsmoduler til brug for hobbyfolk og industriel prototypefremstilling. Det er som regel små computer-on-modules med et eksternt sensor board, som kan forbindes via et dedikeret parallelt eller serielt interface. Et nyligt eksempel på et sådant system er Raspberry Pi udstyret med et RaspiCam kameramodul.

Faktisk viste Raspiberry Pi med RaspiCam sig at være en meget interessant mulighed. Til at begynde med var jeg ikke så interesseret i Raspberry Pi med dens forældede ARM kerne, klodsede mekaniske formfaktor, specifikationer under NDA, blob-drivere osv.; men med de nyeste kameradrivere kan Raspberry PI + RaspiCam nu optage kvalitetsvideo op til 1920 x 1080 pixels ved 30 billeder per sekund. Videokompressionen sker i VideoCore-hardwaren, og selvom det stadig er mangelfuldt, er der masser af håndtag til at pille ved kameraindstillinger. Til forskel fra de fleste webkameraer er RaspiCams fokus sat på uendeligt fra fabrikken, og selvom objektivet er lille, tager det gode billeder ved de opløsninger, vi er interesserede i.

Illustration: CS

Rocketcam 1-billede taget fra toppen af HEAT 2Xs servicetårn. Foto: A. Csete.

Den mekaniske konstruktion af RaspiCam boardet gør det relativt let at udskifte objektivholderen, som har M6-gevind, med et adapter til M12- eller C-mount objektiver. Vi har derfor besluttet at bruge Raspberry Pi med RapsiCam til on-board kameraer på HEAT 2X-missionen. Selvfølgelig vil det kræve noget arbejde at tilpasse dem mekanisk og elektrisk til flyvning; men vi har et godt udgangspunkt.

Testopstilling ved HEAT 2X's statiske test

Vi har lavet en testopstilling bestående af et prototypekamera (Rocketcam 1) og DVB-T sender og modtager. Formålet med dette er at:

  • Opnå erfaring med kombinationen Raspberry Pi + RaspiCam.
  • Afprøve hardwarens og drivernes robusthed og stabilitet.
  • Eksperimentere med de mulige videokompressions- og transmissionsindstillinger.

Testopstillingen var klar til den (siden udsatte) statiske test af HEAT 2X. Den kunne ikke monteres på selve raketten. I stedet er kameraet monteret på servicetårnets øvre platform og rettet nedad langs raketten. Det gav et ret pænt billede.

Billede fra Rocketcam 1 som det var placeret ved første forsøg på HEAT 2X's statiske test. Foto: A. Csete.

RaspiCam er forbundet til Raspberry Pi gennem et high-speed CSI interface. Dette interface er forbundet direkte til VideoCoren i Pi's hovedprocessor, som laver noget sort magi, vi ikke skal vide noget om. En simpel open-source applikation ved navn raspivid kan styre kamera og kompressions indstillinger og hente den H.264-encodede video. I denne prototype har vi yderligere to applikationer kørende på Pi: ffmpeg, som giver en DVB-kompatibel MPEG-TS stream, og tsrfsend, som styrer DVB-T-modulatoren. DVB-T-modulatoren er en UT-100C USB-dongle lavet af et firma i Taiwan. Den er meget interessant, pga. dens lille størrelse, og fordi den også virker i 1,3-GHz amatørradiobåndet.

Rocketcam 1 bestående af en Raspberry Pi, et RaspiCam kameramodul, strømforsyning, en UT-100C DVB-T-modulator og en 20 dBm forstærker. Interesserede kan se de tekniske detaljer vedr. at få transmitteren til at virke med Raspberry Pi her. Foto: A. Csete.

Blokdiagram af Rocketcam 1 testopsætningen ved HEAT 2X statisk test. Grafik: A. Csete.

På modtagersiden burger vi en DVB-T modtager (også USB dongle) baseret på en RTL2832U demodulator chip og en R820T eller E4000 tuner chip. Disse modtagere kan købes for 10-20 € og supporterer DAB/DAB+ modtagelse i L-båndet mellem 1,45 ‒ 1,49 GHz. Selvom DVB driverne i Linux er begrænsede til de officielle VHF/UHF DVB-T frekvenser mellem 174 og 862 MHz, er dette kun softwarebetinget, og en simpel modifikation af driverne tillader modtageren at operere i 1,3 GHz amatørradiobåndet. I praksis virker tuneren udmærket mellem 50 MHz og 2 GHz.

DVB-T modtageren er forbundet til en Linux PC eller en Beaglebone med kerne 3.12 eller senere. I den aktuelle testopstilling bruger vi en simpel applikation ved navn dvblast, som tager den komplette MPEG-TS strøm fra modtageren og streamer det til netværksklienter vha. UDP eller RTP. Applikationen kan også præsentere info om modtagerstatus, såsom tilstedeværelse af bærebølge, demodulator lås og signal/støj-forhold i arbitrære enheder. Det er faktisk al den funktionalitet, vi har brug for i modtagersoftwaren.

Foreløbige testresultater

Trods udsættelsen af test-affyringen fik vi mulighed for at teste Rocketcam 1 i løbet af dagene op til og med HEAT 2X testen den 31. maj. Vi fik mange timers trådløse optagelser, hvoraf nogle er uploadet til YouTube.

Kameraet optog ved 3,3 Mbps og MUX rate var sat til 3,732 Mbps. Dette er den laveste kapacitet for en 6 MHz bred DVB-T kanal med den højeste fejlkorrektion og robusthed. Ud fra disse tests kan vi konkludere at:

  • Både Raspberry Pi, RaspiCam og kameradriverne var stabile. De kørte uden problemer, så længe batterierne tillod det (ca. 14 timer).
  • Billedkvalitet og videokompressorens ydelse var meget god og tilstrækkelig til brug for HEAT 2Xmissionen. Dog afhænger den endelige konklusion også af, hvordan sensoren klarer det, når der kommer flammer fra raketmotoren. Det ser vi om få uger, når HEAT 2X motoren affyres.
  • Mens vi fumlede rundt med modtageantennen, bemærkede vi, at RTL2832U demodulatoren var ret hurtig til at locke (~1s). Nu var signalet også meget kraftigt, så denne lock-tid er ikke definitiv.
  • Vi fandt en bug i UT-100C kernel-driverne, som forhindrede os i at justere modulatorens output over hele dens område. Det skal fixes snart (Vi har driverens kildekode).

I mellemtiden fortsætter arbejdet på Rocketcam 2, som funktionelt vil svare til et flightkamera. Det betyder bl.a. at MPEG-TS muxing og RF interfacing vil blive udført på et separat computerboard, og det vil kræve et betydeligt programmeringsarbejde.

Mads Wilson er et af flere medlemmer af Copenhagen Suborbitals, der skriver på denne blog.
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først

Fantastisk.. det er sgu da en teknikbasker der vil noget.. og så noget som aldrig har været belyst før, sikkert pga manglende viden på området.. Jeg er allerde vild med CS-bloggen, hvor vi får CS belyst fra alle siderne.. Det tegner fanme godt!!!

Respekt for jeres evner og gå-på-mod.. C

  • 32
  • 1

Jeg kunne ikke sige det bedre selv!

Det er lækkert at høre at I har fået kildekoden til driverne, og lov til at redigere dem. Det ville være ærgerligt at komme i juridiske slagsmål over sådan noget.

  • 8
  • 0

Fremragende fremlægning, dejligt med detaljer. Dog er jeg lidt forundret over valget af digital video downlink.

Da SpaceX for nyligt "landede" deres Falcon 9 first stage på havoverfladen brugte de ligeledes en digital videostream til downlink. Det giver en fremragende billedkvalitet mens der er signal, men der var stort udfald i signalet ved landingen således at de sidste kritiske sekunder stort set var tabt. Efter omfattende bit-pilleri er nogle dele af signalet møjsommeligt blevet rekonstrueret.

http://www.spacex.com/news/2014/04/29/firs...

Er analog video generelt ikke lettere at få et genkendeligt billede ud af selv med omfattende signaltab? Optager I h.264 media streamen på et lagermedie før transmission?

  • 6
  • 0

Det nydelige ved at arbejde med Linux er jo netop at ting som drivere som udgangspunkt er open source. Alex har skrevet mere om selve øvelsen med driveren på nedenstående blog, og af den README han linker til fremgår det også at driveren er GPL (hvilket klart er at foretrække over en særaftale, som andre raketgrupper ikke ville nyde adgang til).

http://www.oz9aec.net/index.php/dvb/488-us...

Det er i øvrigt fornøjeligt at se de berømte LOX-krystaller "up close" i videoen. Det er det rene Saturn V :)

  • 7
  • 0

Har I afprøvet konstruktionen under rystelser svarende til dem ved opsendelsen? Jeg har ret dårlige erfaringer med usb-stik og rystelser (på en selvbygget robot).

Rasmus Kjeldsen

  • 8
  • 0

Hej Sonny

Er analog video generelt ikke lettere at få et genkendeligt billede ud af selv med omfattende signaltab?

Det kommer an på de tekniske detaljer i transmissionen. Analog video bliver gradvis dårligere mens digital video falder pludselig ud. Jeg kender ikke detaljerne i Space X's system, men det kan ikke udelukkes at på det tidspunkt hvor deres digitale video falder ud, ville den tilsvarende analoge video være "druknet i sne" for lang tid siden. Generelt kræver analog videotransmission meget mere effekt end digital video alene af den grund at digital video er kraftigt komprimeret i forhold til analog video. Jeg ved at med DVB-S2 ville vi kunne fiske 3 HD kanaler ud af støj (langt under grænsen for en enkelt analog video i PAL format). Om det også gælder DVB-T ved jeg endnu ikke, men jeg skal nok vende tilbage med info når jeg ved mere.

Analog video har dog stadig den fordel, at når den kommer igen så er den der bare uden forsinkelse. Digital video kræver derimod databehandling og dermed en vis mængde data før modtageren kan vise et billede. Hvis video var missionskritisk ville jeg nok overveje et analogt system.

Optager I h.264 media streamen på et lagermedie før transmission?

Ja, det har vi i hvert fald mulighed for. Hvert kamera er baseret på en Raspberry Pi og de kører fra et SD kort. Videoen er ca. 3 Mbit/sek. Selve operativsystemet og applikationer kan jeg få ned på omkring 100 Mbyte, så med et 32 Gbyte kort har vi plads til et par timers video :-)

  • 20
  • 0

Fantastisk blog! Meget mere af det tak :)

Jeg glæder mig også helt enormt til CS-paletten bliver bredt fuldt ud for os her på bloggen. Peter skrev godt og fængende, men der gik til tider lidt for meget JFK-tale og WvB-nostalgi i den.

Det er klart at der stadig skal være en ideologisk indpisker repræsenteret på bloggen, men hold op jeg glæder mig til at høre om alle de ting der sker rundt omkring i krogene.

  • 14
  • 0

Hej, til sidst skriver i:

". Det betyder bl.a. at MPEG-TS muxing og RF interfacing vil blive udført på et separat computerboard, og det vil kræve et betydeligt programmeringsarbejde."

Hvorfor ikke fortsætte med det setup i har nu? Hvad er vundet på at dele opgaven ud i 2 boards? Som jeg forstår så virker det 100% nu (?)

Er det også jer der skal lave downlink af flight data?

  • 3
  • 0

Nu er det naturligvis en demonstration af det kommende system - fantastisk at se hvordan det er skruet sammen iøvrigt! men til en statisk test, ville det så ikke være en mulighed at lade Pi'en generere en RTSP strøm og så streame den gennem ethernetforbindelsen? Jeg tænker også må muligheden for at kombinere et link til flere kameraer, f.eks. flere kameraer på sputnik og et enkelt wifi-link á la downlinket fra Vostok til land? et par nanostation M5 mellem sputnik og Vostok burde give en båndbredde stor nok til flere kameraer? eller hvad?

  • 2
  • 0

Der har altid været åbent for at CSere kunne gæsteblogge her. B.la. Steen Andersen har skrevet teknikbaskere om FIDO, og flere andre har bidraget med forskellige områder. Nu er det særligt påkrævet, og det CS gør er efter min udmy mening helt rigtigt, særligt på et medie som ing.dk

Man kan ofte ikke se ud af akvariet når man selv svømmer i det. Men artikler som denne rummer jo vildt brugbare hårde data, for alle der måtte have brug for den slags teknologier. Dronefolk, dem der flyver balloner, alt muligt spændende.

Det er også et område hvor der laves noget exelent fordi det er en "confined space" hvor en enkelt kompetent person eller få, med få kontakt falder kan lave noget virkeligt godt arbejde.

Hvis der mangler data for nogen i teksten er jeg sikker på forfatteren kan bidrage med svar hvis man spørger.

Peter Madsen

  • 9
  • 7

Hvorfor ikke fortsætte med det setup i har nu? Hvad er vundet på at dele opgaven ud i 2 boards? Som jeg forstår så virker det 100% nu (?)

Lars,

Dette setup virker kun med et kamera. Vi skal have 3 kameraer og videoen fra dem skal blandes sammen til en transmission. Ligesom man har DR1, DR2, DR3, .... på en frekvens (en MUX) skal vi have 3 kameraer muxet sammen og det regner jeg med at bruge et ekstra board til.

Er det også jer der skal lave downlink af flight data?

Ja, men det er et separat system (design genbrugt fra Sapphire).

  • 10
  • 0

Set fra et PR/CSS synspunkt, så må det være missionskrittisk at få YouTube egnet video ned til at kunne sælge billeter og få support til næste mission.

  • 4
  • 2

Ved "missionskritisk" forstås et forhold, som kan true en igangværende flyvnings formål.

For projektet som helhed er der naturligvis mange forhold, der er kritiske.

  • 4
  • 0

@Hans Peter - der kommer snarest en (eller nok flere) blogs om hele vores egenudviklede WIFI netværk - hele vejen fra Sputnik i Østersøen til Campingvognsstudiet i København :)

  • 5
  • 0

Det er vist nævnt i artiklen, at fokus på Pi kameraet er indstillet til uendeligt, modsat C920 som sikkert er beregnet til indendørs brug. det bevirker også at signalbehandlingen er indstillet til indendørs belysning.

  • 3
  • 0

Det er vist nævnt i artiklen, at fokus på Pi kameraet er indstillet til uendeligt, modsat C920 som sikkert er beregnet til indendørs brug. det bevirker også at signalbehandlingen er indstillet til indendørs belysning.

Det er helt korrekt.

Vi fandt faktisk en metode til at splitte C920 ad og flytte fokus længere mod uendeligt ved at dreje linseholderen. Men det er en meget skrøbelig procedure fordi C920 har motoriseret fokus som kan komme til skade når man drejer linsen.

Jeg tror også at Pi kameraet har en bedre videoprocessor. Den kan f. eks. køre med op til 90 billeder per sekund i VGA opløsning. Desude er Pi kameraet lettere at opgradere med bedre linser.

  • 5
  • 0

Specielt kameraer har altid være noget som sjovt nok har voldt problemer, da de var udført så simpelt som muligt. Den første kapsel havde fået påsat et par overvågningskameraer, jeg selv havde installeret i et metalrør og vi kørte også med gopro i deres standard-huse. HEAT 1X havde et miniature konsumer-kamera man skulle tænde manuelt.

I alle de tilfælde hvor kamerarer var noget man skulle tænde manuelt fungerede det bare ikke.. Enten løb man tør fra tid, memory-plads eller batteri og det var svært at bedømme om de faktisk var tændt.

Derfor var et interessant valg at gå over til noget mere "komplekst" som umiddelbart virkede som om det gik i mod filosofien for CS. Men ikke desto mindre var denne mindre kompleksitets-forøgelse noget som formindskede problemerne for missionen og gav god sikkerhed for den video man skulle bedømme performance på og som man kunne skabe PR med.

Al den automatisering og ekstra halløj med kameraer er vejen frem. Der er styr på power, data, stream og on/off. Det andet giver stress og høj usikkerhed. På kamera-området er turbo-KISS bare ikke nødvendigvis sagen.

CS rocks!

vonB

  • 12
  • 0

Hej Alex,

Jeg kan godt se det attraktive i at samle kamera streams i et feed.

Men jeg håber også du laver nogle selvstændige enheder som kan monteres uafhængigt af alt andet og sende et tv feed tilbage.

I mine øjne er det et meget attraktivt redskab at have, især under sea lunch, at man i sidste øjeblik kan opsætte et kamera som giver øjne på noget der har vist sig problematisk.

Det er ihvert fald noget lækkert grej. Husk at stoppe udviklingen i tide så du er helt sikker på at få fixet alle bugs og testet alt ;)

Super arbejde og super blog.

  • 6
  • 0

En GoPro videokamera koster vel i nabolaget af 2.000kr De stumper som Alex Csete lister op lyder ikke så voldsom dyre, men hvad er niveauet i kroner?

En Raspberry Pi koster 299 kroner og kameraet koster 280 kroner. Begge normal pris hos den danske forhandler (lige nu er de faktisk billigere). Men, RPi+kamera kan vi selv programmere til at levere komprimeret H.264 video over en netværksforbindelse. Så vidt jeg ved det kan GoPro kun lagre H.264 video, ikke streame. Som andre lignende "consumer cams" kan GoPro kun levere analogt signal eller HDMI; begge vil kræve en ekstra konverter og enkoder. Prisen for en HDMI-til-ethernet konverter/enkoder er størrelsesorden 10000 kroner.

  • 2
  • 0

Har i kigget på HEVC / h.265 / Google VP9 endnu eller er det for tidligt? Jeg tænker på at de skulle være i stand til at levere samme kvalitet med halvdelen af båndbredden.

  • 1
  • 0

Har i kigget på HEVC / h.265 / Google VP9 endnu eller er det for tidligt? Jeg tænker på at de skulle være i stand til at levere samme kvalitet med halvdelen af båndbredden.

Hej Jørgen,

Jeg kender til deres eksistens men har ikke rigtig kigget på dem i detaljer. Jeg tror det er for tidligt forstået på den måde, at det ikke er let at finde billige indlejrede computere som understøtter det. Men det kommer nok meget snart.

  • 2
  • 0
Bidrag med din viden – log ind og deltag i debatten