SISTEM DE COMUNICAȚII WIRELESS PENTRU UN VEHICUL TERESTRU TELEOPERAT [305255]

Licență

SISTEM DE COMUNICAȚII WIRELESS PENTRU UN VEHICUL TERESTRU TELEOPERAT [305255]

Byadmin ianuarie 1, 2024

UNIVERSITATEA “TITU MAIORESCU” DIN BUCUREȘTI

FACULTATEA DE INFORMATICĂ

LUCRARE DE LICENȚĂ

COORDONATOR ȘTIINȚIFIC:

Conf.univ.dr.ing.

Lucian Ștefăniță GRIGORE

ABSOLVENT: [anonimizat]-[anonimizat]

2017

UNIVERSITATEA “TITU MAIORESCU” DIN BUCUREȘTI

FACULTATEA DE INFORMATICĂ

LUCRARE DE LICENȚĂ

SISTEM DE COMUNICAȚII WIRELESS PENTRU UN VEHICUL TERESTRU TELEOPERAT

COORDONATOR ȘTIINȚIFIC:

Conf.univ.dr.ing.

Lucian Ștefăniță GRIGORE

ABSOLVENT: [anonimizat]-[anonimizat]

2017

[anonimizat], legat de suprafața de susținere.

[anonimizat]-se o considerabilă mărire a [anonimizat].

[anonimizat], [anonimizat].

[anonimizat], se mișcă pe suprafețe de sprijin naturale sau artificiale. Deplasarea pe suprafețe trebuie să ia în considerare reacțiunile acestora. Comportarea suprafeței de sprijin depinde în principal de forțele aplicate asupra ei în cursul locomoției. Reacțiunea exercitată de substratul de sprijin depinde de asemenea de forma precum și de natura suprafeței. [anonimizat], denivelări, pante, găuri, etc. [anonimizat], [anonimizat].

Analiza globală a problemei locomoției pe suprafețe conduce la identificarea a [anonimizat]-se și forța de propulsie:

propulsia – forța de împingere exercitată asupra substratului în direcția mișcării;

adeziune – forța care să permită ancorarea pentru faza de propulsie;

coeziunea – forța care să permită rezistența mobilului față de tendințele de detașare a acestuia de substrat;

susținere – forța care să compenseze tendința unor forțe exterioare de prăbușire a mobilului pe suprafața de sprijin.

Analiza condițiilor de mediu în care are loc locomoția mobilului are o [anonimizat], structurale, cinematice și dinamice asupra acestora. Pentru a realiza configurarea geometrică a unui propulsor trebuie luată în calcul influența pe care o au caracteristicile geometrice ale acestuia asupra:

mobilității robotului pe terenuri cu configurații și consistențe diverse;

stabilității robotului pe timpul deplasării și pe timpul executării misiunii specifice.

[anonimizat]. Efectele terenului asupra robotului pot fi grupate în categoriile prezentate în (Fig. 1-1). Configurarea platformei și a propulsorului trebuie să fie rezultatul studierii atente a influenței pe care larga diversitate de parametri ai terenului o exercită asupra caracteristicilor de mobilitate și stabilitate. Platformele trebuie să se caracterizeze printr-o [anonimizat] a [anonimizat]ibilitate ridicată datorită existenței posibilităților de adaptare constructivă și funcțională la cerințele unei palete largi de utilizatori. etc.

Controlerul care se ocupă cu partea de comandă și control a robotului ajustează și reglează elementele de geometrie, cinematică și dinamică în baza unor modele analitice, deja existente. Analiza de stabilitate și de senzitivitate, permite obținerea unui compromis între obiectivele prevăzute în: caietul de sarcini și cerințele de performanță. Modelul dinamic ia în considerare toate tipurile de constrângeri.

Controlerul funcționează dual: fie generează traiectorii fie introduce principiile navigării reactive. Reglarea, din punct de vedere analitic, utilizează următorul sistem de ecuații:

(1.1)

unde: F – modul de ; m – masa robotului; Izz – momentul de inerție în jurul axei verticale; b – coeficientul de frecare vâscoasă; – coeficientul de frecare Coulomb.

Simplificările, legate de termenii neglijabili, conduc la transformarea ecuațiilor (1.1), astfel:

(1.2)

Ecuația (1.2) s-a generat în urma acțiunii forței . Modelul ține cont de constrângerile cinematice și dinamice. Modelul de referință poate determina:

poziția robotului: , care se compară cu datele măsurate: .

Indiferent de metodele de analiză numerică și experimentale, apar erori . Acest lucru impune efectuarea unui control (Fig. 1-5).

Controlerul acționează asupra driverelor de motoare, pentru a putea controla viteza robotului în baza ecuației: . Această ecuație este valabilă doar dacă:

viteza de reacție a controlerului este mult mai mare decât a întregului sistem de control;

accelerațiile care pot fi impuse prin controller se regăsesc în intervalul de accelerare al robotului.

Funcțiile de transfer pentru vitezele controlate au valoarea 1. Modelul de referință în sine poate fi folosit ca un controler în buclă directă. În acest caz, eroarea , între robotul de locație și locația calculată , este , iar apoi sistemul de control final este cel reprezentat în blocul cu dublă aliniere. Ecuațiile de mișcare utilizate de controler sunt obținute din modelul:

(1.3)

Stabilitatea traiectoriei se bazează pe modele predictive liniare și neliniare ale dinamicii unui vehicul terestru – MPC (Model Predictive Control).

Schema algoritmului de navigare și control:

. (1.4)

