1. května 2017 jsem si položil otázku: Mohu se naučit nezbytnou počítačovou vědu pro sestavení softwarové části autosedačky za měsíc?

22. května 2017, po 26 hodinách učení a kódování, jsem zjistil, že odpověď byla ano.

Během měsíce května jsem celý svůj proces učení zdokumentoval v sérii 31 denních blogových příspěvků, které jsou zde shrnuty do jediného příběhu. V tomto článku si můžete prožít můj měsíc zasvěcení, frustrace, učení hacků a triumfů, když se snažím o měsíční mistrovství.

Dnes začínám nový měsíc a novou výzvu: Mohu se naučit nezbytnou počítačovou vědu k tomu, abych mohl za jeden měsíc postavit softwarovou část samohybného auta?

Definování úspěchu

Abych mohl plně vyrobit auto s vlastním pohonem, musel bych postavit 1. Software s vlastním pohonem a 2. hardware s vlastním pohonem. Software by používal senzory a vstupní data k algoritmickému generování jízdních instrukcí a hardware by tyto instrukce řídil ve skutečném autě.

Protože většina technické výzvy je ve skutečnosti v softwarové části (a také proto, že nevlastním auto), zaměřím se výhradně na softwarovou část pro tento měsíc výzvu.

Zejména bych chtěl vytvořit software pro řízení vozidel, který dokáže dělat dvě věci:

  1. Na základě videovstupu na silnici může software určit, jak bezpečně a efektivně řídit vůz.
  2. Na základě videovstupu na silnici může software určit, jak bezpečně a efektivně využívat akcelerační a brzdicí mechanismy vozidla.

Mohu se pokusit řešit každou z těchto skladeb samostatně nebo společně. Ještě si nejsem jistý. Nejsem si také zcela jistý konkrétními podrobnostmi o každé z těchto dílčích výzev, ale jakmile provedu nějaký počáteční výzkum, tyto podrobnosti podrobněji rozvážím.

Mohou existovat další důležité aspekty softwaru pro autosedačky, které nejsou zahrnuty do těchto dvou kbelíků, ale to jsou položky, na které se budu tento měsíc zaměřovat. Z těchto položek je zřejmé, že se hlavně snažím naučit, jak používat strojové učení / hluboké učení k řešení problémů s počítačovým viděním (vysvětlím, co to všechno znamená v budoucím příspěvku).

Můj výchozí bod

Vytváření softwaru pro autofrekvenční řízení jasně vyžaduje určité znalosti v oblasti informatiky a v tomto ohledu nezačínám od nuly.

Zaprvé, můj titul z matematiky Brown je v matematice, což je docela užitečné pro toto konkrétní odvětví informatiky. Mám také obecné znalosti o kódování / informatice, což mi určitě pomůže.

Nejzajímavější je, že loni v létě jsem zveřejnil několik kusů fikce fanoušků, které jsem vytvořil pomocí příslušné techniky strojového učení - jako je tato kapitola AI napsaná Harrym Potterem - ale to bylo většinou svědectvím o dostupnosti vysoce kvalitního open-source kód, a ne moje znalosti strojového učení.

Minulé léto jsem také absolvoval matematický kurz o hlubokém učení (hluboké učení je podkategorií strojového učení ... což je podkategorie umělé inteligence ... což je podkategorie počítačové vědy). Tento kurz byl zajímavý, ale byl čistě teoretický, nikoli praktický.

Tento měsíc se intenzivně zaměřuji na aplikaci, ne na teorii, a na počítačové vidění, což je něco, s čím nemám žádné zkušenosti.

V zásadě mám nějaké základní zkušenosti, ale nemám dost zkušeností, abych věděl, kde začít (bude to vyžadovat nějaký výzkum během několika příštích dnů).

Každopádně nemám rozumný odhad toho, jak těžké to vlastně bude, takže to bude určitě fascinující měsíc. Jsem nadšený, že mohu začít ...

Lineární metoda učení

Když se pokoušíte porozumět širokému oboru (jako je základní počítačová věda aut s vlastním pohonem), je často obtížné zjistit, kde je správný vstupní bod.

Výsledkem je, že většina lidí předpokládá, že nejlepší cestou vpřed je začít se základy, vybudovat obecný základ znalostí a poté pokračovat k jemnějším a jemnějším úrovním detailů.

Říkám tomu lineární metoda učení.

Použití lineární metody k učení počítačové vědy o autech s vlastním pohonem by vypadalo takto:

  1. Naučte se vícerozměrný počet
  2. Naučte se lineární algebru
  3. Naučte se základní základy informatiky
  4. Další informace o obecných koncepcích strojového učení
  5. Další informace o koncepcích počítačového vidění
  6. Naučte se, jak kódovat v Pythonu (kódovací jazyk běžně používaný pro strojové učení)
  7. Naučte se používat TensorFlow (speciální strojovou knihovnu učení pro Python)
  8. Naučte se, jak se používá počítačové vidění při tvorbě softwaru pro autosedačky
  9. Naučte se, jak psát Python a TensorFlow kód pro vytváření příslušných programů
  10. Atd…

I když tato metoda může nakonec fungovat, je neefektivní a pravděpodobně není účinná.

Zaprvé, jakmile začnu učením multivariabilního počtu, jak zjistím, které části multivariabilního počtu jsou relevantní pro automobily s vlastním pohonem a které části nejsou? Nemám. Musím se toho všechno naučit. Totéž platí pro lineární algebru a základy počítačové vědy atd.

Jinými slovy, pokud začnu s nejobecnějšími znalostmi, nemám způsob, jak upřednostňovat to, co se učím, a tak se nakonec nutím, abych se naučil všechno jen pro případ.

Navíc, protože se nejprve učím základní pojmy v obecném, abstraktním smyslu, je pro mě mnohem těžší spojit to, co se učím, s věcmi, které již znám. Protože efektivní učení v zásadě přichází na to, jak smysluplným způsobem připojit nové informace k aktuálně existujícím znalostem, Linearova metoda učení také v tomto ohledu selhává.

Takže zatímco většina lidí přistupuje k učení lineárním způsobem, je docela špatnou metodou naučit se cokoli v rozumném časovém rámci.

V-metoda učení

Místo toho používám jinou metodu, kterou nazývám V-metoda učení.

Jak funguje metoda V-Learning:

  1. Začnu konkrétním, dobře zdokumentovaným příkladem mého konečného cíle
  2. Snažím se pochopit, jak tento příklad funguje
  3. Pro všechno, čemu nerozumím o příkladu, zkoumám základní pojmy
  4. Pokud nerozumím základním konceptům, zkoumám základní pojmy základních konceptů, dokud necítím, že jsem tuto cestu nevyčerpal (buď dosažením porozumění nebo dosažením bodu snižujících se výnosů)
  5. Nakonec jsem vrhl dost různých cest, abych začal vidět vzorce v důležitých základních pojmech
  6. Studuji tyto relevantní základní pojmy a pomalu pracuji ve znalostním řetězci, dokud se nevrátím na úroveň detailů původního příkladu
  7. Nakonec reprodukuji příklad na základě mých nových hierarchických znalostí

Tomu říkám „V-metoda“, protože začínám s nejjemnější úrovní detailů, ponořím se hluboko k přímo použitelným základním konceptům a poté se vrátím zpět k nejjemnější úrovni detailů - koncepční V.

V-metoda je mnohem účinnější než lineární metoda, protože jsem schopen: 1. Naučit se v pořadí relevance k mému konečnému cíli, 2. Naučit se základní pojmy v kontextu něčeho hmatatelného a 3. Vytvářet a organizovat moje znalosti hierarchickým, vzájemně propojeným způsobem.

Výsledkem je, že tato metoda je mnohem účinnější, efektivnější a poutavější.

Takto plánuji použít metodu V na výzvu pro tento měsíc:

  1. Podívejte se na ukázkový, autosalonový kód s otevřeným zdrojovým kódem na Githubu (Github je populární úložiště kódu, což v podstatě znamená, že zde mohu najít spoustu softwarových projektů jiných lidí)
  2. Pracujte svou cestou řádek po řádku skrz kód
  3. Pro každý řádek kódu, kterému nerozumím na intuitivní úrovni (což bude většina z nich), začni sestup skrz vrstvy základních pojmů
  4. Identifikujte vzorce toho, co neustále vyhledávám / zkoumám, a určuji nejdůležitější základní pojmy
  5. Studujte tyto základní pojmy
  6. Pracujte na cestě zpět do vrstev základních konceptů, dokud si nedokážu efektivně vysvětlit každý řádek kódu z ukázkového projektu Github

Pokud to stále zní trochu matoucí, doufejme, že to začne mít větší smysl, jakmile začnu.

Mým prvním krokem je hledat v Githubu dobrý ukázkový projekt…

Včera jsem představil primární metodu, kterou používám pro učení nových technických dovedností, které nazývám V-metoda. Pomocí této metody zahájím své studium velmi specifickým příkladem (který by měl úzce simulovat můj požadovaný konečný výsledek) a použít jej jako vstupní bod k tomu, abychom se naučili relevantní základní pojmy hmatatelným, organizovaným a hierarchickým způsobem.

Mým cílem proto bylo dnes v počítači spustit nějaký kód, který budu moci použít pro své vozidlo s vlastním řízením.

Nalezení kódu

Poté, co jsem Googling trochu našel, jsem našel projekt na Githubu, který dobře vyhovoval mým potřebám. Kód vezme vstupní obraz silnice a pokusí se zjistit, kde jsou čáry pruhu.

Z tohoto ...

K tomuto…

Mým cílem pro dnešek bylo pokusit se replikovat tento výsledek s kódem spuštěným na mém počítači.

Příprava

Než jsem mohl spustit jakýkoli kód, musel jsem se ujistit, že můj počítač byl nastaven pomocí příslušných softwarových knihoven. Zejména jsem potřeboval nainstalovat numpy, matplotlib a OpenCV knihovny pro Python.

Po orientaci v Terminálu (příkazový řádek v systému Mac) a nalezení některých pokynů online jsem narazil na svou první chybu…

Spíše než se snažím zjistit, co přesně tato chyba znamená nebo jak ji opravit sám, jsem použil nejúčinnější techniku ​​ladění, kterou znám: Zkopíroval jsem a vložil celou chybovou zprávu do Googlu.

Kliknul jsem na třetí odkaz a našel tuto odpověď:

Po spuštění těchto několika příkazů (jejich zkopírováním a vložením do Terminálu a kliknutím na „Enter“) se zdálo, že všechno funguje správně.

Byl jsem oficiálně nastaven (alespoň prozatím).

Spuštění kódu

Nyní, když jsem byl nastaven, nastal čas spustit kód. Poté, co jsem znovu použil Google k rozšíření mých omezených znalostí Terminálu, dostal jsem kód do chodu a zdálo se, že se nic nezlomilo.

Dostal jsem tento výstup ...

Chladný! Tato čísla jsou tedy v podstatě matematickou reprezentací dvou linií pruhu.

Zatím je vše dobré. Ale kde jsou vizuální prvky?

V projektu Github, který jsem se snažil replikovat, kód také vydal tyto pěkné spiknutí…

Stejně jako obrázek s červenými překryvy ...

Můj kód bohužel nevyvedl ani jeden z nich, ani neukládal žádné obrázky do mého místního adresáře.

Znovu jsem se tedy obrátil zpět na Google a hledal jsem „save image python“, v naději, že přijdu na to, jak uložit obrázek výstupu.

Google mi pěkně řekl, abych použil funkci cv2.imwrite (), tak jsem to udělal a fungovalo to. A „pracováním“ mám na mysli ... podařilo se mi zachránit obrázek fotografie v šedé škále s pruhy vizualizovanými bílou barvou.

A tady je další ...

A ještě jedna…

Co teď?

To je dobrý začátek.

V zásadě, jakmile dokážu účinně identifikovat jízdní pruhy, mohu tyto informace použít k tomu, abych své vozidlo s vlastním řízením naučil řídit (v rámci jízdních pruhů). Také, protože video je jen sbírka mnoha fotografií, zpracování videa by mělo fungovat stejným způsobem (pokud dokážu přijít na to, jak rozdělit video na fotografie v reálném čase pro zpracování).

Zítra, protože tento kód funguje víceméně, pokusím se projít projektem řádek po řádku a začít odhalovat, jak to vlastně funguje.

Do té doby je tato lekce následující: Pokud jste ochotni akceptovat, že často nemáte všechny odpovědi, ale jste ochotni Google obejít a trochu experimentovat, můžete přesto dosáhnout pokroku.

Jistě, zatím nemám silné pojmové porozumění, ale nyní mám funkční příklad, který mohu použít jako svůj výchozí bod.

Včera jsem přišel na to, jak identifikovat čáry pruhu v obraze silnice směřujícím dopředu. No ... aspoň jsem přišel na to, jak spustit kód, který by to dokázal.

Výstup ze včerejška

Po pravdě řečeno jsem nerozuměl tomu, jak kód vlastně fungoval, a tak jsem se to dnes pokusil změnit.

Níže je hlavní blok kódu, který jsem použil včera. Zejména jsem zkopíroval primární funkci, která se nazývá „draw_lane_lines“. V zásadě je funkce blokem kódu, který bere nějaký vstup (v tomto případě fotografii), nějakým způsobem manipuluje se vstupem a poté manipuluje s výstupy (v tomto případě řádky pruhu).

Tato primární funkce používá některé další pomocné funkce definované jinde v kódu, ale tyto pomocné funkce jsou většinou jen mírně čistějšími způsoby, jak spotřebovat předem připravené funkce z knihoven, které jsem včera stáhl (například OpenCV).

