Jak wyciągnąć najwięcej ze swojej kamery sportowej?

Coraz większą popularność zyskują kamery sportowe. W wielu miejscach sprzyjających aktywności i wypoczynkowi można spotkać ludzi, którzy za ich pomocą chcą uwiecznić wspomnienia. Jak jednak wycisnąć ze swojego GoPro maksimum? Co zrobić aby film z wakacji był interesujący i ciekawy? Oto cztery proste kroki.


Po pierwsze trzeba zrozumieć wady i zalety takiej kamery. Niewątpliwą zaletą jest jej szerokokątny obiektyw, który jest w stanie pokazać bardzo dużo z akcji, która się dzieje. Pewną wadą jest jednak ten właśnie obiektyw, który powoduje, że obraz jest zniekształcony. Filmując z bliska taką kamerą zarejstrujemy wielkie nosy lub inne zniekształcone cechy. Aby otrzymać ciekawy materiał należy unikać zbliżeń twarzy. Jedno zbliżenie na twarz w filmie da bardzo ciekawy efekt ale już więcej będzie powodowało po prostu zmęczenie u widza.

Po drugie światło. Nic tak nie psuje materiału jak złe oświetlenie. Zgodnie ze sztuką, słońce powinniśmy trzymać za plecami aparatu. Proste i oczywiste. Co jednak jeśli niebo jest „zaciągnięte”, pochmurne i nie widać słońca? Otrzymamy albo białe wypalone niebo albo ciemne twarze. Rozwiązanie jest w miarę proste. Zobacz na kompasie w telefonie gdzie jest północ, oszacuj gdzie teraz powinno być słońce i już wiesz jak się ustawić. Ten prosty zabieg ułatwi kamerze pracę a Ty otrzymasz lepszy materiał.

Po trzecie stabilizacja. Jeśli cały materiał jest rozbiegany, trzęsie się i rusza, wówczas dla widza taki film będzie po prostu męczący. Można temu zapobiec stawiając kamerę na statywie lub mocując uchwytem drzewa. Można też zainwestować z porządny trzyosiowy gimbal, który będzie posiadał odpowiednie mocowanie dla kamery sportowej. Jeśli większość materiału będzie stabilna, wówczas główny element filmu, ten gdzie dzieje się najwięcej akcji, będzie trzęsący uzyskamy efekt wzmocnienia, dodatkowej dynamiki. Wówczas taki ruchomy obraz będzie bardzo pożądany.

Po czwarte nakręć dodatkowy materiał normalną kamerą, choćby telefonem komórkowym. Szeroki kąt obiektywu potrafi być męczący więc warto normalnym obiektywem nakręcić przygotowania albo element podróży do miejsca akcji. Warto stworzyć historię, która opowie o Twojej przygodzie. Następnie główną akcję nakręć kamerą sportową a potem stwórz jeszcze trochę materiału, takiego po części głównej. Wtedy twoja historia będzie kompletna i ciekawa. Z miłą chęcią będziesz ją pokazywać znajomym po powrocie do domu.

 

więcej informacji na: http://feiyu-tech.pl/gimbale-do-kamer-sportowych

Odczytywanie temperatury za pomocą LM75A i Raspberry Pi

Ostatnio opisywałem czujnik LM75A, który jest banalny do podłączenia do Raspberry Pi i który jest banalny do odczytu za pomocą prostego skryptu w pythonie. Dzisiaj wgryziemy się w kod:

Zaczniemy od tego co lubię najbardziej: KOD. Najszybciej zaczniemy wpisując w terminalu

nano temperature.py

i zaczniemy kodować (rozumiem, że i2c jest skonfigurowane):


import smbus

sensorAddress = 0x48
i2c = smbus.SMBus(1)

print i2c.read_word_data(sensorAddress,0)

Czyli po kolej: importujemy bibliotekę smbus (zainstalowaną wcześniej)
podajemy adres czujnika (i2cdetect –y 1 żeby sprawdzić czy mamy coś podpięte i pod jakim adresem)

tworzymy obiekt reprezentujący szynę i2c (w raspberry pi rev2 jako parametr podajemy 1, w rev1 0)

i odczytujemy temperaturę. Wychodzimy z edytora i uruchamiamy skrypt:

python temperature.py

i mamy odczyt. Banalnie prosto. 🙂

A jeśli dziwi Cię dlaczego ten odczyt jest taki dziwny to dlatego, że odczytaliśmy surową wartość w formie jakiej wypluł czujnik. To jak to jest kodowane o co oznacza pisałem ostatnio zatem kod parsujący temperaturę z LM75A:

Zatem dodajemy kawałek kodu, który parsuje wartość odczytaną i zwraca prawidłową temperaturę