Deformarea cu histerezis a pneului roții, rezistența la rulare Rr , frecări superficiale între pneu și cale, frecările din lagărele roții, deformarea căii, percuția dintre elementele pneului și micro-neregularități ale căii, efectul de ventuză produs de profile cu contur închis pe banda de rulare etc. Rezistența la rulare este luată în considerare prin f – coeficientul rezistenței la rulare, care reprezintă o forță specifică la rulare definită prin relația:

(1.5)

unde: Rr – este rezistența la rulare; – componenta greutății normală pe cale.

Deoarece pneul nu este perfect elastic, energia consumată pentru deformarea elementelor sale componente este mai mare decât energia cedată în timpul revenirii lor la forma inițială, diferența transformându-se în căldură – fenomenul de histerezis.

Având în vedere că rularea pneului pe drum constă dintr-o succesiune continuă de comprimări și destinderi ale elementelor de pneu se poate ușor înțelege că diferența dintre energia consumată la comprimare și cea recuperată la destindere se manifestă prin încălzirea pneului și prin apariția unei forțe rezistente care se opune rulării acestuia.

Reacțiunea Zr va genera un moment de rezistență la rulare, definit prin relația (1.6):

. (1.6)

În articulația de legătură cu puntea asupra roții acționează două forțe perpendiculare: -G greutatea repartizată pe roată; F forța cu care puntea împinge roata. Ca urmare a acțiunii acestor forțe în suprafața de contact a roții cu calea de rulare, apar reacțiunile drumului asupra roții: -Zr reacțiunea normală; -X reacțiunea tangențială. Contactul dintre roată și cale se face pe lungimea l, iar forța Zr este rezultanta forțelor de presiune dintre anvelopă și cale.

MODELUL ANALITICO-NUMERIC PRIVIND DINAMICA ROBOTULUI

Analiza mobilității trebuie să răspundă unor necesități izvorâte din cerințele de mobilitate.

Rezultă că, din punct de vedere al utilității datelor obținute prin simulare, acestea trebuie să descrie performanțele vehiculelor în situațiile de deplasare aflate în concordanță cu profilul misiunii preconizate.

Principalele cerințe impuse procesului de simulare sunt următoarele:

grad înalt de generalizare – să permită simularea unei game largi de tipuri constructive de autovehicule cu roți;

grad ridicat de detaliere – să permită luarea în considerare a caracteristicilor constructive de detaliu ale sistemelor principale componente ale robotului;

flexibilitate sporită – să permită definirea mai multor tipuri de teren, de obstacole sau de condiții de executare a deplasării;

ușurință în exploatare – interfață grafică prietenoasă pentru introducerea datelor și pentru interpretarea rezultatelor;

posibilitatea de interfațare cu programe dedicate pentru analiza datelor.

Aceste cerințe, adesea contradictorii, devin extrem de complexe în condițiile în care nu există încă un cadru conceptual unitar privind descrierea sintetică a caracteristicilor de mobilitate.

Situațiile caracteristice tipice pentru simulare sunt următoarele:

rulaj cu viteză cât mai mare pe cale nedeformabilă (cu acoperământ dur), orizontală sau cu pante longitudinale de maximum 15, cu direcție de deplasare rectilinie sau cu raze de viraj largi;

rulaj pe cale nedeformabilă (cu acoperământ dur), orizontală cu obstacole naturale sau artificiale, cu direcție de deplasare rectilinie pentru scurt timp și cu viraje cu rază mică și/sau cu restricții de gabarit de manevrare;

rulaj pe cale deformabilă, orizontală sau cu pante longitudinale și transversale, cu obstacole naturale sau artificiale, cu direcție de deplasare rectilinie și cu viraje cu rază variabilă.

Parametrii funcționali, care condiționează mobilitatea robotului sunt:

accelerația robotului, dependentă de caracteristicile motorului, masa și dimensiuni;

maniabilitatea robotului, dependentă de tipul motorului și sistemul de viraj;

capacitatea de trecere a diferitelor tipuri de obstacole: banchetă, escarpă, șanț, pantă longitudinală, pantă transversală etc., dependentă de caracteristicile geometrice, tipul de propulsor, momentul la roata și poziția centrului de masă;

Din punct de vedere al resurselor de calcul necesare simulării, sunt posibile două situații distincte:

utilizarea unor programe specializate sau a unor medii de programare pentru rezolvarea punctuală a unei situații singulare, cum ar fi de exemplu: demarajul, trecerea peste obstacolul singular, urcarea pantei etc. În acest caz, se pot utiliza programe specializate (Recurdyn, Matlab etc.) capabile să furnizeze rezultate concludente pentru o situație singulară, cel mai adese corespunzătoare unui teren nedeformabil. Mediile de programare (MathCad, Mathematica, Microsoft Excel) permit efectuarea unor calcule complexe pe baza unor descrieri analitice a fenomenelor studiate;

utilizarea unor programe specializate pentru analiza mobilității de ansamblu a autovehiculelor. În această situație se optimizează introducerea datelor de intrare (bază unică de date), transferul de date între blocurile componente ale programului, realizându-se totodată și unificare conceptuală.

Simularea urcării pantei

Pentru evaluarea potențialului de simulare a simulării realizate pe baza unui model simplu 2D, s-a procedat la schematizarea unui vehicul cu două punți în situația deplasării longitudinale pe pantă. Schematizarea geometrică și a forțelor care acționează asupra robotului este prezentată în Fig. 2-1.

S-au utilizat următoarele notații:

m – masa robotului, în kg;