def draw_lane_lines (obrázek):
imshape = image.shape
    
    # Obrázek ve stupních šedi
    greyscaled_image = šedá stupnice (obrázek)
    
    # Gaussovské rozostření
    blurred_grey_image = gaussian_blur (greyscaled_image, 5)
    
    # Detekce hrany canny
    edge_image = canny (blurred_grey_image, 50, 150)
    
    # Obrázek hran masky
    hranice = 0
    vertices = np.array ([[(0, imshape [0]), (465, 320), (475, 320),
    (imshape [1], imshape [0])]], dtype = np.int32)
    edge_image_with_mask = region_of_interest (edge_image,
    vrcholy)
    
    # Hough lines
    rho = 2
    theta = np.pi / 180
    práh = 45
    min_line_len = 40
    max_line_gap = 100
    lines_image = hough_lines (edge_image_with_mask, rho, theta,
    práh, min_line_len, max_line_gap)
# Převést Hough z jednoho kanálu na RGB na přípravu pro vážení
    hough_rgb_image = cv2.cvtColor (lines_image, cv2.COLOR_GRAY2BGR)
 
    # Zkombinujte obraz čar s původním obrázkem
    final_image = weighted_img (hough_rgb_image, image)
    
    návrat final_image

Tučně zvýrazněné komentáře jsou popisy hlavních částí potrubí pro zpracování obrazu, což v podstatě znamená, že se jedná o sedm manipulací provedených postupně na vstupním obrazu, aby se na výstup vytvořily linie pruhu.

Mým cílem bylo dnes pochopit, co každý z těchto sedmi kroků udělal a proč byly použity.

Ve skutečnosti jsem se zaměřil pouze na prvních pět, které vydávají matematické znázornění jízdních pruhů. Poslední dvě manipulace pouze vytvářejí vizuální prvky, takže my, lidé, můžeme vizuálně ocenit matematiku (jinými slovy, tyto kroky nejsou nutné, když auto s vlastním pohonem skutečně spotřebovává výstupní data).

Na základě dnešního výzkumu se nyní pokusím vysvětlit následující sled událostí zpracování obrazu: Vstupní obraz → 1. Obraz v odstínech šedi, 2. Gaussovské rozostření, 3. Detekce hran Canny, 4. Obraz hran masky, 5. Hough linky → Výstup linky

Vstupní obrázek

Zde je úvodní vstupní obrázek.

Je důležité si uvědomit, že obrázek není nic jiného než svazek pixelů uspořádaných v obdélníku. Tento konkrétní obdélník je 960 pixelů x 540 pixelů.

Hodnota každého pixelu je nějaká kombinace červené, zelené a modré a je reprezentována trojicí čísel, kde každé číslo odpovídá hodnotě jedné z barev. Hodnota každé z barev se může pohybovat od 0 do 255, kde 0 je úplná absence barvy a 255 je 100% intenzita.

Například bílá barva je reprezentována jako (255, 255, 255) a černá barva je reprezentována jako (0, 0, 0).

Tento vstupní obraz tedy může být popsán 960 x 540 = 518 400 triplety čísel v rozsahu od (0, 0, 0) do (255, 255, 255).

Nyní, když je tento obrázek jen sbírkou čísel, můžeme začít s těmito čísly manipulovat užitečnými způsoby pomocí matematiky.

1. Obrázek ve stupních šedi

Prvním krokem zpracování je převedení barevného obrázku na stupně šedi, čímž se efektivně sníží barevný prostor z trojrozměrných na jeden. Je mnohem snazší (a účinnější) manipulovat s obrazem pouze v jedné dimenzi: Tato jedna dimenze je „tma“ nebo „intenzita“ pixelu, přičemž 0 představuje černou, 255 představuje bílou a 126 představuje střední šedou barvu. .

Intuitivně jsem očekával, že filtr ve stupních šedi bude jen funkcí, která zprůměruje hodnoty červené, modré a zelené dohromady, aby bylo dosaženo výstupu v odstínech šedé.

Například zde je barva z oblohy na původní fotografii:

Může být reprezentován v RGB (červené, zelené, modré) místo jako (120, 172, 209).

Pokud tyto hodnoty průměruji společně, dostanu (120 + 172 + 209) / 3 = 167, nebo tuto barvu v odstínech šedé.

Ale ukázalo se, že když převedu tuto barvu na stupně šedi pomocí výše uvedené funkce, skutečná výstupní barva je 164, což je mírně odlišné od toho, co jsem vytvořil pomocí své jednoduché metody průměrování.

I když moje metoda není ve skutečnosti „špatná“ sama o sobě, běžně používanou metodou je výpočet váženého průměru, který lépe odpovídá tomu, jak naše oči vnímají barvu. Jinými slovy, protože naše oči mají mnohem více zelených receptorů než červené nebo modré receptory, hodnota zelené by měla být ve funkci šedi vážena více.

Jedna vážená metoda zvaná colometrická konverze používá tento vážený součet: 0,2126 červená + 0,7152 zelená + 0,0722 modrá.

Po zpracování původního obrazu filtrem ve stupních šedi získáme tento výstup…

2. Gaussova rozostření

Dalším krokem je rozostření obrazu pomocí Gaussova rozostření.

Použitím mírného rozostření můžeme z obrázku odstranit informace o nejvyšší frekvenci (a.k.a šum), což nám poskytne „plynulejší“ barevné bloky, které můžeme analyzovat.

Základní matematika Gaussovy rozostření je opět velmi jednoduchá: Rozostření vyžaduje pouze více průměrů pixelů (tento průměrovací proces je typ konvoluce jádra, což je zbytečně fantazijní název toho, co se chystám vysvětlit).

Chcete-li generovat rozostření, musíte v zásadě provést následující kroky:

  1. Vyberte pixel na fotografii a určete jeho hodnotu
  2. Najděte hodnoty pro místní sousedy vybraného pixelu (můžeme libovolně definovat velikost této „místní oblasti“, ale obvykle je poměrně malá)
  3. Vezměte hodnotu původního pixelu a sousedních pixelů a průměrujte je dohromady pomocí nějakého váhového systému
  4. Nahraďte hodnotu původního pixelu výstupní hodnotou průměrované hodnoty
  5. Udělejte to pro všechny pixely

Tento proces v podstatě říká „učinit všechny pixely podobnější pixelům v okolí“, což intuitivně zní jako rozmazání.

Pro Gaussovo rozostření jednoduše použijeme Gaussovo rozdělení (tj. Zvonovou křivku) k určení hmotnosti v kroku 3 výše. To znamená, že čím je pixel blíže k vybranému pixelu, tím větší je jeho hmotnost.

Nechceme však obraz příliš rozmazat, ale jen natolik, abychom z fotografie odstranili nějaký šum. Zde je to, co získáme ...

3. Detekce okrajů kanyly

Nyní, když máme obraz ve stupních šedi a Gaussově rozmazané, pokusíme se najít všechny okraje na této fotografii.

Okraj je prostě oblast na obrázku, kde je náhlý skok v hodnotě.

Například mezi šedou cestou a přerušovanou bílou čarou je jasný okraj, protože šedá silnice může mít hodnotu něco jako 126, bílá čára má hodnotu blízkou 255 a mezi těmito hodnotami není postupný přechod. .

Filtr detekce hran Canny opět používá k nalezení hran velmi jednoduchou matematiku:

  1. Vyberte pixel na fotografii
  2. Určete hodnotu skupiny pixelů vlevo a skupiny pixelů vpravo od vybraného pixelu
  3. Vezměte rozdíl mezi těmito dvěma skupinami (tj. Odečtěte hodnotu jedné od druhé).
  4. Změňte hodnotu vybraného pixelu na hodnotu rozdílu vypočteného v kroku 3.
  5. Udělejte to pro všechny pixely.

Předstírejte, že se díváme pouze na jeden pixel vlevo a vpravo od vybraného pixelu a představte si, že to jsou hodnoty: (Levý pixel, vybraný pixel, pravý pixel) = (133, 134, 155). Pak bychom vypočítali rozdíl mezi pravým a levým pixelem, 155–133 = 22, a nastavili jsme novou hodnotu vybraného pixelu na 22.

Pokud je vybraný pixel hranou, bude rozdíl mezi levým a pravým pixelem větší číslo (blíže k 255), a proto se ve výstupním obrázku zobrazí jako bílá. Pokud vybraný pixel není hranou, bude rozdíl přibližně 0 a zobrazí se jako černý.

Samozřejmě jste si možná všimli, že výše uvedená metoda najde pouze hrany ve svislém směru, takže musíme provést druhý proces, kde porovnáme pixely nad a pod vybraným pixelem, abychom oslovili hrany v horizontálním směru.

Tyto rozdíly se nazývají gradienty a my můžeme vypočítat celkový gradient v podstatě pomocí Pythagorovy věty pro sčítání jednotlivých příspěvků z vertikálních a horizontálních gradientů. Jinými slovy, můžeme říci, že celkový gradient² = vertikální gradient² + horizontální gradient².

Řekněme například vertikální gradient = 22 a horizontální gradient = 143, pak celkový gradient = sqrt (22² + 143²) = ~ 145.

Výstup vypadá asi takto ...

Filtr detekce hrany Canny Edge nyní dokončuje další krok.

Filtr detekce hran Canny se snaží nejen identifikovat všechny hrany, ale snaží se identifikovat důležité hrany.

Za tímto účelem jsme nastavili dva prahy: vysoký a nízký práh. Řekněme, že vysoká prahová hodnota je 200 a dolní prahová hodnota je 150.

Pro jakýkoli celkový gradient, který má hodnotu vyšší než horní prahová hodnota 200, se tento pixel automaticky považuje za hranu a převede se na čistě bílou (255). Pro jakýkoli celkový gradient, který má hodnotu menší než dolní prahová hodnota 155, se tento pixel automaticky považuje za „ne hranu“ a převede se na čistě černou (0).

Pro jakýkoli gradient mezi 150 a 200 se pixel počítá jako hrana, pouze pokud se přímo dotýká jiného pixelu, který již byl počítán jako hrana.

Předpokládá se, že pokud je tato měkká hrana spojena s tvrdou hranou, je pravděpodobně součástí stejného objektu.

Po dokončení tohoto procesu pro všechny pixely získáme obrázek, který vypadá takto ...

4. Obrázek hran masky

Tento další krok je velmi jednoduchý: Vytvoří se maska, která eliminuje všechny části fotografie, o nichž se domníváme, že nemají pruhy.

Získáme to ...

Vypadá to, že se jedná o docela agresivní a domýšlivou masku, ale to je to, co je v současné době napsáno v původním kódu. Takže, pokračujeme…

5. Hough lines

Posledním krokem je použití Houghovy transformace k nalezení matematického výrazu pro linie pruhu.

Matematika za Houghovou transformací je o něco složitější než všechny vážené průměrné věci, které jsme udělali výše, ale jen stěží.

Zde je základní koncept:

Rovnice pro přímku je y = mx + b, kde m a b jsou konstanty, které představují sklon přímky a přímka y přímky.

V podstatě, pro použití Houghovy transformace, určujeme nějaký dvojrozměrný prostor m a b's. Tento prostor představuje všechny kombinace m a b, o kterých si myslíme, že by bylo možné vytvořit nejvhodnější linii pro linie pruhu.

Poté procházíme tímto prostorem m a b a pro každý pár (m, b) můžeme určit rovnici pro konkrétní řádek tvaru y = mx + b. V této chvíli chceme testovat tuto čáru, takže na fotografii najdeme všechny pixely, které leží na této linii, a požádáme je, aby hlasovali, jestli je to dobrý odhad pro linii pruhu nebo ne. Pixel hlasuje „ano“, pokud je bílý (a.k.a část okraje) a hlasuje „ne“, pokud je černý.

Dvojice (m, b), které získají nejvíce hlasů (nebo v tomto případě dva páry, které získají nejvíce hlasů), jsou určeny jako dva pruhy.

Zde je výstup Houghovy transformace ...

Přeskočím přes část, kde namísto použití vzorce y = mx + b k reprezentaci čáry používá Houghova transformace místo toho polární souřadnice - trigonometrický styl, který používá rho a theta jako dva parametry.

Toto rozlišení není příliš důležité (pro naše porozumění), protože prostor je stále parametrizován ve 2 dimenzích a logika je přesně stejná, ale toto trigonometrické znázornění pomáhá s tím, že nemůžeme vyjádřit zcela svislou čáry s rovnicí y = mx + b.

Proto se ve výše uvedeném kódu používají rho a theta.

Konečný výstup

A máme hotovo.

Program vydává dva parametry k popisu dvou linií jízdních pruhů (zajímavé je, že tyto výstupy jsou převedeny zpět na m, b parametrizace). Program také poskytuje souřadnice koncových bodů každé jízdní pruhy.

Linka 1

Sklon: -0,740605727717; Intercept: 664,075746144

První bod: (475, 311) Druhý bod: (960, 599)

Linka 2

Coef: -0,740605727717; Intercept: 664,075746144

První bod: (475, 311) Druhý bod: (0, 664)

Při překrývání těchto čar na původním obrázku vidíme, že jsme efektivně identifikovali čáry pruhu pomocí základních matematických operací.

Včera jsem dekonstruoval kus kódu, který identifikuje čáry jízdních pruhů v obrazech vozovky směřujících dopředu.

Takhle…

Možná mnohem zajímavější než obrázek, tento blok kódu generuje matematické reprezentace linií pruhu pouze pomocí velmi základních matematických operací (v podstatě řetězec funkcí, které nacházejí vážené průměry):

Řádek 1 = sklon: -0,740605727717; Intercept: 664,075746144