def Decode(raw):
    tempA = raw & 0xFF
    tempB = (raw >> 8) & 0xFF
    temp = (tempA << 8) | tempB
    temp = temp >> 5
    return temp

def Parse(input):
    signBit = input >> 10
    if signBit > 0:
        negativeTemperature = input
        return (negativeTemperature * 0.125) - 256
    return input * 0.125

raw = i2c.read_word_data(sensorAddress,0)
temp = Decode(raw)
print Parse(temp)

czyli mamy dwie funkcje, Decode, która tak przestawia bity aby zgodnie z tym co ostatnio pisałem uzyskać prawidłową liczbę w pythonie oraz Parse, która odpowiednio przelicza to na nasze dobrze znane stopnie Andersa Celsiusa.

Po sieci krąży jeszcze jedne kod do odczytu temperatury z LM75A:

tempA = temp & 0xFF
tempB = (temp >> 8) & 0xFF
temp = (tempA  << 8) | tempB
temp = temp >> 5

r = temp >> 7
if (temp & 0x8000):
r = (~r & 0x1FF)
r = r - 1
r = -r
r = r / 2.0
return str(r)

ma on jednak małą wadę, zaokrągla odczyt do .5 więc tracimy na rozdzielczości czujnika i z .125 robi nam się 0.5 stopnia Wprawdzie w zastosowaniach domowych i meteo nie ma to wielkiego znaczenia to jednak piszę o tym, ponieważ jedna z pierwszych moich wersji bazowała na tym kodzie i zaokrąglała własnie do .5. Teraz znalazłem czas, żeby napisać to po swojemu i mam .125

Ostatnia sprawa to spięcie całości. Potrzebujemy połączyć kość LM75A z Malinką:

image

Łączymy piny:

LM75ARaspberry PI
1 (SDA)2 (SDA)
2 (SCL)3 (SCL)
4 (GND)24 (Ground)
8 (VCC)1(3V3 Power)
51 (3V3 Power)
61 (3V3 Power)
71 (3V3 Power)

Piny 5 6 7 możemy połączyć dowolnie z “plusem” lub “minusem” – w ten sposób ustalamy adres jednak należy pamiętać, że piny 5, 6 i 7 MUSZĄ BYĆ POŁĄCZONE.

Miłej zabawy a w następnym odcinku serii na warsztat weźmiemy ciśnienie ale dopiero w przyszłym tygodniu.

LM75A + i2c + Raspberry Pi czyli mierzymy temperaturę

Szerszy obraz czyli tzw. przydługi wstęp

Zainteresowanie szyną i2c spowodowane było moim lenistwem. Piec w domu nie ma termostatu a rozpalając go warto wiedzieć jaka jest temperatura żeby wiedzieć kiedy go zamknąć. Rozwiązanie? Czujnik temperatury w piwnicy – na piecu, najlepiej taki który będę mógł sprawdzać za pomocą telefonu. Dodatkowo dlaczego by nie mieć czujnika temperatury w każdym pokoju i w dodatku zapisywać je aby moc później oglądać jak te temperatury się zmieniają. Dostępne na rynku rozwiązania albo nie spełniają wszystkich założeń albo są mega drogie. Pod telewizorem leży malinka wiec dlaczego jej nie zaprzęgnąć do dodatkowej pracy. Idealny materiał na pet project. Wstępne założenia są takie czujnik temperatury w piwnicy, w sypialni i salonie oraz na zewnątrz – być może temperatura przy ziemi oraz na wysokości 2 metrów czyli tak jak to mierzą meteorolodzy (btw. nie ma czegoś takiego jak temperatura w/na słońcu. Prawidłowo mierzona temperatura powietrza jest dokonywana na wysokości 2m w klatce meteorologicznej zapewniającej cień. Nie mierzymy temperatury w/na „słońcu”). Wyszło 5, być może jeszcze w pokoju dzieci i może kuchni to daje 7. Po szybkiej analizie dostępnych możliwości okazało sie ze Lm75a nadaje sie najlepiej. Na jednej szynie i2c (to ważne bo dzięki temu cześć elektroniczna jest uproszczona do minimum) można podpisać 8 termometrów. Zakres mierzonej temperatury to -50 do 150 stopni. Dla mnie idealnie. Dokładność 2stopnie. Z jednej strony masakra a z drugiej – co mnie to obchodzi, to nie jest aparatura medyczna. Się skalibruje i odpowiednie poprawki w kodzie się zrobi. W zakresie domowym i zewnętrznym czujnik jest liniowy wiec nie ma stresu a pomiar temperatury w piecu wystarczy z dokładnością 5 stopni, aktualny bimetalowy wskaźnik i tak jest mocno orientacyjny.