FTr,f – forța de tracțiune spate, respectiv față, în N;

FNr,f – forța normală spate, respectiv față, în N;

– unghiul de înclinare a pantei longitudinale, în grade;

Lcg, – distanța centrului de masă față de axa punții față, în m;

hcg – distanța centrului de masă față de suprafața căii de rulare, în m;

Lw, – distanța dintre axele punților, în m;

– coeficient de indicare a axei motoare, având valoarea 1 dacă axa este motoare, respectiv 0 dacă axa nu este motoare.

Ecuațiile de echilibru a forțelor și momentelor care acționează asupra robotului sunt următoarele:

[N] ; (2.1)

[N] ; (2.2)

[Nm] . (2.3)

Ecuațiile (2.1), (2.2) și (2.3) permit determinarea expresiilor pentru forțele normale care acționează asupra roților și ale coeficientului de aderență minim care asigură valorificarea forțelor de tracțiune:

[N] ; (2.4)

[N] ; (2.5)

[-] ; (2.6)

[rad] . (2.7)

Relațiile (2.4)÷(2.7) pot fi utilizate pentru studiul prin simulare al condițiilor de urcare a pantei longitudinale.

O primă situație supusă simulării este cea în care momentul motor este distribuit ambelor punți sau unei singure punți.

Simularea prezentată nu ia în considerare coeficientul de aderență necesar pentru punerea în valoare a momentului de tracțiune. Studiul detaliat al valorii minime necesare pentru coeficientul de aderență a condus la rezultatele prezentate grafic în (Fig. 2-2).

Din analiza rezultatelor obținute, rezultă că soluția tracțiunii integrale este cea mai favorabilă, urmată de cea la care fluxul de putere se transmite integral punții din spate. Autovehiculul cu tracțiune față nu poate urca panta datorită pierderii aderenței la puntea motoare pentru unghiuri ale pantei longitudinale mai mari de 18ș.

Concluzii

Simularea executată permite formularea următoarelor concluzii:

Modelul este simplu și ușor de exploatat;

Corelația dintre parametrii constructivi și caracteristicile funcționale este ușor de scos în evidență și de optimizat la nivel grosier;

Simplitatea modelului îl face rapid integrabil în modele complexe pentru simularea mobilității.

Simularea traversării obstacolului tip treaptă

Simularea traversării unui obstacol tip treaptă s-a realizat în două variante:

obstacolul este abordat cu ambele roți de la punte

obstacolul este abordat cu o singură roată a punții.

Schematizarea utilizată pentru simulare este prezentată în (Fig. 2-4).

În plus față de (Fig. 2-3), s-au folosit următoarele notații:

h – înălțimea obstacolului m;

R,Fw – momentul de tracțiune spate, respectiv față, în [Nm].

Utilizând schematizarea din (Fig. 4.4), rezultă următoarele relații geometrice:

[-] ; (2.8)

[-] . (2.9)

Ecuațiile de echilibru pentru forțele și momentele care acționează asupra robotului sunt următoarele:

[N] ; (2.10)

[N] ; (2.11)

[Nm] . (2.12)

Se introduc următoarele notații:

[m] ; (2.13)

[m] ; (2.14)

[m] ; (2.15)

[m] ; (2.16)

Cu notațiile (2.13) ÷ (2.16) și din ecuațiile (2.10)÷(2.12) se obține în final următoarea ecuație de gradul doi:

, (2.17)

cu soluția pozitivă următoare:

, (2.18)

Relația (2.18) permite determinarea coeficientului de aderență necesar pentru traversarea obstacolului.

Din ecuațiile (2.10)÷(2.12) rezultă expresiile forțelor normale care acționează asupra roților:

[N] . (2.19)

[N] . (2.20)

În cazul în care se traversează obstacolul de către o singură roată, rezultă următoarele ecuații:

[N] ; (2.21)

, (2.22)

[N] . (2.23)

[N] . (2.24)

ROBOTUL FlexyBot

Structura de bază a robotului constă în:

DG02S-A130GEARMOTOR – motor electric și mini reductor:

caracteristici motor:

tensiune alimentare 3 [V] DC;

125 [mA] – max. 170 [mA];

Turația nominală 6510 [rpm]

caracteristici reductor:

raport multiplicare 48:1;

acumulatori:

10.000 [mAh] 5 [V];

2.100 [mAh] 5 [V];

cablaje necesare pentru alimentare și transmitere date;

controler/placă Arduino UNO V3 (sau altă placă de tip Arduino);

senzori de distanță GP2Y0D810Z0F;

senzori infraroșu;

șasiu cu dimensiunile: 178L x 135W x 78H [mm];

roți cu diametrul de 78 [mm];

traductor bidirecțional PCA9306 care are două stări de tensiuni de lucru: joasă 1.0÷3.6 [V] și mare 1.8÷5.5 [V]. Are rolul de a traduce nivelele logice între dispozitivul principal și dispozitivul țintă, care poate varia de la 2.8 [V], 3.3 [V] și 5 [V].

Scopul robotului FlexyBot este de a permite efectuarea unor misiuni de patrulare și preluare imagini, care vor fi transmise WiFi către un centru de comandă. Acest lucru presupune utilizarea unui controler Raspberry PI 3 B V1.2.

Robotul, în forma inițială, era programat cu un Arduino, alimentarea motoarelor fiind efectuată cu ajutorul unor drivere de motoare, model L298. În noua configurație se vor utiliza relee de 5V la 1 A (Fig. 3-4).