Linka 2 = Coef: -0,740605727717; Intercept: 664,075746144.

Když jsem prošel tímto cvičením, pomohlo mi to lépe intuitivizovat základní mechaniku auta s vlastním řízením, které se už nezdá být tak mystické.

Na základě toho, co jsem dosud experimentoval, se zdá, že existují dva hlavní kroky k vytvoření softwaru pro autosedačky:

Krok 1: Manipulujte se vstupním obrázkem do sady užitečných numerických reprezentací prostředí řízení (tj. Jízdní pruhy, jiná auta, dopravní značky, chodci atd.)

Krok 2: Vložte tuto numerickou reprezentaci světa do funkce, která na základě těchto vstupů vypočítá správný úhel řízení a zrychlení.

Mám podezření, že se funkce v kroku 2 zlepší (jak se v budoucnu zpřístupní rostoucí množství výpočetní energie), stává se předběžné zpracování a kategorizace objektů v kroku 1 stále méně důležité.

Zdá se tedy, že bych měl přesunout pozornost od kroku 1, který se zaměřuje převážně na rozpoznávání objektů a digitalizaci, a místo toho většinu své pozornosti zaměřit na funkci z kroku 2, která mapuje vstupy ze světa do pokynů pro řízení. Tuto funkci nazývám kouzelnou funkcí.

Zdá se to jako rozumný plán, zejména proto, že techniky zpracování obrazu, které jsem popsal včera, byly vynalezeny před desítkami let, kdy se zdá, že magická funkce se teprve nedávno stala proveditelnou.

Nejsem si jistý, zda je tato analýza správná nebo zda je tato cesta optimální, ale toto je právě teď moje intuice založená na tom, co jsem prozkoumal a na cvičeních z posledních několika dnů.

Počínaje zítra začnu zkoumat, jak může magická funkce fungovat a jak ji budu moci postavit.

Včera jsem si uvědomil, že musím přesunout své zaměření a věnovat své úsilí budování nějaké verze magické funkce, což je matematický algoritmus, který mapuje vstupní obrazy silnice na explicitní pokyny pro řízení / řízení pro auto s vlastním pohonem.

Dnes jsem našel datový soubor o kapacitě 223 GB, který byl otevřen společností Udacity (společnost, která dělá online kurzy o technických tématech, včetně aut s vlastním pohonem), která obsahuje přesně to, co potřebuji:

Udacity pořídil video z pomlčkové vačky, rozdělil ho na jednotlivé snímky a poté označil každý snímek odpovídajícím úhlem řízení, který lidský řidič skutečně vykonával.

Například rámec: 1479425444933328937; úhel řízení: -0,36924703940749

Výsledkem je, že tento datový soubor je ideální pro vytvoření a testování magické funkce - mohu požádat kouzelnou funkci o odhad úhlu řízení na základě videa a poté mohu porovnat odhad se skutečným zaznamenaným úhlem řízení.

Pokud je odhad daleko od skutečné hodnoty, mohu funkci aktualizovat a znovu ji otestovat. Teoreticky pak mohu použít počítač, aby mi pomohl iterovat tento proces tisíckrát, a nakonec najít rozumný způsob, jak přesně řídit auto.

Jelikož teprve „teoreticky“ vím, jak to udělat hned teď, vrátil jsem se dnes do Githubu, abych zjistil, zda bych mohl najít někoho, kdo by takto využíval datový soubor Udacity.

Našel jsem několik projektů a doufal jsem, že je dokážu spustit a běžet docela rychle. Asi po dvou hodinách pokusu jsem se však v Terminálu setkal s fatálními chybami - a to ani při spuštění kódu, ale jen při pokusu o nastavení počítače s knihovnami potřebnými ke spuštění kódu na prvním místě.

Před několika dny se mi zdálo, že kdykoli terminál vyvolá chybu, je triviální snadné odpovědět Google a pokračovat vpřed. I když to byla moje zkušenost před několika dny, tato zkušenost pravděpodobně není normou a rozhodně to dnes nebylo.

Takže navzdory všem mým snahám jsem dnes účinně dosáhl nulového pokroku, což je frustrující, ale také část hry.

Zítra budu hrát tuto hru a uvidím, jestli můžu přimět počítač ke spolupráci. Prozatím zůstanu naděje…

Někdy si myslím, že stavební software je nejkrutější forma trestu. Dnes byl jeden z těch dnů.

Na rozdíl od jiných snah, kde i když jsou věci těžké, mohu dosáhnout pomalého neustálého pokroku (nebo alespoň naučit něco cenného z mých selhání), pokusit se přimět počítač, aby úspěšně spustil několik řádků kódu, je jako bouchnout hlavu do zeď, doufat, že když to udělám dostatečně dlouho, něco se nakonec změní.

Když se pustíte do nového kódovacího území, zde je společný graf: 1. Strávte dvě hodiny zkoušením každé možné permutace nastavení kódu / prostředí, abyste zjistili, zda bude fungovat nějaká náhodná kombinace. z vašeho cíle, než když jste začínali (protože jste si pohrávali s tolika věcmi), 3. Pokračujte v pokusech o další hodinu, 4. Magicky se hvězdy vyrovnají a některé nevysvětlitelné kombinace věcí způsobí, že všechno funguje.

Problém s tímto modelem je, že ... musíte zaškrábat zuby a trpět bolestí po neznámé množství času, dokud magicky nedosáhnete nirvany ve Kroku 4. Nevíte, kdy nirvana přichází, ani nevěříte, že to bude někdy přijde, ale musíte pokračovat v off-šanci, že by to mohlo. Neexistuje žádná postupná výplata, pouze frustrace sání duší, dokud magicky nefunguje.

A pak, když to funguje, není nic blaženého. Celá bolest stojí za to na tento jeden okamžik, za předpokladu, že tento okamžik přijde.

Dnes jsem sotva visel.

Jsem hluboko v oblasti, ve které mám málo uzemnění, a v důsledku toho jsem se po většinu dne cítil ztracený a bezmocný.

V těchto případech je často užitečné spoléhat se na videonávody nebo on-line kurzy, ale zatím jsem nenašel přístupný tutoriál (nebo žádný tutoriál), který by mi pomohl uzemnit.

Místo toho jsem dnes strávil asi 2,5 hodiny utopením v kódovací jámě zoufalství. Bylo to brutální a ohrožující důvěru a dnes jsem chtěl mnohokrát připustit porážku, ale dokázal jsem to vydržet.

Nějak jsem si našel cestu ke konci dne a zdá se, že jsem udělal hmatatelný pokrok. Až do zítřejšího rána však nemůžu s jistotou říci: Můj počítač v současné době pracuje dál a pravděpodobně bude dál pracovat celou noc.

Zítra doufám, že se probudím úspěšně spuštěným programem.

Včera v noci jsem se několik hodin utopil v „Coding Pit of Despair“ a konečně jsem udělal nějaký pokrok.

Připomínám, že v posledních několika dnech jsem se snažil najít a spustit kód, který dokáže generovat pokyny k řízení (pro mé auto s vlastním pohonem) na základě vstupních obrazů silnice.

Po mnoha hodinách hledání a hraní jsem našel akademický dokument napsaný vědci v NVIDIA (společnost, která mimo jiné vyrábí hardware a software automobilu s vlastním řízením).

Jak je popsáno v Abstrakt článku, jejich vymyslený systém může „mapovat surové pixely z jediné kamery obrácené přímo na příkazy řízení“.

To je přesně to, co potřebuji!

Poté jsem na Githubu našel implementaci systému NVIDIA TensorFlow a po několika pokusech jsem byl schopen model „vycvičit“ na základě některých dat NVIDIA.

(Aktualizace: Toto ve skutečnosti nejde o data NVIDIA, ale spíše o datový soubor vytvořený Sully Chen. Shromáždil tato data klepnutím na webovou kameru na čelní sklo svého auta a zachycením „dat o řízení“ z portu CAN-BUS svého automobilu. ).

Rychlé vysvětlení některých pojmů: 1. „Model“ je funkce, která popisuje, jak převést pixely na pokyny k řízení, a 2. „Trénovat model“ znamená iterativně zlepšit tuto funkci pomocí technik strojového učení. Tento proces podrobněji vysvětlím v budoucím příspěvku.

Datová sada NVIDIA každopádně zahrnuje 25 minut videa rozděleného po jednotlivých snímcích, kde je každý snímek označen skutečným úhlem řízení (tj. Úhlem řízení, který lidský řidič používal).

Rám 45,522

V Terminálu jsem spustil program pro trénink modelu a přes některá varování to začalo fungovat:

V tomto snímku popisuje „Krok“ pokaždé, když je část dat zaváděna systémem pro výcvik. „Epocha“ je jen širší kategorie, která obsahuje více kroků.

K trénování tohoto modelu jsem použil 30 epoch s několika desítkami kroků na epochu.

Na snímku „Ztráta“ popisuje, jak přesný je model (nebo funkce). Koncepčně se pro výpočet ztráty porovná skutečný úhel řízení s úhlem řízení předpovídaným modelem. Čím větší je rozdíl, tím větší je ztráta.

Nakonec program při tréninku modelu používá několik matematických triků (které popíšu v budoucím příspěvku), aby se pokusil snížit ztrátu prostřednictvím každého iteračního kroku.

Tedy „trénink modelu“ je jen „snižování ztráty“.

Tady je graf s kroky na ose X a ztrátou na ose Y. (Včera v noci, když jsem používal něco, co se nazývalo Tensorboard, to můj počítač vykreslil, zatímco to bylo trénink).

Například v kroku 126 měla ztráta hodnotu 5,708.

Zatímco v kroku 3 241, téměř o šest hodin později, ztráta měla výrazně lepší hodnotu 0,1615.

Nyní, když byl trénink oficiálně ukončen, je nyní model teoreticky připraven řídit vůz, což je super.

Když jsem se dnes z práce dostal domů, pokusil jsem se vyzkoušet model (a.k.a. „řídit auto“) a podívat se, jak to funguje. Bohužel, když jsem se pokusil spustit program, dostal jsem tuto chybu ...

Strávil jsem dobrou hodinu pokusem o překonání tohoto problému, ale zdá se, že část kódu, který jsem stáhl, nelze spustit na počítači Mac (a pokud je to možné, nemohl jsem najít způsob, jak to vyřešit).

Mám nápad na řešení, ale bude muset počkat do zítřka.

Mezitím mohu oslavit skutečnost, že já (pravděpodobně) mám připravený k použití přiměřeně funkční, již vyškolený model s vlastním pohonem. Doufejme, že zítra dokážu přijít na to, jak ji skutečně použít ...

Včera jsem přišel na to, jak trénovat auto s vlastním řízením, ale snažil jsem se potvrdit, že trénink byl skutečně efektivní.

Dnes jsem si rychle uvědomil, že ta část programu, která nefungovala, se týkala pouze vizualizace. Jinými slovy, byl jsem schopen vymazat veškerý vizualizační kód a stále úspěšně vydávat příkazy řízení v reálném čase pro auto.

I když tato čísla jsou dostačující k tomu, aby si samohybné auto pro provedení pokynů, jako člověk, tento výstup je obtížné ocenit.

Naštěstí jsem před několika dny přišel na to, jak uložit jednotlivé zpracované snímky do mého místního počítače.

Rozhodl jsem se tedy z programu vyprodukovat jednotlivé snímky vstupního videa a předpokládanou animaci na volantu.

Pak jsem spojil jednotlivé snímky, překryl dvě videa a stiskl přehrávání. Zde je výsledek ...

Jsem z toho opravdu nadšený!

K objasnění toho, co se děje: Program sledoval nekvalitní záběry z vačkové vačky a poté autonomně animoval volant na základě modelu s vlastním řízením, který jsem včera trénoval. Jinými slovy, počítač řídí toto auto a dělá docela solidní práci.

Dalším krokem je dozvědět se více o základním kódu, optimalizovat jej pro všeobecné použití a poté zjistit, jak se provádí na různých sadách dat (tj. Na různých silnicích). Začnu s datovou sadou Udacity.

Stále si nejsem úplně jistý, že jsem připraven ještě spát v zadní části svého autosedačky, ale dnes rozhodně znamená velký krok vpřed.

Nyní, když mám funkční kód autovládacího vozu (viz video ze včerejška), v následujících několika dnech plánuji kód dekonstruovat a pokusit se přesně pochopit, jak to funguje.

Dnes se budu konkrétně zabývat „modelem“, který lze považovat za maso kódu: Model definuje, jak se vstupní obrázky převádějí na pokyny k řízení.

Dnes už nemám moc času, takže nebudu podrobně popisovat, jak kód funguje (protože zatím nevím a ještě musím udělat spoustu výzkumu). Místo toho uvedu několik hypotéz o tom, co mohou řádky kódu znamenat, a poté zdokumentuji otevřené otázky, které budu muset dále zkoumat.

To mě připraví, abych se naučil materiál strukturovaným způsobem.

Zde je kód pro model s vlastním pohonem jako celek. Je to jen 50 řádků kódu plus komentáře a mezery (což je pěkné ořechy, protože řídí auto a tak…)

importovat tensorflow jako tf
importovat scipy
def weight_variable (tvar):
  initial = tf.truncated_normal (tvar, stddev = 0,1)
  návrat tf.Variable (počáteční)
def bias_variable (tvar):
  Initial = tf.constant (0,1, shape = shape)
  návrat tf.Variable (počáteční)
def conv2d (x, W, stride):
  návrat tf.nn.conv2d (x, W, strides = [1, stride, stride, 1], padding = 'VALID')