Zatem na warsztat idzie kostka do odczytywania temperatury czyli LM75A. Idiotycznie prosta w użyciu i obsłudze kość pozwoli łatwo uzyskać zadowalające efekty i nie powinna stanowić większego problemu nawet dla początkujących elektroników. Dokumentacja techniczna znajduje się tutaj.

lm75-elememnty

Do zmontowania będą potrzebne LM75, dostępne na allegro i w przyzwoitych sklepach elektronicznych (na powyższej rycinie to te pajączki w woreczku antystatycznym) garść kondensatoró 10nF ceramicznych oraz płytki drukowane. Te ostatnie nie są obowiązkowe bo można zmontować wszystko na pająka albo jak to teraz modniej w 3D ale na allegro można dostać gotowe płytki SO8 która ułatwi pracę. Przydatny może być również kynar jeśli chcemy mieć więcej niż 1 czujnik. Przyda się również lutownica (lepiej oporowa niż transformatorowa) oraz podstawowe umiejętności z zakresu lutowania i wąchania kalafonii.

Technikalia

Kostka ma 8 wyjść. VCC to zasilanie. Malinka może zapewnić nam 3.3 lub 5V, kość wymaga zasilania w zakresie 2.8-5.5 więc 3.3 będzie ok (później będziemy się zajmować barometrem, który jest bardziej wybredny i dlatego skorzystam z 3.3). GND to masa – lub  minus zasilania. To załatwia zasilanie. SDA i SCL to szyna danych w I2C. Ponieważ całość podpinamy do Raspberry Pi, która ma rezystory podciągające to poza połączeniem VCC GND SDA i SCL mamy w pełni funkcjonalną szynę, która nić ponad to nie potrzebuje.

image

Teraz najciekawsza część. LM75 ma ustawiany adres a ustawiamy go za pomocą zwierania A0 A1 i A2 do VCC lub do GND. I2C pozwala podpiąć równolegle do 120 urządzeń więc żeby je rozróżnić od siebie –  z którym w danej chwili chcemy rozmawiać – należy je zaadresować. Adres jest ustalany przez producenta na etapie projektowania. W przypadku LM75 adres wygląda tak:

MSBLSB
1001A2A1A0

Co ważne, A0-A2 MUSZĄ być połączone albo z VCC albo z GND. Jeśli pozostawimy je wiszące to kość będzie się dziwnie zachowywać tzn. czasem będzie odpowiadać a czasem nie. Ustawiając adresy cudeńko możemy znaleźć pod adresami od 72 (0x48) do 79 (0x4F) – sprawdzimy to za pomocą komendy i2cdetect.

Zmontowana kość u mnie wygląda tak:

photo

Jak widać mistrzostwo we władaniu lutownicą nie jest jakoś specjalnie potrzebne, ważne żeby nie poparzyć się, nie ugotować kostki i nie pozwierać za dużo…. aha i nie oblizujemy grota lutownicy.

Temperatura

Kość jest samowystarczalna w tym sensie, że po ustawieniu adresu i dostarczeniu zasilania można czytać temperaturę bez jakiejś specjalnej kalibracji czy innych magicznych obrządków. Wystarczy odczytać odpowiedni rejestr (o tym jak, będzie w następnym wpisie), który zbudowany jest tak:

MSByteLSByte
7654321076543210
D10D9D8D7D6D5D4D3D2D1D0XXXXX

D10 to znak czyli 0 temperatura dodatnia, 1 temperatura ujemna. D9 do D0 to nasza temperatura zapisana jako wartość całkowita – ofc zapisana binarnie. XXXXX są nie używane.

Dla fanów tdd trochę mięsa czyli przypadki testowe – ot wprost z dokumentacji:

11-bit binary

szenastkowodziesiętniewartość temperatury
011111110000x3F81016+127.000 °C
011111101110x3F71015+126.875 °C
011111100010x3F11009+126.125 °C
011111010000x3E81000+125.000 °C
000110010000x0C8200+25.000 °C
000000000010x0011+0.125 °C
000000000000x00000.000 °C
111111111110x7FF-1−0.125 °C
111001110000x738-200−25.000 °C
110010010010x649-439−54.875 °C
110010010000x648-440−55.000 °C

z wartości dziesiętnej na prawdziwą temperaturę przechodzimy tak:

dla wartości dodatniej czyli D10 = 0

(°C) = +(Temp) × 0.125 °C.

dla wartości ujemnych czyli D10 = 1

(°C) = −(pozostała część Temp) × 0.125 °C.