Programarea platformei Raspberry PI necesită un soft de operare acceptat pe Windows 10 IoT Core, precum și tipurile de aplicații UWP și non-UWP acceptate pe Core IoT (Platformele Universale Windows Platform UWP – Universal Windows Platform).

IoT Core este un sistem de operare UWP centric și aplicațiile UWP sunt tipul său principal de aplicație. Platforma Windows universală (UWP) este o platformă comună de aplicații pentru toată versiunea Windows 10, inclusiv Windows 10 IoT Core. UWP este o evoluție a Windows Runtime (WinRT).

Visual Studio este instrumentul principal pentru scrierea aplicațiilor UWP pentru Core IoT și are compatibilitate pe MSDN. Aplicațiile UWP funcționează doar pe Core IoT, la fel ca și în alte ediții Windows 10. O aplicație Xaml simplă și necompletată în Visual Studio va fi implementată în mod corespunzător pe dispozitivul IoT Core la fel ca pe un telefon sau pe un computer Windows 10. Ultimul xml ar trebui să arate astfel:

<Package

xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10"

xmlns:mp="http://schemas.microsoft.com/appx/2014/phone/manifest"

xmlns:uap="http://schemas.microsoft.com/appx/manifest/uap/windows10"

xmlns:iot="http://schemas.microsoft.com/appx/manifest/iot/windows10"

IgnorableNamespaces="uap mp iot">

Raspberry lucrează cu așa zisa noțiune de „Aplicație de Fundal”, care față de aplicațiile UI tradiționale, nu au o componentă UI, ci o clasă care implementează interfața "IBackgroundTask". Această clasă este înregistrată ca un "StartupTask" pentru a putea efectua boot-area sistemului. Deoarece acestea sunt încă aplicații UWP, ele au acces la același set de API-uri și sunt acceptate din aceeași limbă. Singura diferență este că nu există un punct de intrare pentru UI.

Fiecare tip de IBackgroundTask își are propria politică de resurse. De obicei, acest lucru este restrictiv pentru îmbunătățirea duratei de viață a bateriei și a resurselor mașinilor pe dispozitivele în care aceste aplicații de fundal sunt componente secundare ale aplicațiilor UI din prim plan. Pe dispozitivele IOT, aplicațiile de fundal sunt adesea principala funcție a dispozitivului și, astfel, aceste StartupTask au o politică de resurse care oglindesc aplicațiile UI de pe alte dispozitive.

În următorul exemplu se prezintă codul necesar pentru a crea o aplicație de fundal, în limbaj de programare C # și care arată cum poat determina un LED să se stingă și aprindă succesiv (să clipească):

namespace BlinkyHeadlessCS