x = tf.placeholder (tf.float32, shape = [None, 66, 200, 3])
y_ = tf.placeholder (tf.float32, shape = [None, 1])
x_image = x
# první konvoluční vrstva
W_conv1 = weight_variable ([5, 5, 3, 24])
b_conv1 = bias_variable ([24])
h_conv1 = tf.nn.relu (conv2d (x_image, W_conv1, 2) + b_conv1)
# sekundová konvoluční vrstva
W_conv2 = weight_variable ([5, 5, 24, 36])
b_conv2 = bias_variable ([36])
h_conv2 = tf.nn.relu (conv2d (h_conv1, W_conv2, 2) + b_conv2)
#third convolutional layer
W_conv3 = weight_variable ([5, 5, 36, 48])
b_conv3 = bias_variable ([48])
h_conv3 = tf.nn.relu (conv2d (h_conv2, W_conv3, 2) + b_conv3)
# čtvrtá konvoluční vrstva
W_conv4 = weight_variable ([3, 3, 48, 64])
b_conv4 = bias_variable ([64])
h_conv4 = tf.nn.relu (conv2d (h_conv3, W_conv4, 1) + b_conv4)
# pátá konvoluční vrstva
W_conv5 = weight_variable ([3, 3, 64, 64])
b_conv5 = bias_variable ([64])
h_conv5 = tf.nn.relu (conv2d (h_conv4, W_conv5, 1) + b_conv5)
#FCL 1
W_fc1 = weight_variable ([1152, 1164])
b_fc1 = bias_variable ([1164])
h_conv5_flat = tf.reshape (h_conv5, [-1, 1152])
h_fc1 = tf.nn.relu (tf.matmul (h_conv5_flat, W_fc1) + b_fc1)
keep_prob = tf.placeholder (tf.float32)
h_fc1_drop = tf.nn.dropout (h_fc1, keep_prob)
#FCL 2
W_fc2 = weight_variable ([1164, 100])
b_fc2 = bias_variable ([100])
h_fc2 = tf.nn.relu (tf.matmul (h_fc1_drop, W_fc2) + b_fc2)
h_fc2_drop = tf.nn.dropout (h_fc2, keep_prob)
#FCL 3
W_fc3 = weight_variable ([100, 50])
b_fc3 = bias_variable ([50])
h_fc3 = tf.nn.relu (tf.matmul (h_fc2_drop, W_fc3) + b_fc3)
h_fc3_drop = tf.nn.dropout (h_fc3, keep_prob)
#FCL 4
W_fc4 = weight_variable ([50, 10])
b_fc4 = bias_variable ([10])
h_fc4 = tf.nn.relu (tf.matmul (h_fc3_drop, W_fc4) + b_fc4)
h_fc4_drop = tf.nn.dropout (h_fc4, keep_prob)
#Výstup
W_fc5 = weight_variable ([10, 1])
b_fc5 = bias_variable ([1])
y = tf.mul (tf.atan (tf.matmul (h_fc4_drop, W_fc5) + b_fc5), 2)

Řádkový komentář

Nyní budu procházet kódem v blocích a popisuji, co si myslím, že každý kus znamená / dělá.

importovat tensorflow jako tf
importovat scipy

První dvě řádky jsou přímočaré.

Dovážíme knihovnu TensorFlow (na kterou se v kódu budeme odkazovat jako na „tf“) a knihovnu SciPy. TensorFlow je knihovna pythonů vytvořená společností Google, která pomůže abstraktně odstranit většinu implementací strojového učení na úrovni země. SciPy pomůže s matematickými věcmi.

Nic nového se tu nedozví.

def weight_variable (tvar):
  initial = tf.truncated_normal (tvar, stddev = 0,1)
  návrat tf.Variable (počáteční)
def bias_variable (tvar):
  Initial = tf.constant (0,1, shape = shape)
  návrat tf.Variable (počáteční)

Dobře, takže tady si myslím, že definujeme nové objekty, což v podstatě znamená, že můžeme použít pojem „weight_variable“ a „bias_variable“ jinde v našem kódu, aniž bychom je museli znovu definovat kdykoli.

Ve strojovém učení je funkce, kterou se snažíme řešit, obvykle reprezentována jako Wx + b = y, kde dostaneme x (seznam vstupních obrázků) a y (seznam odpovídajících pokynů k řízení) a chceme najít nejlepší kombinace W a b pro vyvážení rovnic.

W a b ve skutečnosti nejsou jediná čísla, ale sbírka koeficientů. Tyto kolekce jsou vícerozměrné a velikost těchto sbírek odpovídá počtu uzlů v síti strojového učení. (Aspoň takhle to chápu právě teď).

Ve výše uvedeném kódu tedy objekt weight_variable představuje W a objekt bias_variable představuje b ve zobecněném smyslu.

Tyto objekty mají vstup zvaný „tvar“, který v podstatě definuje rozměrnost W a b.

Tyto objekty W a b jsou iniciovány funkcí zvanou „normální“. Jsem si docela jistý, že to znamená, že… když jsou původně vytvořeny kolekce W a b, měly by být hodnoty jednotlivých koeficientů náhodně přiřazeny na základě normálního rozdělení (tj. Zvonové křivky) se standardní odchylkou 0,1. Standardní odchylka více či méně definuje, jak náhodně chceme, aby počáteční koeficienty byly.

Překvapivě si myslím, že tento kód většinou chápu. Na první pohled jsem si nebyl jistý, co se děje, ale jeho psaní mi pomohlo shromáždit mé myšlenky.

Co se ještě musím naučit: Potřebuji se dozvědět více o struktuře Wx + b = y, proč se používá, jak to funguje atd., Ale chápu základy kódu.

def conv2d (x, W, stride):
  návrat tf.nn.conv2d (x, W, strides = [1, stride, stride, 1], padding = 'VALID')

Věřím, že tato conv2d věc je funkce, která provádí jadernou konvoluci na nějakém vstupu. Jádrové závity jsou obecnější třídou manipulace s obrázky, o které jsem se dozvěděl před několika dny.

Pokud jde o mě, jaderná konvoluce manipuluje s obrázkem tak, aby zdůrazňovala jeho charakteristiku, ať už jde o jeho okraje, rohy atd.

Tato konkrétní charakteristika je definována „jádrem“, které se zdá být definováno pomocí strides = [1, stride, stride, 1] from above. I když nevím, co znamenají kroky nebo přesně, jak to funguje.

Vypadá to, že do této funkce pro manipulaci s obrazem existují tři vstupy: 1. Jádro / kroky (řekněme, jak manipulovat s obrázkem); 2. x (což je samotný obrázek); a 3. W (což, myslím, je sada koeficientů, které se používají k míchání různých manipulací obrazu dohromady v nějaké kapacitě).

Musím se dozvědět více o roli W ve všem.

Na vysoké úrovni však tato funkce manipuluje s obrazem nějakým způsobem, aby se obrázek automaticky zmenšil na odlišné funkce, které napomáhají trénovat model.

Co se ještě musím naučit: Jak přesně je konvoluční funkce definována matematicky a jak v tom hraje W roli?

x = tf.placeholder (tf.float32, shape = [None, 66, 200, 3])
y_ = tf.placeholder (tf.float32, shape = [None, 1])
x_image = x

Těchto několik následujících řádků se zdá být docela snadné. Znovu odkazujeme na rovnici Wx + b = y.

Zde definujeme zástupné symboly pro proměnné xay. Tyto zástupné symboly nastavují dimenze proměnných (pamatujte: tyto proměnné představují sbírku hodnot, nejen jediné číslo).

Nastavujeme x, abychom očekávali, že obdrží obraz určitých rozměrů, a nastavujeme y, abychom očekávali jediné číslo jako výstup (tj. Úhel řízení).

Poté přejmenujeme x na „x_image“, abychom si připomněli, že x je obrázek, protože… proč ne.

Nic nového se tu nedozví.

# první konvoluční vrstva
W_conv1 = weight_variable ([5, 5, 3, 24])
b_conv1 = bias_variable ([24])
h_conv1 = tf.nn.relu (conv2d (x_image, W_conv1, 2) + b_conv1)

Dobře, nyní jsme na naší první konvoluční vrstvě.

Definujeme W_conv1, což je pouze konkrétní příklad hmotnosti_variabilní, který jsem vysvětlil výše (ve tvaru [5, 5, 3, 24]). Nejsem si jistý, jak a proč byl tvar nastaven tímto konkrétním způsobem.

Potom definujeme b_conv1, což je jen konkrétní příklad bias_variable, který jsem vysvětlil výše (s tvarem [24]). Těchto 24 pravděpodobně potřebuje, aby odpovídaly 24 z tvaru W_conv1, ale nejsem si jistý proč (jiné než toto pomůže, aby maticové násobení fungovalo).

h_conv1 je přechodný objekt, který aplikuje konvoluční funkci na vstupy x_image a W_conv1, přidá bconv1 na výstup konvoluce a potom vše zpracuje pomocí funkce nazvané relu.

Tato reliéfní věc zní povědomě, ale nepamatuji si přesně, co to dělá. Myslím, že je to nějaký druh „stříkance“ nebo normalizační funkce, která v určité kapacitě vyhlazuje všechno, ať to znamená cokoli. Budu se na to muset podívat.

I když dokážu přečíst většinu kódu, nejsem si úplně jistý, proč je tímto způsobem nastavena „konvoluční vrstva“.

Co se ještě musím naučit: Co je to konvoluční vrstva, co má dělat a jak to dělá?

# sekundová konvoluční vrstva
W_conv2 = weight_variable ([5, 5, 24, 36])
b_conv2 = bias_variable ([36])
h_conv2 = tf.nn.relu (conv2d (h_conv1, W_conv2, 2) + b_conv2)
#third convolutional layer
W_conv3 = weight_variable ([5, 5, 36, 48])
b_conv3 = bias_variable ([48])
h_conv3 = tf.nn.relu (conv2d (h_conv2, W_conv3, 2) + b_conv3)
# čtvrtá konvoluční vrstva
W_conv4 = weight_variable ([3, 3, 48, 64])
b_conv4 = bias_variable ([64])
h_conv4 = tf.nn.relu (conv2d (h_conv3, W_conv4, 1) + b_conv4)
# pátá konvoluční vrstva
W_conv5 = weight_variable ([3, 3, 64, 64])
b_conv5 = bias_variable ([64])
h_conv5 = tf.nn.relu (conv2d (h_conv4, W_conv5, 1) + b_conv5)

Pokračujeme ve vytváření dalších čtyř konvolučních vrstev, které fungují přesně stejným způsobem jako první vrstva, ale namísto použití x_image jako vstupu používají výstup z předchozí vrstvy (tj. H_conv).

Nejsem si jistý, jak jsme se rozhodli použít pět vrstev a jak a proč jsou tvary každého W_conv odlišné.

Co se ještě musím naučit: Proč pět vrstev a jak vybíráme tvary pro každou z nich?

#FCL 1
W_fc1 = weight_variable ([1152, 1164])
b_fc1 = bias_variable ([1164])
h_conv5_flat = tf.reshape (h_conv5, [-1, 1152])
h_fc1 = tf.nn.relu (tf.matmul (h_conv5_flat, W_fc1) + b_fc1)
keep_prob = tf.placeholder (tf.float32)
h_fc1_drop = tf.nn.dropout (h_fc1, keep_prob)
#FCL 2
W_fc2 = weight_variable ([1164, 100])
b_fc2 = bias_variable ([100])
h_fc2 = tf.nn.relu (tf.matmul (h_fc1_drop, W_fc2) + b_fc2)
h_fc2_drop = tf.nn.dropout (h_fc2, keep_prob)
#FCL 3
W_fc3 = weight_variable ([100, 50])
b_fc3 = bias_variable ([50])
h_fc3 = tf.nn.relu (tf.matmul (h_fc2_drop, W_fc3) + b_fc3)
h_fc3_drop = tf.nn.dropout (h_fc3, keep_prob)
#FCL 4
W_fc4 = weight_variable ([50, 10])
b_fc4 = bias_variable ([10])
h_fc4 = tf.nn.relu (tf.matmul (h_fc3_drop, W_fc4) + b_fc4)
h_fc4_drop = tf.nn.dropout (h_fc4, keep_prob)

Dále máme čtyři FCL, což, jak věřím, znamená „plně propojené vrstvy“.

Nastavení pro tyto vrstvy vypadá podobně jako kroky konvoluce, ale nejsem si úplně jistá, co se tady děje. Myslím, že se jedná pouze o věci vanilkové neuronové sítě (o nichž píšu, abych předstírala, že plně chápu „věci vanilkové neuronové sítě“).

Každopádně se na to budu muset podívat více.

Co se ještě musím naučit: Co je to FCL a co se děje v každém kroku FCL?

#Výstup
W_fc5 = weight_variable ([10, 1])
b_fc5 = bias_variable ([1])
y = tf.mul (tf.atan (tf.matmul (h_fc4_drop, W_fc5) + b_fc5), 2)

Nakonec vezmeme výstupy finální vrstvy FCL, uděláme nějaké bláznivé trigonometrické manipulace a poté vydáme y, předpokládaný úhel řízení.

Zdá se, že tento krok je jen „vypracování matematiky“, ale nejsem si jistý.

Co se ještě musím naučit: Jak a proč se výstup vypočítává tímto způsobem?

Hotovo.

Trvalo to déle, než jsem čekal - hlavně proto, že jsem dokázal analyzovat více, než jsem čekal.

Je to trochu šílené, jak velká část implementace byla abstrahována knihovnou TensorFlow a jak málo základních matematických znalostí je potřeba k vybudování plně schopného modelu autovládacího auta.

Jako konstruktéři modelu se jeví jako jediná důležitá věc, jak nastavit hloubku (např. Počet vrstev) modelu, tvary každé vrstvy a typy vrstev.