Wstępnie mamy omówiony pierwszy klocek układanki. Wiadomo dlaczego i czym chcę mierzyć temperaturę. W następnej części pokażę jak to to podpiąć do malinki oraz zaglądniemy do kodu który pozwoli na odczyt temperatury.

SSD dla developera czyli Samsung 840

samsung-840-pro.jpg

Długo się zastanawiałem czy przejść na SSD czy nie. Z jednej strony internety mówią, że to takie super i szybkie i w ogóle a z drugiej cena jakoś ciągle jeszcze nie jest przyzwoita, szczególnie że 128GB to dla mnie za mało – potrzebuję ~200GB. W końcu jednak stwierdziłem, że trzeba spróbować. Wybór padł na Samsung-a 840 Pro. Podstawowy argument to 5 lat gwarancji, drugi to (podobno) najszybszy dysk na rynku. Jak inwestować to w najlepsze zatem zakupiłem. Pierwsze wrażenia, piękne pudełko i piękny dysk. Mimo, że to nie ma wielkiego znaczenia to jednak robi wrażenie czarne pudełko z lekką, błyszczącą fazą. Dla porównania stary dysk, który to cudo zastępuje to ordynarna blacha z wielkimi śrubami na górze i stadem nalepek z jeszcze większą liczbą piktogramków, kodów paskowych, QRów i innych bzdetów. Ja wiem, że geeki takie rzeczy lubią ale mimo wszystko dlaczego w środku wszystko musi wyglądać jakby wyrzygał się wielki elektronik?

Jak dysk sobie radzi. Poniżej test dysku. Nie są to syntetyczne testy prędkości bo te znajdziesz wszędzie. Ja po prosty zmierzyłem zwykłym zegarkiem czas uruchomienia tego co używam najczęściej.

operacja

stary dysk

sdd (migracja)

czysta instalacja

restart

1 min 25.74

52.00

15

VS2012

10.82

8.40

2.7

VS2012 projekt testowy

33.38

17

13.90

WebStorm I

56.90

9.2

5.03

WebStorm II

6.55

6

4.6

VS2012 kompilacja projektu testowego

6.21

6.20

6.01

R# Code Issues

25.20

23

18.12

Pierwsza kolumna to stary dysk. Na warsztat poszły VS2012 (z R# 8 EAP + NCrunch-em) i  WebStorm. System to fabrycznie zainstalowany Win7 po upgradzie do Windows 8 Pro.

Druga kolumna to zmigrowany stary dysk na ssd za pomocą narzędzia dostarczanego przez Samsunga. I tutaj już widać olbrzymi skok. Cały system chodził wyraźnie szybciej niż na starym dysku – czyli bajki o szybkości ssd nie są wyssane z palca.

Trzecia kolumna to wyczyszczony SSD i zainstalowany na czystko Windows 8 Pro. I tutaj okazało się, że to chodzi jeszcze szybciej. Kopiowanie danych po ssd i usuwanie jest wręcz nieprzyzwoite pliki po prostu znikają. Chrome uruchamia się tak szybko, że nie ma co mierzyć. Word i Excel to samo. Po prostu się pojawiają – niesamowite.

Jeśli chodzi o Visual Studio to odnoszę wrażenie, że chodzi szybciej. W XAML-ach nie muli się jak w błotnej kąpieli. Co do kompilacji to niestety tutaj wielkiego zysku nie ma – no ale co się dziwić, tutaj trzeba procesora i to nawet nie rdzeni a jednego mega mocnego rdzenia. Swoją drogą to czekam aż Microsoft przepisze kompilator na wielowątkowość, przecież specyfikacja tego nie zabrania.

WebStorm I i II różni się tym, że I to pierwsze uruchomienie a II to każde następne. Przy pierwszym startuje dodatkowo Java więc różnica w czasach jest usprawiedliwiona.

Co do samej “testowej” platformy to jest to zwykły półkowy laptop Dell z i5 (2gen) + 4GB Ramu. Skok wydajności imho jest dużo większy niż gdyby zwiększyć Ramu do 16 (moje max) więc wydaje się, że inwestycja w ssd da dużo lepsze wyniki niż w ram jeśli mamy ograniczone zasoby.

A teraz wady. Dysk ma 7mm  wysokości a w tym konkretnym Dell-u dysk wpina się po prostu w port i tyle, “Pam rest” przytrzymuje go na miejscu dlatego  ta brakująca grubość powoduje, że dysk lata  i obija się. Tutaj z pomocą przyszła szara pianka z jakiegoś pudła. To co dla ultrabooków jest zaletą u mnie okazało się wadą.

Na tą chwilę, mogę polecić taki dysk każdemu. Komputer dostaje skrzydeł i aż chce się pracować. Jak z czasem będzie się sprawdzał? Zobaczymy.