{

public sealed class StartupTask : IBackgroundTask

{

BackgroundTaskDeferral deferral;

private GpioPinValue value = GpioPinValue.High;

private const int LED_PIN = 5;

private GpioPin pin;

private ThreadPoolTimer timer;

public void Run(IBackgroundTaskInstance taskInstance)

{

deferral = taskInstance.GetDeferral();

InitGPIO();

timer = ThreadPoolTimer.CreatePeriodicTimer(Timer_Tick, TimeSpan.FromMilliseconds(500));

}

private void InitGPIO()

{

pin = GpioController.GetDefault().OpenPin(LED_PIN);

pin.Write(GpioPinValue.High);

pin.SetDriveMode(GpioPinDriveMode.Output);

}

private void Timer_Tick(ThreadPoolTimer timer)

{

value = (value == GpioPinValue.High) ? GpioPinValue.Low : GpioPinValue.High;

pin.Write(value);

}

Camera de veedre EO – Raspberry Pi Camera V2.1

Camera Raspberry Pi V2.1 este un modul programabil în Python 2.7 sau Python 3.2. Codul este licențiat sub licența BSD: https://opensource.org/licenses/BSD-3-Clause . Codul sursă poate fi descărcat de pe GitHub https://github.com/waveform80/picamera , care găzduiește și tracker-ul de erori https://github.com/waveform80/picamera/issues . Documentația (care include instalarea, exemple de pornire rapidă și multe rețete de cod) poate fi citită pe ReadTheDocs – https://picamera.readthedocs.io/en/release-1.13/ . Pachetele pot fi descărcate de la https://pypi.python.org/pypi/picamera/ .

Această cameră Raspberry Pi V2.1 poate suporta diverse moduri de rată ridicată a cadrelor, dar software-ul putea gestiona doar 30 de cadre pe secundă în modul video de înaltă definiție. Camera funcționează în două moduri de rezoluție:

un modul de captură a fotografiilor, care oferă rezoluția completă a senzorului (2592 × 1944), Full FOV, captură implicit de imagini, 1÷15 [frame/s];

un modul video de 1080 pixeli, care oferă rezoluția completă a senzorului (1920 × 1080), Full FOV, 1÷30 [frame/s].

Camera are multe asemenea seturi de rezoluții posibile de ieșire sau de fragmentare a imaginilor în [frame/s]. Acestea sunt doar seturi de rezoluții și fragmentări de imagini pe care senzorul le poate emite direct pe GPU. Blocul ISP al GPU-ului va redimensiona la orice rezoluție solicitată (în rațiune). Modul senzor 3 al modulului V2 au fost proiectate pentru a imita cele mai apropiate moduri senzoriale ale modulului V1. Expunerile lungi pe modulul V1 necesitau un mod de senzor separat. În următoarea imagine (Fig. 3-6) se ilustrează diferența dintre câmpul vizual complet și parțial pentru camera V2.

Camera Pi V2.1 se poate configura ca Encoder personalizat, având posibilitatea să înlocuim și / sau să extindem clasele de codificatoare utilizate în timpul capturării imaginilor sau a imaginilor video. Acest lucru este util în special în cazul capturilor video, deoarece permite executarea unui cod, propriu, ca răspuns la fiecare cadru, deși, în mod firesc, indiferent de codul rulat în timpul apelării codorului, trebuie să fie suficient de rapid pentru a evita blocarea transferului de date al codificator-ului. Scrierea unui cod personalizat este ceva mai dificilă decât scrierea unei ieșiri personalizate și în majoritatea cazurilor, există puține beneficii. Singurul lucru pe care un codificator personalizat îl oferă este ieșirea personalizată nu poate fi accesată de alte dispozitive. Clasele de Encoder definite de PiCamera formează următoarea ierarhie (Fig. 3-7).

În următoarele tabele sunt detaliate metodele PiCamera care utilizează clasele de codificatoare și ce metodă le cer pentru a construi aceste Encodere:

Este recomandat ca funcția specifică a acestor clase să fie corespunzătoare cerințelor utilizatorului. Pentru a extinde clasa PiCookedVideoEncoder și pentru a stoca câte „i – cadre” și a captura câte „p – cadre”, se execută programul:

import picamera

import picamera.mmal as mmal

# Override PiVideoEncoder to keep track of the number of each type of frame

class MyEncoder(picamera.PiCookedVideoEncoder):

def start(self, output, motion_output=None):

self.parent.i_frames = 0

self.parent.p_frames = 0

super(MyEncoder, self).start(output, motion_output)

def _callback_write(self, buf):

# Only count when buffer indicates it's the end of a frame, and

# it's not an SPS/PPS header (…_CONFIG)

if (

(buf.flags & mmal.MMAL_BUFFER_HEADER_FLAG_FRAME_END) and

not (buf.flags & mmal.MMAL_BUFFER_HEADER_FLAG_CONFIG)

):

if buf.flags & mmal.MMAL_BUFFER_HEADER_FLAG_KEYFRAME:

self.parent.i_frames += 1

else:

self.parent.p_frames += 1

# Remember to return the result of the parent method!

return super(MyEncoder, self)._callback_write(buf)

# Override PiCamera to use our custom encoder for video recording

class MyCamera(picamera.PiCamera):

def __init__(self):

super(MyCamera, self).__init__()

self.i_frames = 0

self.p_frames = 0

def _get_video_encoder(

self, camera_port, output_port, format, resize, **options):

return MyEncoder(

self, camera_port, output_port, format, resize, **options)

K

with MyCamera() as camera:

camera.start_recording('foo.h264')

camera.wait_recording(10)

camera.stop_recording()

print('Recording contains %d I-frames and %d P-frames' % (

camera.i_frames, camera.p_frames))

Prelevarea datelor brute de la Bayer (un mozaic filtru Bayer este o matrice de filtre de culoare (CFA) pentru aranjarea filtrelor de culoare RGB pe o rețea pătrată de foto senzori, aranjamentul său particular de filtre de culoare este folosit în majoritatea senzorilor de imagine digitali cu un singur chip, utilizați în camere digitale, camere video și scanere pentru a crea o imagine color, modelul de filtrare este de 50% verde, 25% roșu și 25% albastru, prin urmare se numește și BGGR, RGBG, GRGB sau RGGB.

Este numit după inventatorul său, Bryce Bayer de la Eastman Kodak. Bayer este de asemenea cunoscut pentru matricea sa definită recursivă utilizată în dithering-ul ordonat.

Alternativele la filtrul Bayer includ atât modificări diferite ale culorilor și aranjamentului, cât și tehnologii complet diferite, cum ar fi eșantionarea în co-site-ul culorilor, senzorul Foveon X3, oglinzile dichroice sau o matrice transparentă a filtrului de difracție.)

Parametrul bayer al metodei capture (Fig. 3-8) determină ca datele brute de la Bayer înregistrate de senzorul camerei să fie trimise ca parte a meta datelor de imagine.

Parametrul bayer funcționează numai cu formatul JPEG și numai pentru capturile de pe port.

Datele brute ale Bayer diferă considerabil de capturările simple necodificate; Datele date de senzorul camerei sunt înregistrate înainte de orice procesare grafică a procesorului, incluzând balansul de alb automat, compensarea vignetului, netezirea, scalarea în jos.

PiCamera captează o imagine care include datele brute ale filtrului Bayer. Apoi continuă să despacheteze datele Bayer într-o matrice tridimensională, reprezentând datele RGB brute și în cele din urmă efectuează un pas de-mozaic rudimentar cu medii ponderate, dar trebuie avut în vedere că toate prelucrările se întâmplă pe CPU și vor fi considerabil mai lente decât imaginile obișnuite:

from __future__ import (

unicode_literals,

absolute_import,

print_function,

division,

)

import io

import time

import picamera

import numpy as np

from numpy.lib.stride_tricks import as_strided

stream = io.BytesIO()

with picamera.PiCamera() as camera:

# Let the camera warm up for a couple of seconds

time.sleep(2)

# Capture the image, including the Bayer data

camera.capture(stream, format='jpeg', bayer=True)

ver = {

'RP_ov5647': 1,

'RP_imx219': 2,

}[camera.exif_tags['IFD0.Model']]

# Extract the raw Bayer data from the end of the stream, check the

# header and strip if off before converting the data into a numpy array

offset = {

1: 6404096,

2: 10270208,

}[ver]

data = stream.getvalue()[-offset:]

assert data[:4] == 'BRCM'

data = data[32768:]

data = np.fromstring(data, dtype=np.uint8)

# For the V1 module, the data consists of 1952 rows of 3264 bytes of data.

# The last 8 rows of data are unused (they only exist because the maximum

# resolution of 1944 rows is rounded up to the nearest 16).

#

# For the V2 module, the data consists of 2480 rows of 4128 bytes of data.

# There's actually 2464 rows of data, but the sensor's raw size is 2466

# rows, rounded up to the nearest multiple of 16: 2480.

#

# Likewise, the last few bytes of each row are unused (why?). Here we

# reshape the data and strip off the unused bytes.

reshape, crop = {

1: ((1952, 3264), (1944, 3240)),

2: ((2480, 4128), (2464, 4100)),

}[ver]

data = data.reshape(reshape)[:crop[0], :crop[1]]

# Horizontally, each row consists of 10-bit values. Every four bytes are

# the high 8-bits of four values, and the 5th byte contains the packed low

# 2-bits of the preceding four values. In other words, the bits of the

# values A, B, C, D and arranged like so:

#

# byte 1 byte 2 byte 3 byte 4 byte 5

# AAAAAAAA BBBBBBBB CCCCCCCC DDDDDDDD AABBCCDD

#

# Here, we convert our data into a 16-bit array, shift all values left by

# 2-bits and unpack the low-order bits from every 5th byte in each row,

# then remove the columns containing the packed bits

data = data.astype(np.uint16) << 2

for byte in range(4):

data[:, byte::5] |= ((data[:, 4::5] >> ((4 – byte) * 2)) & 0b11)

data = np.delete(data, np.s_[4::5], 1)

# Now to split the data up into its red, green, and blue components. The

# Bayer pattern of the OV5647 sensor is BGGR. In other words the first

# row contains alternating green/blue elements, the second row contains

# alternating red/green elements, and so on as illustrated below:

#

# GBGBGBGBGBGBGB

# RGRGRGRGRGRGRG

# GBGBGBGBGBGBGB

# RGRGRGRGRGRGRG

#

# Please note that if you use vflip or hflip to change the orientation

# of the capture, you must flip the Bayer pattern accordingly

rgb = np.zeros(data.shape + (3,), dtype=data.dtype)

rgb[1::2, 0::2, 0] = data[1::2, 0::2] # Red

rgb[0::2, 0::2, 1] = data[0::2, 0::2] # Green

rgb[1::2, 1::2, 1] = data[1::2, 1::2] # Green

rgb[0::2, 1::2, 2] = data[0::2, 1::2] # Blue

# At this point we now have the raw Bayer data with the correct values

# and colors but the data still requires de-mosaicing and

# post-processing. If you wish to do this yourself, end the script here!

#

# Below we present a fairly naive de-mosaic method that simply

# calculates the weighted average of a pixel based on the pixels

# surrounding it. The weighting is provided by a byte representation of

# the Bayer filter which we construct first:

bayer = np.zeros(rgb.shape, dtype=np.uint8)

bayer[1::2, 0::2, 0] = 1 # Red

bayer[0::2, 0::2, 1] = 1 # Green

bayer[1::2, 1::2, 1] = 1 # Green

bayer[0::2, 1::2, 2] = 1 # Blue

# Allocate an array to hold our output with the same shape as the input

# data. After this we define the size of window that will be used to

# calculate each weighted average (3×3). Then we pad out the rgb and

# bayer arrays, adding blank pixels at their edges to compensate for the

# size of the window when calculating averages for edge pixels.

output = np.empty(rgb.shape, dtype=rgb.dtype)

window = (3, 3)

borders = (window[0] – 1, window[1] – 1)

border = (borders[0] // 2, borders[1] // 2)

rgb = np.pad(rgb, [

(border[0], border[0]),

(border[1], border[1]),

(0, 0),

], 'constant')

bayer = np.pad(bayer, [

(border[0], border[0]),

(border[1], border[1]),

(0, 0),

], 'constant')

# For each plane in the RGB data, we use a nifty numpy trick

# (as_strided) to construct a view over the plane of 3×3 matrices. We do

# the same for the bayer array, then use Einstein summation on each

# (np.sum is simpler, but copies the data so it's slower), and divide

# the results to get our weighted average:

for plane in range(3):

p = rgb[…, plane]

b = bayer[…, plane]

pview = as_strided(p, shape=(

p.shape[0] – borders[0],

p.shape[1] – borders[1]) + window, strides=p.strides * 2)

bview = as_strided(b, shape=(

b.shape[0] – borders[0],

b.shape[1] – borders[1]) + window, strides=b.strides * 2)

psum = np.einsum('ijkl->ij', pview)

bsum = np.einsum('ijkl->ij', bview)

output[…, plane] = psum // bsum

# At this point output should contain a reasonably "normal" looking

# image, although it still won't look as good as the camera's normal

# output (as it lacks vignette compensation, AWB, etc).

#

# If you want to view this in most packages (like GIMP) you'll need to

# convert it to 8-bit RGB data. The simplest way to do this is by

# right-shifting everything by 2-bits (yes, this makes all that

# unpacking work at the start rather redundant…)

output = (output >> 2).astype(np.uint8)

with open('image.data', 'wb') as f:

output.tofile(f)

Monitor Touchscreen de 7″ pentru Raspberry Pi B V2.1

Afișajul de 800 x 480 se conectează printr-o placă de adaptare care gestionează convertirea semnalului de alimentare și semnal. Sunt necesare doar două conexiuni la Pi:

alimentarea de la portul GPI al lui Pi;

un cablu de panglică care se conectează la portul DSI prezent pe toate ramele lui Raspberry Pi.

Driverele Touchscreen cu suport pentru o tastatură sunt disponibile pe cel mai recent sistem de operare Raspbian pentru funcționalitate completă fără o tastatură fizică sau un mouse. Driverul suportă o tastatură virtuală „pe ecran”, astfel încât nu este nevoie să se conecteze o tastatură și un mouse. Se pot crea astfel dispozitive „IoT – Internet of Things”, inclusiv un afișaj vizual. Se conectează Raspberry Pi, și se dezvoltă un script Python pentru a interacționa cu afișajul.

Pentru a putea realiza o conexiune corectă a driverelor RPi la RPi trebuie cunoscută codificarea pinilor de contact.

GPIO Pinout este proiectat astfel:

pini pentru plăcile adiționale Raspberry Pi, HAT și pHAT;

BCM – numărul PIN-ului Broadcom, denumit în mod obișnuit "GPIO";

se pot utiliza cu RPi.GPIO și GPIO Zero;

WiringPi – reprezintă cablarea pinului PIN pentru biblioteca Wiring Pi;

numărul fizic este corespunzător locației fizice a pinului de pe antet;

Rev 1 Pi – sunt numere BCM alternative pentru modelul original, cu 26 de pini "A" și "B" Pi.

toate celelalte suprapuneri periferice care utilizează pini GPIO și se găsesc în situația de conflict, trebuie dezactivate. În config.txt, se introduc comentariile aferente sau se inversează orice dtparams care permit I2C sau SPI:

dtparam=i2c_arm=off

dtparam=spi=off

Controlul parametrilor de ieșire, cum ar fi: ceas, culoare, polaritate, sincronizare, activare, etc. poate fi controlat cu un număr trecut la parametrul dpi_output_format în config.txt creat din următoarele câmpuri:

output_format = (dpi_output_format >> 0) & 0xf;

rgb_order = (dpi_output_format >> 4) & 0xf;

output_enable_mode = (dpi_output_format >> 8) & 0x1;

invert_pixel_clock = (dpi_output_format >> 9) & 0x1;

hsync_disable = (dpi_output_format >> 12) & 0x1;

vsync_disable = (dpi_output_format >> 13) & 0x1;

output_enable_disable = (dpi_output_format >> 14) & 0x1;

hsync_polarity = (dpi_output_format >> 16) & 0x1;

vsync_polarity = (dpi_output_format >> 17) & 0x1;

output_enable_polarity = (dpi_output_format >> 18) & 0x1;

hsync_phase = (dpi_output_format >> 20) & 0x1;

vsync_phase = (dpi_output_format >> 21) & 0x1;

output_enable_phase = (dpi_output_format >> 22) & 0x1;

output_format:

1: DPI_OUTPUT_FORMAT_9BIT_666

2: DPI_OUTPUT_FORMAT_16BIT_565_CFG1

3: DPI_OUTPUT_FORMAT_16BIT_565_CFG2

4: DPI_OUTPUT_FORMAT_16BIT_565_CFG3

5: DPI_OUTPUT_FORMAT_18BIT_666_CFG1

6: DPI_OUTPUT_FORMAT_18BIT_666_CFG2

7: DPI_OUTPUT_FORMAT_24BIT_888

rgb_order:

1: DPI_RGB_ORDER_RGB

2: DPI_RGB_ORDER_BGR

3: DPI_RGB_ORDER_GRB

4: DPI_RGB_ORDER_BRG

output_enable_mode:

0: DPI_OUTPUT_ENABLE_MODE_DATA_VALID

1: DPI_OUTPUT_ENABLE_MODE_COMBINED_SYNCS

invert_pixel_clock:

0: RGB Data changes on rising edge and is stable at falling edge

1: RGB Data changes on falling edge and is stable at rising edge.

hsync/vsync/output_enable_polarity:

0: default for HDMI mode

1: inverted

hsync/vsync/oe phases:

0: DPI_PHASE_POSEDGE

1: DPI_PHASE_NEGEDGE

Controlul timpilor sau rezoluțiilor presupune ca parametrii dpi_group și dpi_mode config.txt să fie setați în moduri predeterminate (modurile DMT sau CEA utilizate de HDMI), , sau fiecare utilizator să genereze modul propriu, personalizat. Configurarea în modul HDMI folosește (în config.txt), următoarele instrucțiuni:

dpi_group = 2

dpi_mode = 87

Aceste instrucțiuni vor folosi cronometrele HDMI pentru DPI. Dacă se utilizează opțiunea, parametrul hdmi_timings config.txt este folosit pentru a seta temporizările HDMI (DPI) direct. Parametrii hdmi_timings sunt specificați ca un set de parametri delimitați de spațiu:

hdmi_timings=<h_active_pixels> <h_sync_polarity> <h_front_porch> <h_sync_pulse> <h_back_porch> <v_active_lines> <v_sync_polarity> <v_front_porch> <v_sync_pulse> <v_back_porch> <v_sync_offset_a> <v_sync_offset_b> <pixel_rep> <frame_rate> <interlaced> <pixel_freq> <aspect_ratio>

<h_active_pixels> = horizontal pixels (width)

<h_sync_polarity> = invert hsync polarity

<h_front_porch> = horizontal forward padding from DE acitve edge

<h_sync_pulse> = hsync pulse width in pixel clocks

<h_back_porch> = vertical back padding from DE active edge

<v_active_lines> = vertical pixels height (lines)

<v_sync_polarity> = invert vsync polarity

<v_front_porch> = vertical forward padding from DE active edge

<v_sync_pulse> = vsync pulse width in pixel clocks

<v_back_porch> = vertical back padding from DE active edge

<v_sync_offset_a> = leave at zero

<v_sync_offset_b> = leave at zero

<pixel_rep> = leave at zero

<frame_rate> = screen refresh rate in Hz

<interlaced> = leave at zero

<pixel_freq> = clock frequency (width*height*framerate)

<aspect_ratio> = *

HDMI_ASPECT_4_3 = 1

HDMI_ASPECT_14_9 = 2

HDMI_ASPECT_16_9 = 3

HDMI_ASPECT_5_4 = 4

HDMI_ASPECT_16_10 = 5

HDMI_ASPECT_15_9 = 6

HDMI_ASPECT_21_9 = 7

HDMI_ASPECT_64_27 = 8

/dts-v1/;

/ {

videocore {

clock_routing {

vco@PLLD { freq = <2000000000>; };

chan@DPER { div = <8>; }; // APER will be 500MHz

};

pins_rev1 {

pin_config {

pin@default {

polarity = "active_high";

termination = "pull_down";

startup_state = "inactive";

function = "input";

}; // pin

pin@p2 { function = "i2c1"; termination = "pull_up"; }; // I2C 1 SDA

pin@p3 { function = "i2c1"; termination = "pull_up"; }; // I2C 1 SCL

pin@p5 { function = "output"; termination = "pull_down"; }; // CAM_LED

pin@p6 { function = "output"; termination = "pull_down"; }; // LAN NRESET

pin@p14 { function = "uart0"; termination = "no_pulling"; drive_strength_mA = < 8 >; }; // TX uart0

pin@p15 { function = "uart0"; termination = "pull_up"; drive_strength_mA = < 8 >; }; // RX uart0

pin@p16 { function = "output"; termination = "pull_up"; polarity="active_low"; }; // activity LED

pin@p27 { function = "output"; termination = "no_pulling"; }; // Camera shutdown

pin@p40 { function = "pwm"; termination = "no_pulling"; drive_strength_mA = < 16 >; }; // Left audio

pin@p45 { function = "pwm"; termination = "no_pulling"; drive_strength_mA = < 16 >; }; // Right audio

pin@p46 { function = "input"; termination = "no_pulling"; }; // Hotplug

pin@p47 { function = "input"; termination = "no_pulling"; }; // SD card detect

pin@p48 { function = "sdcard"; termination = "pull_up"; drive_strength_mA = < 8 >; }; // SD CLK

pin@p49 { function = "sdcard"; termination = "pull_up"; drive_strength_mA = < 8 >; }; // SD CMD

pin@p50 { function = "sdcard"; termination = "pull_up"; drive_strength_mA = < 8 >; }; // SD D0

pin@p51 { function = "sdcard"; termination = "pull_up"; drive_strength_mA = < 8 >; }; // SD D1

pin@p52 { function = "sdcard"; termination = "pull_up"; drive_strength_mA = < 8 >; }; // SD D2

pin@p53 { function = "sdcard"; termination = "pull_up"; drive_strength_mA = < 8 >; }; // SD D3

}; // pin_config

pin_defines {

pin_define@HDMI_CONTROL_ATTACHED {

type = "internal";

number = <46>;

};

pin_define@NUM_CAMERAS {

type = "internal";

number = <1>;

};

pin_define@CAMERA_0_UNICAM_PORT {

type = "internal";

number = <1>;

};

pin_define@CAMERA_0_I2C_PORT {

type = "internal";

number = <1>;

};

pin_define@CAMERA_0_SDA_PIN {

type = "internal";

number = <2>;

};

pin_define@CAMERA_0_SCL_PIN {

type = "internal";

number = <3>;

};

pin_define@CAMERA_0_SHUTDOWN {

type = "internal";

number = <27>;

};

pin_define@CAMERA_0_LED {

type = "internal";

number = <5>;

};

pin_define@FLASH_0_ENABLE {

type = "absent";

};

pin_define@FLASH_0_INDICATOR {

type = "absent";

};

pin_define@FLASH_1_ENABLE {

type = "absent";

};

pin_define@FLASH_1_INDICATOR {

type = "absent";

};

pin_define@POWER_LOW {

type = "absent";

};

pin_define@LEDS_DISK_ACTIVITY {

type = "internal";

number = <16>;

};

pin_define@LAN_RESET {

type = "internal";

number = <6>;

};

}; // pin_defines

}; // pins_rev1

pins_rev2 {

pin_config {

pin@default {

polarity = "active_high";

termination = "pull_down";

startup_state = "inactive";

function = "input";

}; // pin

pin@p0 { function = "i2c0"; termination = "pull_up"; }; // I2C 0 SDA

pin@p1 { function = "i2c0"; termination = "pull_up"; }; // I2C 0 SCL

pin@p5 { function = "output"; termination = "pull_down"; }; // CAM_LED

pin@p6 { function = "output"; termination = "pull_down"; }; // LAN NRESET

pin@p14 { function = "uart0"; termination = "no_pulling"; drive_strength_mA = < 8 >; }; // TX uart0

pin@p15 { function = "uart0"; termination = "pull_up"; drive_strength_mA = < 8 >; }; // RX uart0

pin@p16 { function = "output"; termination = "pull_up"; polarity = "active_low"; }; // activity LED

pin@p21 { function = "output"; termination = "no_pulling"; }; // Camera shutdown