Myslím, že by to mohlo být více umění než věda, ale pravděpodobně vzdělané umění.

Zítra začnu kopat do otevřených otázek.

Během uplynulých jedenácti dnů jsem udělal značný pokrok v této výzvě měsíce, takže jsem se dnes rozhodl přestávku.

Tato přestávka většinou zahrnovala sledování videí na YouTube na neuronových sítích Convolučná a jaderné spirály, což mi stále pomohlo přiblížit se mému cíli, ale v pasivnější a klidnější podobě.

Zejména jsem sledoval spoustu videí z kanálu YouTube Computerphile, což je osobně můj oblíbený kanál na témata týkající se informatiky.

Tady je video Computerphile o konvolučních neuronových sítích ...

A tady je první video Computerphile ze série o jaderných závadách ...

I když je pro tento měsíc výzva méně důležitá, má Computerphile sesterský kanál YouTube s názvem Numberphile, který diskutuje témata v teorii čísel a obecně matematiku.

Zde je jedno z mých oblíbených videí Numberphile - nabízí skvělý způsob, jak přiblížit hodnotu pi.

Každopádně jsem si dnes užil svou přestávku a zítra se vrátím do práce.

Před dvěma dny jsem prošel masem kódu autovládacího auta a identifikoval otevřené otázky, které jsem měl ohledně toho, jak to funguje.

Jak jsem kopal do těchto otázek, začal jsem si uvědomovat, že z čistě aplikačního hlediska není nutné pochopit většinu základních matematických / počítačových věd, aby se vytvořil účinný systém hlubokého učení. Samozřejmě mě to zajímá, tak jsem se učil, jak to chodí, ale rozhodně to vůbec není podstatné.

V zásadě je důležité vědět:

  1. V konvoluční neuronové síti jsou v horní části „hromady“ konvoluční vrstvy, které se učí, které konvoluční operace (tj. Manipulace s obrázky) zvýrazňují nejlepší funkce, na nichž se lze učit.
  2. Potom existují některé plně propojené vrstvy, které se pokouší naučit, jak vytvořit správný výstup na základě funkcí zvýrazněných konvolučními vrstvami.
  3. Mezi tím, tam jsou některé matematické triky (jako downsampling a usměrňovače), které urychlují proces učení.
  4. Určení tvarů a parametrů vrstev se obvykle provádí empiricky (tj. Vyzkoušejte různé možnosti a vyberte konfiguraci, která poskytuje nejlepší výsledky).

Pokud jde o číslo 4, v dokumentu Nvidia, který popisuje systém hlubokého učení, který používám, vysvětlují, že „konvoluční vrstvy byly navrženy tak, aby prováděly extrakci prvků, a byly vybrány empiricky prostřednictvím řady experimentů, které měnily konfigurace vrstev.“

Tady je punchline: Tajemství zřízení efektivní konvoluční neuronové sítě je vyzkoušet spoustu různých kombinací běžně používaných komponent a zjistit, co funguje nejlépe.

V zásadě, pokud rozumíte základním komponentům, není budování efektivního samohybného automobilu (Nvidia 98% autonomní) mnohem víc než „hádat a kontrolovat“. (Dalo by se tvrdit, že pokud chceme, aby bylo auto z 98% na 100% autonomní, musíme udělat trochu víc, než jen hádat a kontrolovat, což je dnes pravda, ale pravděpodobně se časem stane méně pravdivým, jak jsme kdy stále více aplikovat na tento problém větší výpočetní výkon).

Implementace všech těchto „základních komponent“ jsou samozřejmě složitější, ale naštěstí knihovna TensorFlow v podstatě tuto práci odvedla. Navíc jsme se dostali do bodu, kdy fandové publikují na GitHubu plné modely aut s vlastním pohonem.

Předpovídám, že za 18–24 měsíců se dostaneme na úroveň abstrakce, kde může být auto s vlastním řízením vytvořeno v jednom řádku kódu - což podle mého názoru znamená, že tento měsíc není problém se stárnutím učit.

V tomto ohledu se zdá, že výzva tohoto měsíce ukazuje na následující lekci: Někdy „učení tvrdých věcí“ jen odtrhává nejasnost nebo zastrašování a zjistí, že jakmile se zaměříte, věci nejsou příliš náročné.

Protože se nyní orientuji, nebudu trávit více času kopáním do teorie (alespoň asi příští týden). Místo toho přesunu své zaměření zpět na čistě aplikaci a uvidím, jestli mohu rozšířit možnosti svého vlastního řidiče.

Před několika dny jsem byl schopen spustit nějaký kód a přimět své vozidlo s vlastním pohonem, aby úspěšně řídilo ulicemi (alespoň prakticky na základě videozáznamu NVIDIA).

Dnes jsem chtěl podniknout další krok a zjistit, zda mohu použít model autovládacího vozu na jinou sadu dat. Koneckonců, samohybné auto by mělo být schopné jezdit na jakékoli silnici, nejen po silnicích, na kterých bylo cvičeno.

Proto jsem se rozhodl zjistit, zda model, který jsem minulý týden trénoval, by mohl hrát na datasetu Udacity, který obsahuje jinou sadu silnic.

Prvním krokem bylo zformátování datové sady Udacity, aby ji bylo možné zpracovat pomocí mého modelu vozu s vlastním řízením.

Na rozdíl od datového souboru NVIDIA, který obsahuje videoklip pěkně rozdělený do postupně očíslovaných rámečků (0.jpg, 1.jpg, 2.jpg, 3.jpg atd.), Je datový soubor Udacity soubor matoucími číslovanými obrázky: Mezi čísly jsou zvláštní, nekonzistentní mezery a datová sada začíná počítat na 1479425441182877835.

Udacity měla zřejmě pro toto schéma číslování nějaké důvody, ale nedokážu přijít na to, co to je.

Proto mým prvním krokem bylo přejmenovat všechny tyto soubory tak, aby odpovídaly schématu číslování ve stylu NVIDIA (tj. Začínají na nule a počítají se podle nich).

Nejprve jsem přemýšlel o vložení sluchátek, zapnutí zvukové knihy a ručním přejmenování každého souboru. Pak jsem si uvědomil, že existuje více než 5000 souborů a že bych asi měl přijít na to, jak to automaticky udělat s nějakým kódem (konec konců se snažím vylepšit své kódovací schopnosti tento měsíc).

Asi po 12 minutách nudle jsem dokázal napsat malý skript Pythonu, který přejmenoval všechny soubory Udacity.

import os
def přejmenovat (adresář):
i = 0
pro file_name v os.listdir (adresář):
      new_file_name = str (i) + '.jpg'
      old_file_name = file_name
os.rename (old_file_name, new_file_name)
i + = 1
PATH = os.path.abspath ('/ Users / maxdeutsch / Desktop / nvidia / udacity_data')
přejmenovat (PATH)

Spustil jsem skript a během několika okamžiků byly všechny soubory přejmenovány (jsem rád, že jsem to neudělal ručně).

Poté, co byl datový soubor připraven, nastal čas vyzkoušet model na novém datovém souboru, vydat grafiku autonomně ovládaného volantu a poté překrýt grafiku na vrcholu původního záběru, aby bylo vidět, jak auto funguje.

Je smutné, že výkon je velmi špatný: Pokud by auto s vlastním pohonem skutečně postupovalo podle těchto pokynů v reálném životě, došlo by téměř okamžitě k havárii.

Zítra budu experimentovat s tímto modelem a přijdu na to, jak lépe zobecnit své vozidlo s vlastním řízením, aby nedošlo k nárazu pokaždé, když bude představeno do nového prostředí pro řízení.

Včera jsem se pokusil řídit své vozidlo s vlastním pohonem na nových silnicích (z datového souboru Udacity). Auto však na to nebylo připraveno a opakovaně prakticky havarovalo.

Je zřejmé, že model trénovaný na datovém souboru NVIDIA není vhodný pro datový soubor Udacity.

Jedním rozumným vysvětlením této nesrovnalosti je, že ačkoli obě datové sady obsahují videa směřující dopředu, videa se zřetelně liší, pokud jde o úhel pohledu, rámování a zkreslení objektivu. Výsledkem je, že model trénovaný z jednoho pohledu by na obou neměl fungovat dobře (protože kamera byla přesunuta, zvětšena a znovu změněna).

Zde je rámeček z datového souboru NVIDIA:

A tady je stále z datového souboru Udacity:

Je zřejmé, že tyto pohledy na silnici jsou dostatečně odlišné, kde model trénovaný na jednom souboru dat není použitelný od druhého. (Pokud by obě auta natáčela video ze stejného výhodného bodu, teoreticky by byl model použitelný v obou sadách dat).

Abych tedy mohl pokračovat vpřed, musím trénovat model s vlastním pohonem také na části údajů o Udacity a pak uvidím, jak tento model funguje při testování na zbývajících nových datech.

Dnešní úlohou bylo přeformátovat dataset Udacity tak, aby mohl být použit pro výcvik.

Včera jsem dokončil část tohoto přeformátování, když jsem přejmenoval soubory JPEG Udacity z dlouhých náhodných čísel na sekvenčně označené obrázky.

Z tohoto…

K tomuto…

S připravenými obrázky jsem potřeboval vytvořit textový soubor s názvem „data.txt“ pro datový soubor Udacity, který uvádí správný úhel řízení vedle názvu odpovídajícího obrázku.

Jak vypadá soubor NVIDIA data.txt:

Toto není nejpřesvědčivější uchopení obrazovky, protože prvních 22 úhlů řízení je vynulováno.

Přesto byla data Udacity sestavena v následující tabulce:

Takže pro vytvoření souboru data.txt pro datový soubor Udacity jsem potřeboval provést dvě věci: 1. Přejmenujte frame_ids tak, aby odpovídal včerejšímu číslovacímu schématu; 2. Zjistěte, jak převést tabulku do textového souboru bez formátování ve stylu tabulky.

Namísto použití skriptu Python jsem se pokusil zjistit, jak provést oba kroky v Tabulkách Google (pravděpodobně existuje efektivnější způsob).

Nejprve jsem zadal malé posloupnosti po sobě jdoucích čísel a pak jsem stáhl posloupnost, abych vyplnil dalších ~ 5000 buněk.

Dále jsem použil vestavěné funkce TO_TEXT a CONCATENATE k převodu celých čísel na řetězce a pak tyto řetězce zřetězil pomocí přípony .jpg.

Krok 2 - Převedení tabulky na neformátovaný textový dokument.

Opět jsem použil CONCATENATE, abych sloučil názvy obrázků a úhly řízení do jediné buňky (s oddělovačem jednoho prostoru).

Pak jsem zřetězil každou buňku znakem (10), což je znakový znak pro zalomení řádku. A konečně spojil všechny buňky do jediné buňky.

Zkopíroval jsem obsah této jediné buňky do textového dokumentu a můj soubor data.txt byl připraven.

Jedna zvláštní věc je, že čísla úhlů řízení Udacity se zdají velmi odlišné od čísel úhlů řízení NVIDIA.

Zdá se, že společnosti používají výrazně odlišné reprezentace úhlů řízení, ale nejsem si úplně jistý, jak se obě metody matematicky vztahují.

Možná se mi podaří tento model úspěšně trénovat, aniž bych zjistil tento matematický vztah, ale jsem skeptický.

Zkoumám to zítra a potom začnu trénovat model na datech Udacity.

Včera jsem dokončil formátování nového datového souboru, takže když jsem se dnes vrátil z práce, byl jsem připraven začít model trénovat.

Přesto, když jsem v Terminálu provedl příkaz vlaku, počítač se na chvilku zastavil a pak vyplivl chybu. Konkrétně chyba „seznam indexů mimo rozsah“.

Obvykle se tento druh chyby zobrazí, když program očekává seznam věcí, které jsou delší než skutečný seznam věcí.

Protože datový soubor NVIDIA je delší / větší než datový soubor Udacity, usoudil jsem, že hodnota délky seznamu musí být pevně zakódována a tuto hodnotu mohu odpovídajícím způsobem upravit.

Po prostudování kódu jsem však problém nenašel. Všechno vypadalo, že by to mělo fungovat.

Proto jsem do kódu přidal několik tiskových prohlášení, což by mi pomohlo zjistit, co se děje pod kapotou a přesně tam, kde se program láme.

Spustil jsem program s tiskovými příkazy a dostal tento výstup:

Program úspěšně opakoval všechny řádky skutečných dat a potom se zdálo, že se pokouší analyzovat další řádek dat, který neexistuje.

Otevřel jsem tedy soubor data.txt a jsem si jistý ... Na konci souboru jsem náhodně zkopíroval několik prázdných řádků.

Odstranil jsem tyto tři prázdné řádky a znovu jsem spustil program v Terminálu.

Fungovalo to a model začal trénovat.

Zatímco se vlaky modelu (zítra se na to podíváme), domníval jsem se, že se podělím o rychlou a zábavnou stránku:

Dnes, při dojíždění do práce, jsem míjel autosedačku Google / Waymo poblíž vlakového nádraží Mountain View.

Poté, v mém dojíždějícím domě, pár bloků od mého bytu, jsem viděl dva samohybné Ubery v řadě.

Tady je o něco jasnější obrázek vedoucího Ubera: Vypadá to, že v současné době je motivován člověkem, pravděpodobně pro účely školení. Auto Google jezdilo samo.

Téměř každý den během dojíždění vidím několik aut s vlastním pohonem, ale dnes jsem přemýšlel pouze o pořízení a sdílení několika fotografií. Skutečnost, že už jsem necitlivá k místu samohybného automobilu, je docela šílená - zjevně nejsou tak daleko od všudypřítomné reality (kromě regulace).

