Sanntidsbehandling eller lagrede data: hva trenger egentlig VPN?

En robot som slutter å være nyttig én rom borte, har et lenkeproblem eller et arbeidsmengdeproblem lenge før det har et VPN-problem. Kryptering beskytter en vei, men den utvider ikke radiodekningen, og den gjør ikke en fjernberegning ferdig raskere. Beslutningen foran deg er hvilket arbeid som faktisk må krysse nettverket, og det svaret fjerner vanligvis mer trafikk enn folk forventer. Tre vilkår avgjør det, og gjennomstrømning er ikke ett av dem.

Tre oppsett, ett avhengighetsspørsmål

Tabellen skiller oppsettene etter hva som avhenger av lenken, ikke etter hvilken programvare som vises i diagrammet.

Ingen rad i tabellen er et sikkerhetsargument. Styrings- og sikkerhetsfunksjoner trenger fortsatt et kvalifisert svar for forsinkelse, pakketap og en brutt forbindelse, og ingen tunnelindikator gir ett. Tabellen forteller hvor avhengigheten bor, og det er den delen et nettverksdesign faktisk kan endre.

Vilkår én: må svaret være tidsriktig?

Hvis et fjernresultat mater en kontroller, ligger nettverket inne i styringssløyfen, og forsinkelsen, jitteren og utfallene blir styringsegenskaper. Hvis det samme resultatet bare mater en skjerm, et dashbord eller en person som ser på, er den identiske forsinkelsen bare kosmetisk.

Lukket sløyfe over en trådløs lenke er mulig, og det er også der de fleste «VPN-et er tregt»-meldingene oppstår, fordi tunnelen er den synlige komponenten mens radioen og rutingen er årsaken. Mål rundturen til den faktiske meldingen og ikke tunnelens egen ping, og spør deretter om tallet passer i sløyfens budsjett. Hvis det ikke gjør det, flytt trinnet onboard i stedet for å forhandle om et strengere servicenivå for en lenke ingen i rommet kontrollerer. Skriv ned det målte tallet sammen med forholdene det ble tatt under, fordi neste rapport vil komme uten dem.

Vilkår to: hvilken rate, retning og avbrudd kan du erklære?

Skriv ned dataene, raten, retningen og det lengste avbruddet applikasjonen tåler. En kamerastrøm oppover og en kommandokanal nedover feiler på ulike måter, og et avbrudd en stasjonær inspeksjon tåler vil avslutte en oppgave i bevegelse.

Hold den fysiske tilkoblingen og tunnelen atskilt når du sammenligner alternativer, siden en sterkere radio og en mindre arbeidsmengde er ulike reparasjoner. En stor overføring som til slutt fullføres beviser ingenting om et tidskritisk resultat som kommer jevnt, og en sunn tunnel beviser ingenting om radioen bak den.

Reduser så etterspørselen i stedet for å forsvare den. Nedsample observasjonsstrømmen, send sammendrag eller deltaer, og la rå sensordata bli onboard der lagring er billig og overføring ikke er det. En mindre nyttelast svekker argumentet for en raskere lenke og fjerner ofte behovet for en.

Vilkår tre: hvem må se det, og hva blir lokalt

Observasjon er vanligvis et mye mindre krav enn behandling. Hvis en person må se på kameraet og en logg må finnes etterpå, er det telemetri pluss lagring; hvis en modell må kjøre, spør først om den kan kjøre onboard med bare resultatet videresendt. Å flytte det tunge trinnet onboard fjerner den synkrone avhengigheten og etterlater en overføring som kan prøves på nytt.

At to ROS-deltakere finnes på samme robot rettferdiggjør ikke en tunnel i seg selv. Nåbarhet for noder, applikasjonsautorisasjon og en lokal gjenopprettingsplan er separate problemer, og et VPN svarer bare på det første, og bare for trafikken det blir bedt om å rute.

Å ta opp et datasett er sitt eget design, med sine egne kommandoer

For et versjonsbundet eksempel, ROS 2 Jazzy-veiledningen for opptak dekker opptak av utvalgte emner, inspeksjon av den resulterende bagen og avspilling av den. Ta opp de godkjente observasjonsemnene, gi kjøringen et navn, og oppbevar meldingsdefinisjonene og konfigurasjonen ved siden av.

ros2 bag record -o run42 /scan /camera/image_raw
ros2 bag info run42
ros2 bag play run42

Ikke ta opp hvert emne fordi verktøyet gjør det enkelt. Lagring fylles, kamera- og posisjonsdata er sensitive, og en bag med umerkede emner er et analyseproblem for den som åpner den neste gang. Distribusjonen som er installert bestemmer også kommandoene: verktøy skrevet for ROS 1-bager overføres ikke til ROS 2-bager, så tilpass dokumentasjonen til versjonen som er installert på roboten.

Spill av i et isolert analyse- eller simuleringsmiljø. Opptak av kommandotemaer som spilles av inn i en levende robots aktuatorer er en ulykke, og forebyggingen er et eget ROS-domene eller ingen maskinvare i sløyfen i det hele tatt.

Bestem hvor avhengigheten hører hjemme og skriv det ned: et VPN beskytter en utveksling som må skje, behandling onboard fjerner en utveksling som aldri trengte å være synkron, og et lagret datasett erstatter en levende forbruker med en senere. Test så den frakoblede saken med vilje, mens den lokale jobben fortsatt kjører, før noen kaller designet ferdig.