Reaaliaikainen käsittely vai tallennettu data: mitä VPN oikeastaan tarvitsee?
Päättäkää, mikä robotin työ on ylitettävä verkko: oikea-aikaiset tulokset, havainnoinnin telemetria vai tallennettu tietoaineisto. Kolme ehtoa ja sitten bag-komennot.
Robotti, joka lakkaa olemasta hyödyllinen yhden huoneen päästä, kärsii linkki- tai työkuormaongelmasta kauan ennen kuin sillä on VPN-ongelma. Salaus suojaa polun; se ei laajenna radiokuuluvuutta eikä saa etäkaskentaa valmistumaan aikaisemmin. Edessänne oleva päätös on, mikä työ todella on ylitettävä verkko, ja tuo vastaus poistaa yleensä enemmän liikennettä kuin ihmiset odottavat. Kolme ehtoa ratkaisee sen, eikä läpäisykyky ole yksi niistä.
Kolme järjestelyä, yksi riippuvuuskysymys
Taulukko erottaa järjestelyt sen mukaan, mikä riippuu linkistä, ei sen mukaan, mikä ohjelmisto näkyy kaaviossa.
| Arrangement | What depends on the link | What stays onboard |
|---|---|---|
| Live remote processing | The exchange and any timely result the workstation returns | Only what the remote step does not block |
| Onboard processing, remote observation | The declared telemetry or display stream | The processing loop itself |
| Local recording, later analysis | Transfer of one selected dataset | The entire run, including raw sensors |
Mikään taulukon rivi ei ole turvallisuusperustelu. Ohjaus- ja turvatoiminnot tarvitsevat edelleen pätevän vastauksen viiveeseen, pakettihäviöön ja katkenneeseen yhteyteen, eikä mikään tunnelin ilmaisin tarjoa sitä. Taulukko kertoo, missä riippuvuus elää, ja se on osa, jota verkkosuunnittelu voi todella muuttaa.
Ehto yksi: täytyykö vastauksen olla oikea-aikainen?
Jos etätulos syöttää säädintä, verkko istuu säätösilmukan sisällä, ja sen viive, jitter ja katkokset tulevat säädön ominaisuuksiksi. Jos sama tulos syöttää vain näyttöä, kojelautaa tai katselevaa ihmistä, sama viive on kosmeettinen.
Suljetun silmukan työ langattoman linkin yli on mahdollista, ja juuri sieltä useimmat ”VPN on hidas” -raportit syntyvät, koska tunneli on näkyvä komponentti, kun taas radio ja reititys ovat syy. Mittaa varsinaisen viestin edestakaista aikaa tunnelin oman pingin sijaan ja kysy sitten, mahtuuko luku silmukan budjettiin. Kun ei mahdu, siirrä vaihe alukseen sen sijaan, että neuvottelisit tiukemman palvelutason linkille, jota kukaan huoneessa ei hallitse. Kirjaa mitattu luku ylös olosuhteineen, koska seuraava raportti saapuu ilman niitä.
Ehto kaksi: minkä nopeuden, suunnan ja keskeytyksen voitte ilmoittaa?
Kirjoita ylös tiedot, nopeus, suunta ja pisin keskeytys, jonka sovellus sietää. Ylöspäin virtaava kameravirta ja alaspäin menevä komentokanava epäonnistuvat eri tavoin, ja keskeytys, jonka paikallaan oleva tarkastus sietää, lopettaa liikkuvan tehtävän.
Pidä fyysinen liitäntä ja tunneli erillään vaihtoehtoja verratessa, koska vahvempi radio ja pienempi kuorma ovat eri korjauksia. Suuri siirto, joka lopulta valmistuu, ei todista mitään aikakriittisen tuloksen tasaisesta saapumisesta, eikä terve tunneli todista mitään sen takana olevasta radiosta.
Vähennä sitten kysyntää sen puolustamisen sijaan. Harvenna havainnointivirtaa, lähetä yhteenvetoja tai deltoja ja jätä raakatunnistiedot alukseen, missä tallennus on halpaa ja siirto ei. Pienempi hyötykuorma heikentää argumenttia nopeamman linkin puolesta ja poistaa usein tarpeen sille.
Ehto kolme: kenen on nähtävä se, ja mikä pysyy paikallisena
Havainnointi on yleensä paljon pienempi vaatimus kuin käsittely. Jos ihmisen on katsottava kameraa ja jälkeenpäin on oltava loki, se on telemetriaa plus tallennusta; jos mallin on ajettava, kysy ensin, voiko se ajaa aluksessa niin, että vain sen tulos välitetään. Raskaan vaiheen siirtäminen alukseen poistaa synkronisen riippuvuuden ja jättää siirron, joka voidaan toistaa.
Kaksi ROS-osallistujaa samassa robotissa ei yksinään oikeuta tunnelia. Solmujen tavoitettavuus, sovelluksen valtuutus ja paikallinen palautumissuunnitelma ovat erillisiä ongelmia, ja VPN vastaa vain ensimmäiseen, ja vain sille liikenteelle, jota sen pyydetään reitittämään.
Tietoaineiston tallentaminen on oma suunnittelunsa omine komentoineen
Versiosidonnaisesta esimerkistä ROS 2 Jazzy -tallennusopas kattaa valittujen aiheiden tallentamisen, syntyneen bagin tarkastamisen ja sen toistamisen. Tallenna hyväksytyt havainnointiaiheet, anna ajolle nimi ja pidä viestimääritelmät ja kokoonpano sen vieressä.
ros2 bag record -o run42 /scan /camera/image_raw
ros2 bag info run42
ros2 bag play run42
Älä tallenna jokaista aihetta vain siksi, että työkalu tekee siitä helppoa. Tallennustila täyttyy, kamera- ja sijaintitiedot ovat arkaluontoisia, ja bag ilman merkintöjä olevista aiheista on analyysiongelma seuraavalle avaajalle. Käyttöön otettu jakelu määrää myös komennot: ROS 1 -bageille kirjoitetut työkalut eivät siirry ROS 2 -bageille, joten sovita dokumentaatio robottiin asennettuun versioon.
Toista eristetyssä analyysi- tai simulointiympäristössä. Tallennettujen komentoaiheiden toistaminen elävän robotin toimilaitteisiin on onnettomuus, ja ennaltaehkäisy on erillinen ROS-toimialue tai ei lainkaan laitteistoa silmukassa.
Päätä, mihin riippuvuus kuuluu, ja kirjoita se: VPN suojaa vaihtoa, jonka on tapahduttava, aluksessa tapahtuva käsittely poistaa vaihdon, jonka ei koskaan tarvinnut olla synkroninen, ja tallennettu tietoaineisto korvaa live-kuluttajan myöhemmällä. Testaa sitten tarkoituksella yhteydetön tapaus paikallisen työn vielä käydessä, ennen kuin kukaan julistaa suunnittelun valmiiksi.