Každopádně je docela v pohodě si myslet, že software, který používám na svém osobním počítači, je v podstatě dostatečně výkonný, aby ovládal tato skutečná auta.

Dnes byla smutná sbírka chyb a zátarasů (bez šťastného konce). Když jsem se snažil vykoupit, stále jsem padal hlouběji a hlouběji po králičí díře.

Začalo to včera - úspěšně jsem přeformátoval data Udacity a začal trénovat model s vlastním pohonem.

Poté, co model dokončil trénink, rychle jsem se podíval na graf ztráty (ztráta měří „přesnost“ modelu - čím nižší je ztráta, tím lepší je model ... z větší části).

Po 30 epochách tréninku se ztráta ani neklesla pod 1,00, kde, když jsem trénoval model na datech NVIDIA, ztráta se výrazně snížila pod 1,00, až na ~ 0,16.

Nejsem si jistý, proč jsem čekal něco jiného - datový soubor Udacity, který jsem použil, měl pouze 1/8 velikosti datového souboru NVIDIA.

To byla moje první chyba: náhodou jsem použil testovací datový soubor k tréninku modelu. Místo toho jsem měl použít mnohem větší tréninkový datový soubor a pak vyzkoušet trénovaný model na testovacím datovém souboru.

Není to velký problém: šel jsem na stránku Udacity Github a stáhl jsem větší sadu dat pro trénink. Nebo jsem se alespoň pokusil.

V polovině stahování se počítač úplně vyděsil.

Ukázalo se, že lokální úložný / spouštěcí disk v mém počítači byl úplně plný. Tak plný, že můj počítač odmítl spustit žádné programy. Dokonce i Finder se nečekaně zhroutil.

Připojil jsem externí pevný disk a začal převádět veškerou dokumentaci Měsíc do Master z mého místního počítače.

Mimochodem, stranou jsem musel fotit obrazovku svého počítače pomocí telefonu, protože na mém počítači nebylo dost místa na to, abych mohl dělat snímky obrazovky ...

Každých šest měsíců dokumentace M2M se zatmělo 132 GB, z nichž 70,8 bylo na mém místním počítači, takže jakmile byl převod dokončen, mohl jsem přesunout 70 GB místních věcí do koše.

Poté, co jsem se pokusil vyprázdnit svůj koš, ztuhl můj počítač…

Po několika restartování počítače se můj koš konečně vyprázdnil a o 30 minut později jsem se vrátil do práce.

S prostorem v mém počítači jsem se vrátil na stránku Udacity Github a stáhl jsem datový soubor školení.

Školicí datový soubor byl ve skutečnosti komprimován v torrentu, takže jsem si musel stáhnout BitTorrent, abych mohl stáhnout datový soubor.

Po stažení torrentu jsem soubor rozbalil. Očekával jsem, že uvidím spoustu obrázků JPEG a soubor data.txt, jak jsme viděli dříve, ale místo toho jsem viděl ...

Udacity si zřejmě myslel, že by bylo dobré zabalit data do souborů .bag. Ve skutečnosti jsem nikdy neslyšel o .bagových souborech, ale zdá se, že jsou nativním způsobem, jak autovládací automobily (nebo jiné „roboty“ ukládají data).

Musel jsem tedy přijít na to, jak extrahovat soubory JPEG a CSV z jednotlivých souborů .bag.

K dispozici je knihovna s názvem ROS (Robot Operating System), která je nutná pro práci se soubory .bag, takže jsem se ji pokusil nainstalovat.

Ale tady je to, co jsem našel na instalační stránce ROS…

Jinými slovy, lidé, kteří dělají ROS, v podstatě říkají: „To nebude fungovat. Selže to. Promiňte."

A měli pravdu, selhalo.

Přesto jsem strávil nějaký čas pokusem o vyřešení chyby a nakonec to vypadalo, že jsem úspěšně nainstaloval vše, co jsem potřeboval. Ale pak jsem se pokusil spustit extrakční skript a to stále selhalo.

V tuto chvíli jsem se musel zastavit na noc.

Zítra doufejme, že se mi podaří udělat nějaký pokrok.

Včera jsem se vážně snažil: Snažil jsem se převést soubory ROSbag společnosti Udacity na soubory JPEG a CSV, takže jsem mohl data použít pro trénink svého autosedačky, ale neměl jsem mnoho štěstí.

Nakonec jsem zjistil, že operační systém Robot není kompatibilní s Mac, a tak nemohu správně extrahovat soubory lokálně v mém počítači.

Dnes, po mnoha pokusech a omylech, jsem byl schopen zjistit, jak spustit Ubuntu 14.04 a ROS na virtuálním stroji pomocí VirtualBoxu.

Po dalším pokusu a omylu jsem přišel na to, jak pomocí virtuálního stroje extrahovat obsah souborů ROSbag…

Čekal jsem, že najdu přiměřeně velikou sadu snímků z jedné kamery a CSV pro odpovídající úhel řízení.

Místo toho obsahuje datový soubor Udacity ~ 33 000 snímků z videa pro řízení ze tří různých úhlů pohledu kamery a všechna data pro řízení, brzdění, škrticí klapku, GPS atd.

V rámci řízení CSV například data zahrnují nejen časové razítko a úhel, ale také točivý moment (rotační sílu na kolo) a rychlost (rychlost otáčení).

Každopádně je tento datový soubor super cool a mnohem důkladnější, než jsem očekával. Jsem nadšený, když vidím, jak mohu použít tato data k vytvoření funkčnějšího vozu s vlastním řízením od začátku do konce.

Včera jsem rozbil datový soubor Udacity…

Takže dnes bylo plánováno přeformátovat / připravit data a pak začít trénovat model autovládacího vozu.

Jako první krok jsem se rozhodl prozatím modelovat úhel řízení. Pokud to půjde dobře, pokusím se model rozšířit o škrticí klapku i brzdu.

K přípravě dat jsem potřeboval vytvořit soubor data.txt, který vypadá takto:

V zásadě soubor prostého textu s názvem rámce vedle odpovídajícího úhlu řízení, oddělený mezerou.

Zdálo se to dost jednoduché - ale vyskytl se problém:

Když jsem otevřel soubor volant.csv, žádné časové razítko v souboru neodpovídalo časovým razítkům rámců JPEG. Myslel jsem, že jsem něco přehlédl ...

Prošel jsem tedy obrázky JPEG a zkopíroval jsem prvních pár snímků.

Pak jsem jednotlivě prohledal tato čísla rámců ve formátu CSV, ale neexistovaly ...

To byl problém.

Pokud bych nemohl přiřadit obrázky k jízdním údajům, datová sada se stane naprosto zbytečnou.

Naštěstí jsem měl tak skvělý nápad otevřít další CSV v datovém souboru Udacity (jen abych viděl, co ještě tam bylo), a nakonec jsem otevřel interpolovaný.csv, který obsahuje všechna data na jednom místě A odpovídá všem těmto data do časových razítek na obrázcích dokonale.

Takže jsem měl štěstí.

Vytáhl jsem potřebná data, vytvořil soubor data.txt a začal trénovat model.

Bude to pravděpodobně trvat celou noc, takže se do ní zítra podíváme.

Včera jsem začal trénovat model s vlastním pohonem na základě velkého souboru údajů společnosti Udacity.

Hodnota Ztráta (míra nepřímo úměrná přesnosti modelu) začala na 6.14783.

O mnoho hodin později model dokončil výcvik a snížil ztrátu pouze na 0,000377398.

Tady je děj ztráty v čase:

Toto snížení ztráty je celkem nápadné.

Ještě pozoruhodnější je však rozdíl ve ztrátě při použití 5 000 datových bodů (jako tomu bylo před několika dny), se ztrátou ~ 1,00 a při použití 33 000 datových bodů společnosti Udacity se ztrátou kolem 0,000377398.

Jinými slovy, zvýšením velikosti souboru dat faktorem ~ 7 byla ztráta snížena faktorem ~ 2500. Je zřejmé, že se nejedná o lineární vztah: S trochou více dat se model stává směšně lepším.

A to je důvod, proč si Google může dovolit rozdávat všechny / většinu svých algoritmů a knihoven strojového učení prostřednictvím TensorFlow: Množství dat je rozlišovač a Google má nejvíce (z vyhledávání, e-mailu, fotografií, videí z YouTube atd.)

Ve skutečnosti je v nejlepším zájmu Google otevřít zdroje svých algoritmů, což umožňuje širší komunitě vývojářů vylepšovat algoritmy rychleji. Poté může Google tyto vylepšené algoritmy převzít, nakrmit je vlastními údaji a mít k dispozici nejlepší modely strojového učení se značnou rezervou.

Dnes mi opravdu pomohl ocenit hodnotu dat jako konkurenční výhodu.

Když už mluvíme o datech, dosáhl jsem milníku při vytváření vlastního datového souboru: Dnes si připomínáme 200. den v řadě, kdy jsem v rámci svého projektu Měsíc do mistra napsal blogový příspěvek.

Můj dataset denních záznamů nyní činí přibližně 85 000 slov. Možná, až budu hotový se všemi 365 příspěvky, přijdu na něco zajímavého s tímto datovým souborem…

Včera jsem dokončil trénink svého modelu s vlastním pohonem na datovém souboru Udacity. Dnešní úlohou bylo pokusit se vizualizovat výsledek:

I když jsem očekával, že výsledky budou dobré, předpokládané řízení je zcela přirozené a ne příliš nervózní. S výsledkem jsem velmi potěšen.

Několik poznámek:

  • Původně jsem si myslel, že existují dva datové soubory Udacity: datový soubor školení (který jsem použil včera) a testovací data (které jsem náhodou použil pro výcvik před několika dny). Dnes jsem si uvědomil, že testovací datový soubor je ve skutečnosti podmnožinou tréninkové sady, a tak jsem se místo toho rozhodl použít pro testování některá z dat Nvidia. Důležité je, že model byl vyškolen na datovém souboru Udacity a testován na zcela novém terénu z datového souboru Nvidia. Jinými slovy, model funguje dobře na silnicích mimo tréninkovou sadu (to je velmi důležité, pokud chcete univerzálně funkční samohybné auto).
  • Abychom správně simulovali výstup modelu Udacity, potřeboval jsem udělat dvě věci: 1. Mapovat data Udacity do rozsahu hodnot použitelných simulátorem Nvidia (model Nvidia používá stupně jako jednotky, zatímco datový soubor Udacity se pohybuje od -1 až 1) a 2. Proveďte některé drobné předběžné zpracování do testovací sady Nvidia (tj. Oříznutí) a otestujte model Udacity.
  • Během testování skript vykreslil obrazy volantu otočené na základě předpovídaného úhlu natočení volantu a poté jsem je vykreslil na původní, nezastřižené záběry Nvidia pro mírně širší pohled.
  • Přibližně 40 sekund po videu se vůz zastaví a poté se prudce otočí doprava. Vypadá to, že se auto začne otáčet, než vizuální signály naznačují, že má jít vpravo (auto by mohlo jít rovnou po všem), takže si nejsem úplně jistý, jak k tomu dojde. Dataset Udacity o tomto konkrétním tahu neví. Jediným rozumným vysvětlením je, že model rozpoznal, že je na oplátku, nebo je model spíše prediktivní než člověk. V každém případě to bylo trochu překvapivé, ale bylo to docela skvělé vidět.

S výzvou pro tento měsíc jsem skoro hotový: Potřebuji jen model trénovat na škrtení a rozbití, což, myslím, bude prakticky identické s tím, jak byl model trénován na úhel řízení (konec konců úhel řízení, škrtení a lámání jsou právě reprezentována libovolně definovanými čísly).

Většinu tohoto měsíce jsem se soustředil na vytvoření prediktoru úhlu řízení pro své vozidlo s vlastním řízením.

Abych však dokončil své auto, je důležité, abych pochopil, jak vybudovat systém pro ovládání akcelerátoru / plynu a brzdy automobilu (tj. „Pedály“).

I když to může znít jako zcela nová výzva, ukázalo se, že mohu sestavit svůj pedálový systém bez psaní nového kódu linky.

Koneckonců, můj model řízení byl zkonstruován 1. Zobrazením počítače spoustu obrázků, 2. Přiřazení číselné hodnoty každému obrázku, 3. Požádáním počítače, aby zjistil, jak se pixely obrázků vztahují k číselným hodnotám, 4 Pomocí tohoto vztahu lze predikovat číselnou hodnotu přiřazenou jiným obrázkům.

V případě prediktoru řízení představovala tato číselná hodnota úhel řízení. Ale stejně snadno by mohla představovat škrticí klapku nebo brzdnou částku.

Abychom mohli vytvořit pedálový systém, vše, co jsem potřeboval, bylo znovu přiřadit každému obrazu číselnou hodnotu, která odpovídá správné hodnotě škrticí klapky nebo brzdné hodnotě, a poté požádat počítač (stejným přesným způsobem), aby určil vztah mezi pixely a číselné hodnoty.

Tak jsem to udělal.

Například v případě škrticí klapky jsem připravil data.txt s 10 000 obrázky odpovídajícími jejich odpovídajícímu rozsahu škrticí klapky a pak jsem tento soubor prošel přes stejný model strojového učení.

A jak se očekávalo, model se časem naučil, snížil ztrátu a určil účinný způsob předpovídání množství škrticí klapky.

Totéž jsem udělal pro brzdový systém.

Jinými slovy, model strojového učení, který používám, je zcela obecný. Nezáleží na tom, zda jsou vstupy úhel řízení, hodnoty škrticí klapky nebo brzdné hodnoty. Model nediskriminuje.

To je v jistém smyslu možná anticlimactic, ale v jiném smyslu, docela úžasná věc: Technologie strojového učení se dostala do bodu, kdy nemusíme vytvářet vysoce specializované modely pro každou aplikaci. Místo toho je jediný model v mnoha doménách poměrně rozšiřitelný - a to se bude stále zlepšovat.

Jde o to, že opravdu nemusím dělat mnoho práce, abych dostal plyn a brzdění zdarma. Je to docela dobrý obchod…

Tento měsíc jsem vyzval k tomu, abych vytvořil softwarovou část samohybného automobilu. Zejména jsem chtěl postavit dvě hlavní věci: 1. systém řízení automobilu a 2. systém pedálu automobilu (tj. Škrticí klapku a brzdu).

Před dvěma dny jsem dokončil budování řídícího systému - který dokáže přesně předpovídat úhel řízení na základě videa směřujícího dopředu.

Aby byl systém řízení považován za úspěch, stanovil jsem dva dílčí cíle:

  1. Potřeboval jsem přizpůsobit a použít model autovládacího vozu na datové sadě, pro kterou nebyl speciálně navržen. Protože jsem použil model založený na výzkumném dokumentu NVIDIA aplikovaném na datový soubor poskytovaný společností Udacity, splnil jsem požadavky pro tento dílčí cíl.
  2. Zadruhé, potřeboval jsem model trénovat na jednom datovém souboru (tj. Na sadě silnic) a mít dobrý výkon na úplně jiném datovém souboru (tj. Na sadě nových silnic). Jelikož jsem model trénoval na datovém souboru Udacity a poté úspěšně testoval model na datovém souboru NVIDIA, splnil jsem také požadavky pro tento dílčí cíl.

Pak jsem včera použil stejný model s upravenými datovými vstupy k úspěšnému vytvoření škrticí a brzdicí soustavy, která dokáže přesně předpovědět rychlost škrticí klapky nebo brzdnou částku na základě dopředného toku videa na silnici.

Po sestavení všech těchto kusů je výzva pro tento měsíc oficiálně dokončena!

Včera jsem dokončil tento měsíc výzvu a úspěšně jsem postavil softwarovou část samo-řízení automobilu.

Nyní je otázkou ... Co zbývá udělat / postavit, aby se moje auto skutečně dostalo na silnice v Kalifornii?

Nejlepší odpověď přichází od George Hotze - který byl průkopníkem DIY samohybného automobilu.

Před 18 měsíci zveřejnil Bloomberg video o 26letém Hotzovi, který ve své garáži postavil plně funkční (více či méně) auto s vlastním pohonem:

Ve videu George vysvětluje, že pro vytvoření vozu potřeboval pouze dvě věci: 1. Systém, který mohl vydávat jízdní instrukce na základě vstupních dat, a 2. Systém, který mohl ovládat fyzické ovladače vozidla (tj. volant, škrticí klapka, brzda) na základě digitálních vstupů.

Na začátku tohoto měsíce jsem nazval # 1 „softwarovou část“ a # 2 „hardwarovou část“ a zaměřil své energie na software. Takže, s dokončeným # 1, abych dokončil vývoj mého auta, musel bych oslovit # 2.

Jak vysvětluje Hotz ve videu, za účelem ovládání všech fyzických ovladačů automobilu jednoduše zapojil svůj počítač do ladicího portu automobilu (stejně jako mechanik). Potom samozřejmě musel přijít na to, jak přimět svůj softwarový systém, aby prostřednictvím tohoto portu v reálném čase řádně odesílal instrukce do auta, ale ve skutečnosti nemusel dělat příliš mnoho hardwarového hackování: Auto je již navrženo tak, aby být digitálně ovládán tímto způsobem.

Ne že bych toho o autech moc věděl, ale je to velmi přístupné (pokud mám přístup k internetu a YouTube). Kdybych měl další měsíc, a co je důležitější, auto, byl by to přirozený další krok.

V zásadě se zdá, že samohybné auto typu end-to-end není přece koneckonců mýtické. George Hotz pomohl všem, včetně mě, ukázat, že prostor autovládacího automobilu není přístupný pouze společnostem, jako je Google, ale přiměřeně příležitostným fandům.

Od vydání videa Bloomberg nyní mnoho malých týmů pracuje na autosedačkách a souvisejících službách, což se pravděpodobně v příštím roce výrazně zrychlí.

Doufám, že jsem v tomto příběhu hrál velmi malou roli a pokračoval v demonstraci dostupnosti této technologie ...

Výzva pro tento měsíc je trochu jiná než pro výzvy předcházejícího 6 před měsícem Master. Konkrétně to nebude stárnout velmi dobře ...

V únoru 2017 jsem přistál backflip. Kdyby to bylo místo února 2020, nemělo by to žádný význam.

V prosinci 2016 jsem se naučil kreslit realistické portréty. Kdyby to bylo místo prosince 2036, nemělo by to žádný význam.

Tento měsíc, květen 2017, jsem postavil softwarovou část samohybného automobilu. Pokud by to byl květen 2020, byla by tato výzva úplně jiná.

No, samozřejmě, je to hádání, ale přesto ... Za tři roky je pravděpodobné, že vše, co jsem vytvořil tento měsíc, bude možné dosáhnout jedním řádkem kódu (se vším ostatním budou odebrány).

Nejen to, ale můj osobní počítač bude schopen zpracovat mnohem více dat, mnohem rychleji a vydat exponenciálně lepší model pro auto s vlastním pohonem.

V zásadě říkám, že výzva tohoto měsíce nebude výzvou za pár let.

Ne, že to je tak velký problém, ale je zajímavé přemýšlet o zastaralosti dovedností a o tom, jak se „špičková“ rychle stává „matným středem“.

Možná bych měl zvážit tento měsíc výkonnostní umělecké dílo, kde je představení „příležitostný fanda staví software pro řízení ve světě, kde lidé stále řídí automobily“. Poté by tento měsíc mohl blogy zůstat v blogu časem relevantnější / zajímavější. Koneckonců, umění obvykle časem získává hodnotu.

Každopádně jen pozorování, o kterém jsem si myslel, že stojí za sdílení.

Dnes létám do Seattlu na pětidenní dovolenou, proto jsem se snažil dokončit tento měsíc výzvu o něco dříve.

Když jsem v Seattlu, budu pokračovat ve psaní svých denních příspěvků (protože mám stále co přemýšlet, co se týče mých procesů a technik učení / postřehů), ale nemám v úmyslu pracovat na žádném dalším softwaru .

Proto je důležité stanovit měřitelné cíle: Protože jsem definitivně dosáhl toho, co jsem si stanovil, mohu se cítit dobře na dovolené.

Mnoho lidí často definuje své cíle nejednoznačným způsobem - „Chci se naučit mluvit španělsky“, „Chci se naučit kreslit“, „Chci se naučit hrát na klavír“. V těchto případech není nikdy možné dosáhnout cíle ani není možné skutečně vědět, jak postupujete.

Více definovaný cíl je mnohem výhodnější.

Dalo by se tvrdit, že cíl s otevřeným koncem klade větší důraz na pronásledování a ne na cíl, což, jak souhlasím, je produktivnější způsob myšlení, když se pokouším učit. Bez přesně definovaného cíle však není jasné, co je dokonce sledováno.

Nejednoznačný cíl je podle mého názoru trochu líný cíl, kde tvůrce cíle nemá skutečný základní záměr. Koneckonců, s nejasným cílem, nemůžete selhat (což je možná atraktivní), ale také nemůžete uspět.

A ... Pokud vážně sledujete špatně definovaný cíl, je těžké být vždy spokojený nebo vědět, kdy se zastavit (a soustředit se na další důležité části vašeho života).

Ale stejně, protože jsem dokončil svůj explicitně definovaný cíl, jsem plně připraven užít si výlet do Seattlu bez viny.

Před několika dny jsem prohlásil, že jsem dokončil výzvu autovlásky. Výsledkem bylo v podstatě toto video mého počítače, který řídil auto ...

Zatímco výstupem z tohoto měsíce experimentu byl jistě systém, který dokáže samostatně řídit auto, zůstává otázkou ... Co jsem osobně dosáhl tento měsíc?

Koneckonců, moje vozidlo s vlastním řízením bylo primárně založeno na otevřeném zdrojovém kódu někoho jiného (který jsem si lehce přizpůsobil a zobecnil). Tento otevřený zdrojový kód byl založen na příspěvku, který napsal tým výzkumného týmu motorových vozidel společnosti NVIDIA. Model z výzkumu byl založen na matematických technikách (backpropagation atd.), Které byly vynalezeny mimo laboratoř NVIDIA, zejména v univerzitních výzkumných centrech. A můžu dál…

Tyto matematické techniky jsou postaveny na základních poznatcích z počtu, který byl vynalezen před stovkami let atd.

Mohu to také vzít jiným směrem: Kód, který jsem spustil, byl postaven na horní části knihovny strojového učení vytvořené společností Google, která byla postavena na vrcholu programovacího jazyka na vysoké úrovni, který vytvořili ostatní. Navíc, abych mohl spustit jakýkoli z tohoto kódu, potřeboval jsem nainstalovat potřebné knihovny do mého počítače. Instalace těchto knihoven může být komplikovaná, proto jsem použil instalační služby, které ostatní lidé nastavili, aby se tento proces usnadnil.

Pořád mohu pokračovat… ale nebudu.

Takže se vracím k otázce: Co jsem osobně splnil tento měsíc? Není to úplně jasné.

Na jedné straně mohu říci, že se mi podařilo získat systém autovládacího automobilu, který běží lokálně na mém počítači, a že jsem byl schopen přizpůsobit systém tak, aby účinně zpracovával nové zdroje dat.

Na druhou stranu mohu říci, že jsem vzal práci mnoha dalších lidí a zkombinoval ji, abych vytvořil video.

Oba jsou pravdivé.

Takže jsem vlastně postavil auto s vlastním pohonem? Můžete říci, že společnosti jako OnePlus nebo Xiaomi staví chytré telefony, i když je software vytvořen společností Google a hardwarové komponenty jsou postaveny na Samsungu, Foxconnu a dalších?

Počítá se „shromáždění“ jako „budova“ a počítá se „agregace“ jako „učení“?

Tvrdil bych ano, ale nemyslím si, že je to důležité.

Zajímavější s sebou je toto: Někdy jsou věci, které se zdají náročné nebo nepřístupné, ve skutečnosti mnohem přátelštější pro nováčky, než se zdá. Rozdíl mezi „stavbou autovládacího automobilu“ a ne tím, že jsem si myslel, že to dokážu zjistit, a můj pokus o to.

Jinými slovy, často krát, exkluzivita mistrovství existuje pouze proto, že většina lidí nikdy „věc“ nevykonává (na základě předpokladu, že nemohou).

Chtěl bych tedy přeformulovat to, čeho jsem dosáhl tento měsíc: neprolomil jsem šíleně obtížný problém s budováním autovládacího auta. Místo toho jsem si dokázal, že stavba autovládacího automobilu (jako dnes) není ve skutečnosti šíleně obtížným problémem. V tuto chvíli se domnívám, že většina náhodných fandů mohla přijít na to.

Myslím, že je to stejně zajímavější výsledek.

Během tohoto měsíce, když jsem se snažil odhalit záhady aut s vlastním pohonem, jsem dostal jednu otázku více než kterákoli jiná: Nyní, když už lépe rozumíte technologii, cítíte se více či méně bezpečně při vstupu do plně samohybné auto?

Řekl bych bezpečnější, ale je to složité: Jednoduchost modelu s vlastním pohonem mi dává jistotu, že s větším množstvím dat a zpracovatelským výkonem se schopnosti samostatně řídit budou stále exponenciálně lepší. Iracionální část mého mozku se však cítí divně se skutečností, že model je tak jednoduchý a nespecifický pro řízení.

Nicméně čím jednodušší je model, tím je zobecnitelnější a trénovatelnější, takže se cítím docela bezpečně ohledně vyhlídky na plně autonomní auta (No, cítím se bezpečně psát, že se cítím bezpečně. Vlastně mě vložte do auta a uvidím, jestli změnit mou melodii ...).

Jednou z běžných otázek, které jsem slyšel v reakci na moji obecnou pohodlnost, je: „Nechtěli byste raději ovládat svůj život? I když je používání statisticky bezpečnějšího celku pro použití plně autonomního automobilu, nechtěli byste vědět, že jste udělali vše, co jste si osobně mohli udržet naživu? “

Jaksi. Ale po pravdě řečeno, protože nevlastním auto a už svým životem důvěřuji cizím (řidiče Uber / Lyft), nejsem si jistý, že v současné době mám kontrolu stejně.

Jako krátký dodatek: Před dvěma dny zveřejnil MIT svůj roční výzkumný dokument o současném stavu zájmu spotřebitelů o automobily s vlastním pohonem a 48% z 3 000 účastníků studie uvedlo, že si nikdy nekoupí auto, které se zcela řídí.

Nejen to, ale v loňském roce 40% lidí ve věku 25–34 let uvedlo, že by s pohodlným vozidlem bez řidiče vyhovovalo, a přesto jen letos uvedlo to samé jen 20% ze stejné skupiny.

Je zajímavé vidět, že jak se veřejnost dozví více o autech s vlastním pohonem, jejich pohodlí klesá.

Upřímně řečeno, po přečtení příspěvku MIT bych možná souhlasil s širokou veřejností (přinejmenším od dnešního dne ... Ale stále jsem docela optimistický).

Momentálně navštěvuji přítele v Seattlu, který mi dává těžký čas ohledně příspěvku, který jsem napsal před dvěma dny:

V tomto příspěvku vysvětluji, že jsem dokázal využít kolektivní znalosti a práci mnoha dalších k tomu, abych výrazně urychlil své snahy o řízení autem. Zejména jsem nemusel stavět model strojového učení od nuly, ale místo toho jsem mohl integrovat již zabudovaný model do mého systému.

Výsledkem je, že slyším spoustu „Pokud jste vlastně nepotřebovali stavět základní model autovládacího vozidla, jaká byla výzva tohoto měsíce ve skutečnosti výzvou?“.

V pátém příspěvku souhlasím s tím, že vnímaná výzva (vytvoření mechanismu s vlastním pohonem) nebyla ve skutečnosti výzvou, ale to neznamená, že vůbec žádná výzva nebyla.

Ve skutečnosti bych tvrdil, že vnímaná výzva není ve skutečnosti nikdy skutečnou výzvou.

Například v listopadu, když jsem se snažil stát se velmistrem paměti zapamatováním pořadí zamíchaného balíčku karet, těžká část si vlastně nevzpomínala. Místo toho zapomněl, co jsem si pamatoval během předchozích pokusů (abych se nezaměnil).

V únoru, když jsem se učil backflip, tvrdá část neměla nic společného s ničím fyzickým nebo atletickým, ale místo toho musela mít co do činění s mentálními bloky a strachem spojeným se sebezáchranou.

Tento měsíc nebyla výzva nevytvářet model s vlastním pohonem, ale místo toho tento model integrovat do mého systému, aby to skutečně fungovalo.

To není překvapivé - většina softwarového inženýrství nemusí nutně stavět úplně nové komponenty. Obvykle jde o to, jak vzít spoustu již existujících komponent, spojit je všechny dohromady a mít výstupní funkci podle očekávání.

Podle mého názoru je softwarové inženýrství hodně podobné transplantaci orgánů: Trik nenalezl náhradní orgán (i když to může být stále dlouhý proces). Trik nutí tělo, aby nový orgán neodmítlo.

Podobně má softwarové inženýrství dvě hlavní výzvy: 1. Nalezení „orgánu“ (tj. Příklad komponenty, kterou chcete vytvořit), 2. Integrace tohoto „orgánu“ do celého těla (tj. Zajištění správného nastavení vývojového prostředí; připojení komponenty k jiným komponentám a službám tak, aby správně interagovala se zbytkem projektu; úprava komponenty tak, aby se chovala očekávaným / potřebným způsobem).

A tak, i když tento měsíc výzva nebyla obtížná kvůli vnímané obtížnosti přimět auto řídit sama, stále jsem strávil spoustu času v kódovací jámě zoufalství tím, že jsem se snažil 1. Najít model autovlákna, který Mohl bych úspěšně spustit, 2. Nastavit prostředí mého počítače na podporu modelu, 3. Formátovat data tak, aby mohla být použita modelem, 4. Naučte se, jak na výstupu něco zajímavého z modelu, 5. Změnit model tak, aby fungoval s různými datovými sadami a pro modelování různých chování.

Celkově vnímaná výzva nebyla výzvou, ale stále ještě bylo spousta tření.

Ve skutečnosti je zde důležitá lekce: Často, když se lidé učí něco nového, mají předem představu o tom, co „bude těžké“ nebo „co se mají naučit“. Výsledkem je, že když se na cestě vyskytnou další obtíže, lidé tyto obtíže vnímají jako překážky namísto dalších částí procesu učení.

Jinými slovy, když lidé bojují o věc, kterou očekávají, že budou bojovat, obvykle mohou ospravedlnit vytrvalost. Pokud však zápasí s něčím, co se zdá být rozptylováním, lidé mají sklon vzdát se (protože si uvědomují, že ztrácí čas).

Je zřejmé, že tato rozptýlení jsou často časem skutečným masem vzdělávací výzvy a, pokud jsou popraskané, odemknou největší pokrok směrem k cíli.

Jak vysvětluje Ryan Holiday: „Překážkou je cesta“

Vaše překážky vám nebrání v tom, abyste sledovali svůj cíl, ale ve skutečnosti definují samotný výkon.

Stojím tedy tím, že vyzývám tento měsíc na výzvu. Ne, že sémantika stejně záleží ... Ale odhaluje to důležité ponaučení o učení a vytrvalosti.

Zítra se chystám projít praktickými deníky a spočítat, jak dlouho jsem strávil v tomto měsíci výzvou.

Než to ale udělám, je důležité si uvědomit, jak jsem tento měsíc strávil svůj čas, a zejména, jak byl můj čas distribuován.

V předchozích měsících byl můj tréninkový čas rovnoměrně rozložen - pokud jsem strávil 30 hodin v průběhu 30 dnů, trávil jsem obvykle jednu hodinu denně.

Tento měsíc však byly délky mých zasedání často výrazně delší a méně jednotné. Abychom pochopili rozdíl v tomto měsíci, musíme pochopit dvě fáze učení a dva typy učení ...

Dvě fáze učení:

  1. Fáze objevu - V této fázi je úkolem studenta prozkoumat pole, objevit nejlepší cestu a navrhnout cvičení v souladu s touto nejlepší cestou.
  2. Fáze školení - V této fázi již studentka ví, co potřebuje procvičovat, a celý svůj čas tráví záměrně a intenzivně zaměřením svého výcviku na tuto nejlepší cestu.

Veškeré učení vyžaduje tyto dvě fáze, ale tyto fáze se mohou v různých typech učení lišit.

Dva typy učení:

  1. Disjointed Learning - Disjointed Learning - Disjointed Learning, Discovery Phase a Phase Training Phase lze sledovat zcela samostatně nebo disjointed způsobem. Například když jsem se učil zapamatovat si balíček karet, dokázal jsem nejprve objevit správnou techniku ​​a poté ji samostatně praktikovat. Disjoinované učení obvykle umožňuje krátké, ale efektivní školení (po nezbytné fázi objevu)
  2. Simultánní učení - V simultánním učení musí být fáze objevování a fáze školení sledovány současně. Simultánní učení obvykle existuje, když ještě neexistuje jasně definovaná cesta (kterou lze navenek objevit), a proto musí být během tréninku odkryta a utvářena. Tento typický proces vyžaduje výrazně delší sezení, protože pokrok je nepředvídatelný a nestrukturovaný.

Během předchozích šesti měsíců výzev jsem byl schopen zaujmout poměrně nesouvislý přístup (nejprve jsem zkoumal nejlepší způsoby, jak trénovat a poté jsem trénoval), což mi umožnilo rovnoměrně distribuovat své školení na krátké, intenzivní sezení po celý měsíc.

Během této výzvy měsíce jsem však neměl luxus jasně definované cesty. Kromě online kurzu společnosti Udacity v hodnotě 2400 USD (za který jsem nebyl připraven zaplatit) neexistoval žádný explicitní plán, který bych mohl dodržovat při stavbě auta s vlastním řízením. Místo toho jsem potřeboval prozkoumat spoustu slepých uliček a kruhových objezdů, než jsem našel svou cestu.

Výsledkem bylo, že moje zasedání tento měsíc obvykle trvala alespoň několik hodin, ale jejich množství bylo menší.

Kdybych se pokusil vyrobit auto s vlastním pohonem v průběhu 45minutových relací, nikdy bych neuspěl. Potřeboval jsem restrukturalizovat a přerozdělit svůj čas tak, aby vyhovoval typu učení, které se uskutečnilo tento měsíc (tj. Simultánní učení).

Obecná cesta je tedy následující: Pokud plánujete přijmout svou osobní výzvu k učení, je důležité určit, jaký typ učení je třeba, a podle toho uspořádat a naplánovat čas.

Vzhledem k tomu, že je téměř konec května, je čas se ohlédnout a zjistit, kolik času jsem strávil výzvou tohoto měsíce.

Většina mého času byla rozdělena do devíti delších relací, v následujících délkách: 1,5 hodiny, 2 hodiny, 2,5 hodiny, 1,5 hodiny, 1 hodinu, 3,5 hodiny, 2,5 hodiny, 1,5 hodiny, 1 hodiny, 3 hodiny.

Také jsem strávil další hodinu čtyřmi 15minutovými sezeními a dalších pět hodin zkoumal, četl a psal (což počítám v případech, kdy byl použit speciálně jako výukový nástroj).

Celkově jsem tedy strávil 26 hodin stavbou svého autosedačky.

Před výpočtem tohoto součtu jsem čekal něco kolem 35–40 hodin, takže jsem byl s tímto výsledkem určitě trochu překvapen. Ale teď to dává smysl: Bylo mnoho dní, kdy jsem se cítil, jako bych investoval čas, ale ve skutečnosti jsem nechal svůj počítač běžet sám, nebo psát podrobnější než obvyklý denní příspěvek (tj. Ve skutečnosti nepracoval na výzva sama).

Zajímavé je, že kdyby všechno šlo tento měsíc dokonale správně, pravděpodobně bych celou výzvu dokončil za pár hodin. Samozřejmě se vše nedařilo, a já jsem nevěděl, co je úplně v pořádku, ale stále… Většinu času, který jsem strávil tento měsíc, jsem strávil hledáním cesty.

„Cesta“ sama o sobě netrvala příliš dlouho.

Dnes je poslední den výzvou pro auto s vlastním pohonem a chci odpovědět na jednu z velkých otázek, které jsem během měsíce dostal: „Myslím, že tu máte něco… Jak z toho vyděláte peníze?“

Je to divné, protože se mě na to nikdo neptal, když jsem se naučil zapamatovat si balíček karet nebo přistát backflip.

Takže tento poslední příspěvek je mou odpovědí na to (i když si nejsem jistý, zda přímo odpovím na otázku) ...

Pro většinu pracujících dospělých je obtížné věnovat čas učení nových dovedností. A ti, kteří najdou čas, se obvykle zaměřují na získávání profesionálně orientovaných schopností.

Jinými slovy, většina dospělých nikdy neusiluje o mistrovství jen kvůli tomu. Jejich snahy jsou spíše obchodně opodstatněné nebo zaměřené na kariéru.

S touto motivací není nic špatného. Ve skutečnosti bych určitě povzbudil kariérně motivované učení než žádné učení. S odbornými dovednostmi je však problém: Zůstávají relevantní nebo zajímavé po dlouhou dobu.

Před výzvou tohoto měsíce jsem trávil čas masteringovými dovednostmi, které mají velmi omezenou komerční hodnotu, pokud existují (jako Rubikovy Cubingovy a kreslicí portréty). Skvělá věc je ... Dokud žiji, budu si moci tyto dovednosti užívat. Jinými slovy, moje počáteční investice přináší teoreticky nekonečné výnosy.

Na druhou stranu, tento měsíc byla moje výzva zaměřena na komerční účely (nebo alespoň mohla být). Kdybych chtěl, mohl bych pravděpodobně sbalit své nově objevené dovednosti v oblasti řízení motorových vozidel a pokusit se stát autoservisem ve velké technické společnosti. Nebo alternativně bych se mohl pokusit nastartovat svůj vlastní start do aut. Nebo bych se mohl pokusit zabalit a prodat své učební osnovy ostatním, kteří mají tyto profesní ambice.

Díky dovednostem, které jsem získal tento měsíc, dokážu dělat spoustu komerčně zajímavých věcí.

Ale tady je to pravé ... Za 24 měsíců (pokud ne dříve) zmizí veškerá tato komerční hodnota. Nejen to, ale za 24 měsíců už nebude tato výzva relevantní nebo intelektuálně zajímavá: Bylo to zajímavé pouze kvůli načasování, stále přiměřeně masitým technickým detailům a současnému vzrušení pro automobily s vlastním pohonem.

Protože tedy nemám žádné ambice z komerčního řízení motorových vozidel, moje zábava s auty s vlastním pohonem pravděpodobně skončí spolu s květnem. Určitě se bavilo dobývat výzvu, ale nejsem si jistý, zda existují nějaké opakující se zábavné možnosti (jako je tomu u Rubikovy kostky, kterou stále každý den opakovaně řeším).

Možná jsem příliš dramatický, ale ve srovnání s komerčně orientovanými dovednostmi mám sklon dávat přednost nadčasovým dovednostem - dovednostem, které si můžete navždy užívat a neustále na nich pracovat.

Mohl bych napsat mnohem více o tom, jak si také myslím, že komerční motivace nemusí být nejproduktivnějším základem pro učení obecně, ale prozatím se budu zabývat tímto bodem.

Hlavním bodem, který chci zdůraznit, je to ... Investujete v současné době do sebe? Snažíte se naučit něco nového? A zejména se snažíte něco nového naučit jen proto, že je to zábava (a nikoli z finančních důvodů)?

Pokud ne, možná to stojí za zvážení.

Ne proto, že si myslím, že nadčasové učení je nějak lepší nebo „elitnější“ nebo něco podobného. Jen si myslím, že je to zábava. A často si nedáváme příležitost se bavit, protože si nemyslíme, že je to praktické.

Zdá se však, že je to praktické, ale přesto se stále mění, a proto bych vás povzbudil, abyste investovali trochu času do nějaké nepraktické zábavy.

Tento příspěvek je součástí mého celoročního projektu zrychleného učení, Měsíc na mistra.

Pokud chcete sledovat mé denní příspěvky, nezapomeňte sledovat tento střední účet.

Chcete-li získat exkluzivní obsah týkající se zrychleného učení, disciplíny a designu životního stylu, přihlaste se k odběru mého informačního bulletinu „jednou za čas“.

Pokud se vám toto podrobné rozdělení líbilo, dejte mi vědět kliknutím na srdce níže. Vždy se to velmi oceňuje.