- iPhone topik
- Samsung Galaxy S22 Ultra - na, kinél van toll?
- Yettel topik
- Nem várt platformon a OnePlus Nord 5
- CMF Phone 2 Pro - a százezer forintos kérdés
- India felől közelít egy 7550 mAh-s Redmi
- Samsung Galaxy A54 - türelemjáték
- Google Pixel 9a - a lapos munka
- Mobilinternet EU-n kívül, eSIM adatcsomagok használata
- Motorola Edge 50 Neo - az egyensúly gyengesége
-
Mobilarena
Arduino hardverrel és szoftverrel foglakozó téma. Minden mikrovezérlő ami arduinoval programozható, és minden arduino program, board, és hardverrel kapcsolatos kérdések helye.
Új hozzászólás Aktív témák
-
válasz
daninet
#13679
üzenetére
Állapotgép. Egy végtelen ciklusban minden alkalommal beolvasod a bemenet értékét. Kell egy változó, amit még a ciklus előtt deklarálsz, és amiben az előző állapotot tárolod. A beolvasás után összehasonlítod az aktuális állapotot az előző ciklusban elmentett állapottal, ha nem egyforma, akkor végrehajtod a feladatot, amit változáskor kell lefuttatni, felülírod az előző állapotot a mostanival és kész.
-
válasz
zsolti_20
#13658
üzenetére
Szerintem félreértés van, az lehet a lassúság oka, hogy a serial kapcsolat felépülésekor az arduino reseteli magát!
Tegyél egy 10 uF kondenzátort a reset és a gnd közé, és nézd meg, hogy megszünteti-e a késleltetést. (Programozás előtt ezt nyilvánvalóan ki kell húzni, mert nem fogod tudni feltölteni a programot)
Ha nem, akkor sem tartom valószínűnek, hogy az arduino lassúsága lenne az oka, bár nem írod, milyen boardról nem szó, de az uno 16MHz sebessége azért nem annyira lassú, hogy ilyen késést okozzon. Mekkora bitrátával küldöd az adatot? Jó lenne látni a kódot a küldő és a fogadó oldalhoz is (ha a kondenzátor nem oldja meg a dolgot). -
Nem tudom mire gondolsz, de annyira nem trükkös.
Van lehetőség ethernet-re is, de nem annyira bevett szokás vezetékes netet használni, viszont az említett esp wifi-képes, úgyhogy úgy látom az lesz a neked való lap.
ESP8266 vagy ESP32. A rajtuk lévő flash-t nagyon sokféleképpen lehet használni, akár egy szöveges fájlban is tárolhatod az adatokat, de van rá sqlite adatbázis (!) is. Úgy emlékszem eeprom emulációt is láttam, ami úgy ír a flash memóriába, mintha eeprom lenne, de azt most nem találom. -
-
-
-
válasz
zsolti_20
#13640
üzenetére
Nagyon szívesen.
Arra figyelj még oda, hogy ha UNO-val használod, annak 5V-osak a kimenetei, a scanner pedig ha jól értem 3.3V. Nézd meg, hogy van-e szintillesztés gyárilag a s-rx s-tx pineken, pl szimpla feszültségosztó is megteszi, és ha nincs, tegyél rájuk (elég a tx-et összekötni az arduino-val, mert küldeni úgysem fogsz neki adatot soros porton), különben kockáztatod, hogy esetleg megsütöd a szerkezetet, és kár lenne érte, elég drága cucc. -
válasz
zsolti_20
#13632
üzenetére
Én szeretem a rejtvényeket, ezért nem bánom, hogy nem olvastam el korábban az Ali oldalon a leírást, de magadnak spórolhattál volna egy kis időt, ha elolvasod.
"Support for setting module parameters by scanning the setup code (see the specification for details)
Settable parameters include (read mode, baud rate setting, command mode, prompt tone output adjustment, output format, barcode selective setting)"
Még a baud rate is le van írva.Olvasd át a manualokat:
[link]
Benne vannak a vezérlő kódok!Van benne Continuous mode és night vision is.
-
válasz
zsolti_20
#13632
üzenetére
Na akkor szuper.
Nézd meg, hogy mit csinál a gomb, általában földre szokott zárni egy i/o lábat, de lehet, hogy tápra, ezt mérd ki, és utána arduino-val te is meg tudod tenni, de ettől még nem fog neked folyamatosan szkennelni. Gondolom van egy timeout, ha egy bizonyos ideig nem lát kódot, abbahagyja a szkennelést. Tapasztald ki, mennyi ez az idő. Az is lehet, hogy serial-on vmi kóddal is lehet vezérelni (mivel ott az rx láb, csak van funkciója), de ehhez már kéne dokumentáció. Esetleg próbálj neki karaktereket küldeni, hátha beletrafálsz. A gomb folyamatos nyomvatartását is próbáld ki, hátha. -
válasz
zsolti_20
#13630
üzenetére
Feltételezem, hogy ch340 driver már telepítve van a gépeden, a kínai klón arduino-k általában ezzel vannak szerelve.
Mikor gépre dugod, felismerte? Megjelent egy új com port a gépen?
Az ide-ben ki kell választani a megfelelő COM portot, és utána fog csak működni a serial monitor. Feltételezve, hogy nem kell neki tx-en vmi inicializáló parancsot küldeni, hanem bedugás után küldi sorban az adatot.
Eredetileg mivel is kötötted össze a SDA, SCL lábakat, milyen lappal?Látom van a nyákon egy csipogó, mikor kódot mutatsz neki, visszajelez?
-
-
Hogy a viharba ne lenne megszakítással megoldva?
Hogy érted azt, hogy nem működik?
Ugye átírtad ezt a részt a saját bekötésednek megfelelően?const int PinSW=3; // Rotary Encoder Switch
const int PinDT=4; // DATA signal
const int PinCLK=2És nem értem, hogy miért, de nincsenek inicializálva a pinek bemenetként, ki kell egészíteni a programot:
pinMode(PinSW, INPUT_PULLUP);
pinMode(PinDT, INPUT_PULLUP);
pinMode(PinCLK, INPUT_PULLUP);A saját kód, amivel ki szeretnéd egészíteni a programot, miből áll? Tartalmaz delay-t vagy serial.print-et?
-
Dehogynem jó! Pont azt csinálja a program, amit kell neki.
Mivel az encoder gyorsabban foroghat, mint ahogy a lap ki tudja írni az adatokat serial porton, ezért nem lesz minden lépés kiíratva, csak az aktuális pozíció. Teszteld le: jelöld be az encodert egy pozícióban, és tekergesd oda-vissza párszor, majd nézd meg, hogy pontosan követi-e a kiírt adat a valóságot! Ugyanabban a pozícióban ugyanazt a számot kell neki kiírnia.
Ha mégse lett igazam, akkor alighanem pergésmentesíteni kell. -
válasz
Dißnäëß
#13586
üzenetére
"Érdemes még figyelni (...) az irq letiltására"
Akkor már leírom azt is, hogy miért: hosszabb megszakítások elején szokás letiltani az összes megszakítást (a végén pedig újra engedélyezni), hogy ne történhessen meg az, hogy a megszakítás közepén új megszakítás aktiválódjon. Ez jelen esetben pl egy pergés esetén fordulhat elő. Mivel a megszakításkor a processzor a programszámlálót és az állapotregisztert a verembe (stack) menti, szélsőséges esetben az is előfordulhat, hogy túlcsordul a verem, illetve felülírja a ram teljes tartalmát.
-
Ez a példa félig működik csak jól, mert ugyan minden változásra reagál, de a számlálást ugyanúgy a loopban végzi. A számlálást be kell tenni az isr-be, akkor jó lesz.
Próbáld ezt:volatile boolean TurnDetected;
volatile boolean up;
volatile long virtualPosition=0;
const int PinCLK=2; // Used for generating interrupts using CLK signal
const int PinDT=3; // Used for reading DT signal
const int PinSW=4; // Used for the push button switch
void isr () { // Interrupt service routine is executed when any CHANGE transition is detected on CLK
volatile boolean CLK = digitalRead(PinCLK);
volatile boolean DT = digitalRead(PinDT);
up=((!CLK && DT)||(CLK && !DT));
if (up)
virtualPosition++;
else
virtualPosition--;
TurnDetected = true;
}
void setup () {
pinMode(PinCLK,INPUT);
pinMode(PinDT,INPUT);
pinMode(PinSW,INPUT);
attachInterrupt (0,isr,CHANGE); // interrupt 0 is always connected to pin 2 on Arduino UNO
Serial.begin (9600);
Serial.println("Start");
}
void loop () {
if (!digitalRead(PinSW)) { // check if pushbutton is pressed
virtualPosition=0; // if YES, then reset counter to ZERO
Serial.print ("Reset = "); // Using the word RESET instead of COUNT here to find out a buggy encoder
Serial.println (virtualPosition);
}
if (TurnDetected) { // do this only if rotation was detected
TurnDetected = false; // do NOT repeat IF loop until new rotation detected
Serial.print ("Count = ");
Serial.println (virtualPosition);
}
} -
-
Encodert érdemesebb interrupttal kezelni, a pollozás soha nem lesz elég gyors ahhoz, hogy pontos legyen a számolás. Amíg a programnak semmi más dolga nem volt, mint az encodert figyelni, addig persze működött, de a mérés (főleg a rengeteg Serial.print miatt) már túl hosszú ideig tart, kimaradnak lépések.
Ha nincs kedved átírni a kódot, szedj ki minden kiíratást, talán elég lesz és működni fog. -
#13555
Aryes
nagyúr
tonermagus
#13554
válasz
tonermagus
#13554
üzenetére
Azt olvastad, amit én írtam?
-
#13549
Aryes
nagyúr
tonermagus
#13544
válasz
tonermagus
#13544
üzenetére
"Hogy tudom azt megcsinálni, hogy a 43.121212-ból 43121212 legyen? "
Rohadt egyszerű:43.121212*1000000= 43121212
-
#13530
Aryes
nagyúr
tonermagus
#13529
válasz
tonermagus
#13529
üzenetére
"házak között városban, az erkélyről próbálgatom. Elképzelhető hogy ezért a nagy pontatlanság?"
Biztos! Eleve nem lát rá minden műholdra, és házak közti visszaverődések emiatt könnyebben összezavarják a rendszert (ugyanazt a jelet többször is megkapja a vevő), sőt, van, hogy az eredeti jel nem is jut el a vevőig, csak a visszavert, így hibás lesz a számítás. Ilyenkor egy ház előtt guruló autó is hibát tud okozni.
-
válasz
Gergosz2
#13524
üzenetére
"Fix pontra minek GPS meg RF adó? Nem elég lenne elég csak a koordinátája? "
Korábban volt róla szó, hogy egy GPS vevő önmagában elég pontatlan, de két egyforma GPS vevő egymáshoz közel nagy valószínűséggel ugyanabba az irányba és ugyanannyit téved, ezért egymáshoz viszonyítva nagyon pontosan lehet velük távolságot mérni.
Illetve ha az egyik vevőnek ismert az abszolút pozíciója, akkor a mért és a valós helyzet közti különbséget levonva a 2. GPS vevő által mért pozícióból, szintén elég pontos helyadatot lehet nyerni. -
válasz
kesztió
#13515
üzenetére
Ha biztosra akarsz menni, beforrasztás után nyomj rá egy csík forróragasztót, akkor tuti, hogy nem a forrasztásnál fog eltörni, ha hajlítgatják.
Én egyenként szoktam, ha csak egyet csinálsz, ki lehet bírni...
Van olyan kábel, amit le sem kell csupaszítani, mert a páka hőjétől felszalad rajta a szigetelés, ha lusta vagy, ezt is meg lehet próbálni. -
-
válasz
FeniX-
#13507
üzenetére
Jobban teszed, ha a pin-t inkább sink módban használod, vagyis a szenzort a +5V és a pin közé kötöd, mert a pin úgy nagyobb áramot tud elviselni (az uno source-ként asszem 28mA, sink-ként 40mA), de az egésznek csak akkor van értelme, ha akkumulátoros üzemben használod, akkor lehet némi energiát spórolni így, külső táp mellett nem sok haszna van.
-
#13505
Aryes
nagyúr
tonermagus
#13504
válasz
tonermagus
#13504
üzenetére
Semmit nem tudok erről az eszközről, feltételezem, hogy a beállított baud érték helyes. Csak annyit tudok mondani, hogy cseréld meg az RX és a TX lábat, hátha felcserélted véletlenül.
-
-
válasz
FeniX-
#13493
üzenetére
Szia! A tranzisztor emitterét mindenképp össze kell kötni az arduino gnd-jével, különben nem jön létre az áramkör.
A ventilátort pwm-mel szeretnéd szabályozni? Először próbáld ki 100% kitöltéssel, és onnan csökkentsd a kitöltést, ne 0-ról felfelé, mert 30-40%-ig valószínűleg meg sem fog mozdulni. -
Remélem látszik a lényeg a képen.
Olyan optokapu kellene, ami nem infra fényt használ, hanem látható fényt, vagy egy egyszerű vörös lézerdióda + fototranzisztor, mert a fekete nyomtatófesték sajnos az infravörös fényt nem igazán nyeli el, nem lesz elég kontraszt a két jelszint megkülönböztetéséhez.
Rajzoltam egy lencsét a fény fókuszálásához, hogy a vékony vonalakat be lehessen olvasni, de ez egy lézerdiódánál talán el is hagyható. -
válasz
zsolti_20
#13490
üzenetére
Két teljesen különböző dolog, nem lézeres, és nem mér távolságot, bár közelség mérésére szokták használni (proximity sensor).
A lényeg, hogy a fekete és fehér felület más fényvisszaverő képességgel rendelkezik, egy fototranzisztorral pedig tudod mérni a fényerő változását, ahogy a csíkok sorban elvonulnak a szenzor előtt. Ehhez persze úgy kell nyomtatni, hogy ne keresztben, hanem hosszában jöjjön ki a vonalkód a nyomtatóból, tehát ha az optikát elhelyezed a nyomtató papírkiadó tálcája fölött, a csíkok maguktól átmenjenek alatta.
Megpróbálom lerajzolni neked. -
válasz
zsolti_20
#13485
üzenetére
Szia! Tudni kéne, hogy milyen bar code - magyarul vonalkód - lesz a matricán. Ha sima 1D (vmilyen EAN) kód lesz, akkor a legegyszerűbb egy reflektív optokapu lenne! A kód egy egyszerű bitsorozat, ha a nyomtató papírmozgató mechanizmusa egyenletes sebességgel tolja ki a papírt, akkor egyszerűen mérni kell a jelek hosszát, és visszafejteni belőle az adatot.
-
válasz
gyapo11
#13468
üzenetére
Az ilyen gyors reagálást igénylő feladatokhoz sokkal alkalmasabb a gumi kontaktusos nyomógomb (pl. távirányítók, gamepad-ek gombjai stb), az ugyanis nem pereg, így nem kell prellmentesíteni.
Cserébe nem zár nullára, de ez egy nyomógombnál többnyire nem is okoz problémát.A zongorabillentyűkről jut eszembe: akár optokaput is lehet ilyen célra használni (szerintem a szintetizátorok sebességérzékelős billentyűmechanikáját is valahogy így oldhatják meg).
-
válasz
atesss
#13467
üzenetére
"Viszont itt már figyelni kell rá, hogy mi van ha pl. két gombot egyszerre nyomtál le."
Erre egészen egyszerű a válasz: minden gombhoz külön-külön kell egy számláló, nem az interruptok közti időt kell számolni. Ezért is nem érdemes az interruptot letiltani.
"Azért ettől még nem raknám be a main-be."
Ezt írtad: "Lehetne az Interruptot ugyan letiltani ilyenkor, de helyette a MAIN ciklusban "órával" mérni, hogy mikor telt el már több mint 80ms."
-
válasz
atesss
#13465
üzenetére
Ez jó ötlet, de ha kiveszed a feldolgozást az interruptból és a main-be teszed, akkor nem is kell letiltani az interruptot, csak azt vizsgáld, hogy a gomb állapota mikor változott utoljára. Mented az utolsó változás idejét, és ha eltelt azóta pl. 50ms, akkor mehet a művelet.
Ennek a módszernek a hátulütője, hogy minimum 50ms-al lassítja a program reagálását. Ha fontos az azonnali reagálás, pl vmi időzítő kapcsolódik a gombnyomáshoz, akkor az első interruptra indulhat a művelet, és utána kell figyelni, hogy a mondjuk 80ms-belül érzékelt újbóli gombnyomást figyelmen kívül kell hagyni. Ennek pedig a zajérzékenység a hátulütője. -
válasz
gyapo11
#13462
üzenetére
De jelen esetben is egyszerűbb a szoftveres megoldás: interrupt esetén kell egy kb. 50-80ms sleep (ezalatt természetesen az interruptokat letiltani, hogy ne okozzon zavart a pergés miatt a többszörös interrupt), csak utána beolvasni a portok állapotát. A gomb elengedése esetén ugyanez, csak itt az eredményeket eldobjuk, ha nincs művelet gomb felengedésre.
-
válasz
atesss
#13461
üzenetére
"Na de ténylegesen ez a GPIO-olvasási művelet lassú (az adott programkód lefutása sok idő)? "
Nem tudom pontosan hogy működik, mert sosem merültem el ilyen szinten a raspberry lelkivilágában, de úgy olvastam, hogy a python nem közvetlenül éri el a gpio-t, mint a C programok, hanem fájlként kezeli (talán a /dev/pigpio-t (?) írja-olvassa), ezért elég lassú, ~1ms egy művelet. Ha hülyeséget írtam, akkor javítson valaki.
-
válasz
atesss
#13458
üzenetére
Azt hiszem végre sejtem, mi lehet a háttérben.
Van hardveres pergésmentesítés a nyomógombon? A kolléga már kérdezte, de nem adtál rá választ. Ha nincs, az egész teszt ebben a formában értelmetlen, mivel a lenyomástól számított 50-100ms-on belül a kapcsoló a pergés miatt random időközönként nyit-zár, mire megnyugszik. És mivel - ahogy Te magad is írtad - az INT láb az elengedésre is triggerel, ha interruptot állítasz be a gombnyomásra, a legelső kiolvasás után még számtalanszor tüzelhet az INT, mire beáll.
Ha igazam van, akkor ezt akkor fogod látni a szkópon, ha sleep nélkül folyamatosan olvasod az i2c port állapotát végtelen ciklusban (ezzel törölve az INT láb aktív állapotát). És az INT láb értékét ne olvasd közben, mert ahogy írtam, python-ból ez is lassú, talán még lassabb, mint az i2c. -
-
Nem kell külső felhúzó ellenállás, az MCP23017-ben például van belső felhúzó (asszem 100k).
atesss:
"Amikor változás van, rendben 1-be vált az INT pin. Utána kiolvasom az összes bemenetet, rendben látszik is hogy a PCF8574-nek melyik bemeneti pinje változott meg.
De az INT 0-ban marad ez után is, nagyon sokáig.
Direkt beraktam sleep-et, hogy teszteljem ezt, és még 0.1s után is maradt."Elolvastam vagy 5x, de nem értem.
Amikor változás van, miért vált 1-be az INT pin? A PCF8574 INT kimenete active low, vagyis az alaphelyzet az 1, és akkor vált 0-ra, ha van interrupt.
Szerintem fordítva ültél fel a lóra. -
-
válasz
Janos250
#13396
üzenetére
Nem gondoltam, hogy valaki használja a Windows beépített keresőjét bármire is.
Ajánlom a Total commandert ilyen célokra (is).
Nem Te linkeltél régebben egy oldalt, ahol arduino-hoz készült, újraírt/memóriatakarékos String class-ról írnak? Csak úgy eszembe jutott, hogy régebben szó volt róla, hogy nem ajánlott Arduino alatt a String osztályt használni. -
válasz
Dißnäëß
#13384
üzenetére
$7.90?
Na ebből se fogok nagyon bevásárolni. "Mert azt írtad, lassú az eeprom írás.
Nincs valami olyasmi, mint egy USB pendrive, hogy kiteszi milliszekundumok alatt - de legyen lassú, akár 1mp is - és kész ?"Dehát a lassú azt jelenti, hogy milliszekundumok alatt történik!
8-10ms, ami - tekintve, hogy μs tartományban gondolkodunk, amikor egy μcontroller sebességéről van szó - lassú. Nem? Legalább 10ms-ig fenn kell tartani a tápellátást, hogy sikeres legyen a művelet. Erre gondoltam. Ettől nemigen kapsz gyorsabbat, esetleg lehet próbálkozni SD kártyával, de szerintem emiatt nem éri meg."Nem vagyok nagy szaki, hogy külön wear levelinget írjak, törjem rajta az agyam"
Nem is kell, ott a lib, használd!
Egyébként sem kell újra kitalálni, leírtam a módját, viszonylag egyszerű elven működik. -
válasz
Dißnäëß
#13382
üzenetére
Ja, ez cuki. Hol kapni ilyet?
Miért kell alternatív hely? Egy ATmega32U4-ben 1kB eeprom van, ha jól tudom. Egy cella kb. 1000x írható. Ha az általam írt wear levelinget alkalmazod, vagy még egyszerűbb, ha 15 bit elég az időpont tárolására, a legfelső bittel meg lehet oldani a wear levelinget (van hozzá külön library is ám! ), akkor akár 512000 alkalommal írhatsz az eepromba, nem létezik, hogy ne legyen elég. -
válasz
Dißnäëß
#13380
üzenetére
Szia! Ha nem fontos a nagy pontosság (mondjuk naponta 5-10 perc eltérés nem okoz problémát) akkor nem kell az RTC, nyugodtan támaszkodhatsz a belső órajelre. Ha nem használsz megszakításokat, akár önmagában a millis() is használható időmérésre.
A táp megszűnését úgy értetted, hogy valamelyik pin-jén keresztül figyeli, és érzékeli, ha megszűnik a táp, de egy puffer kondiról még valameddig működik? Ez szerintem járható út, de számíts rá, hogy az EEPROM írás elég hosszú folyamat, és nem árt, ha közben kap végig stabil tápot, tehát egy konvertert én mindenképp tennék a trafó/diódahíd/pufferkondi után (meg egy plusz diódát a kondi és a diódahíd közé, hogy ne tudjon a hídon át visszafelé kisülni a kondi)!
Az EEPROM életét pedig, mivel kevés adatot kell rá gyakran írnod, szépen meg tudod növelni egyfajta szoftveres wear levelinggel: nem mindig ugyanazt a cellát írod felül, hanem minden írásnál a következő szabad cellát használod, egy számlálóval együtt, és ha elfogy az üres hely, akkor kezded újra elölről.
Minderre pedig kár egy Leonardo modult használni, egy Attiny85 is tökéletesen megfelelne a feladatra, van belőle olyan, amelyik 2,5V-tól 6V-ig működik (akár a konvertert is el lehet hagyni). -
válasz
zsolti_20
#13368
üzenetére
Ez jó ötlet
feltéve, hogy a dugó helyére tennéd a mikrokapcsolót. Kellően kicsi tank kellene, hogy kis vízmennyiségnél is kapcsoljon, és ne maradjon benne sok víz, mikor lekapcsol.
De 3D nyomtatással nemigen lehet víz- és légmentesen záródó dolgokat nyomtatni, lásd a forró vizes videót a 3D printer topikban. Úszónak megtenné viszont egy pingpong labda, vagy talán egy jól záródó, kis méretű gyógyszeres doboz is. -
válasz
JozsBiker
#13365
üzenetére
Itt arról beszélgetnek, hogy proximity szenzorral közvetlenül a víz jelenlétét lehetne érzékelni, de 0Ft-os barkács megoldásként lehetne akár alufóliából is kapacitív szenzort készíteni.
A nedvesség érzékelést be lehetne egyébként úgy is állítani, hogy ne a csőben érzékeljen, hanem a tartályban a cső felett, így nem fogja szárazra szívni a tartályt, viszont mindig maradna benne egy kevés víz. Az mondjuk legfeljebb a szúnyogok miatt okozhat gondot.
-
#13348
Aryes
nagyúr
Scooter86101
#13313
válasz
Scooter86101
#13313
üzenetére
Tudnátok ajánlani bevált 5V-os boost és buck konvertert meg 18650-es akksit Aliról a kollégának?
-
válasz
repvez
#13344
üzenetére
Hát ezt nemigen fogom megépíteni
Olyan kódra gondoltam, ami teszteli a sebességet."A hasonloságot ugy értem, hogy nem csak a forgatást hanem a teljes kialakitás ugyan az minden alkalommal, nincs benne változatosság, hogy hátha már kialakitással esetleg egyszerübb lehetne vagy pontosabb."
Én egészen biztosan nem így készíteném, ha ilyen kis távolságok pontos mérésére lenne szükség (pl bútorok közt navigáláshoz). A szenzort vagy a forgástengelyre tenném, vagy mögé, hogy nagyobb legyen a minimális távolság a mérendő tárgy és a szenzor közt. Amúgy ez a lézeres szenzor meglepően pontos, milliméteres pontossággal lehet vele mérni. Ahhoz viszont azt hiszem 100ms-nál nem lehet rövidebb a mérési idő.
-
válasz
repvez
#13341
üzenetére
Szia! Nekem van ilyenem itthon, ha küldesz rá teszt kódot (mondjuk UNO-ra), akkor letesztelem neked szívesen. Még nem építettem belőle semmit, csak tesztelgettem a pontosságát, úgy emlékszem, hogy néhányszor 10ms egy mérés, de nem fix az idő, a pontosság rovására lehet csökkenteni vagy növelni, erre van beállítás a hozzá tartozó library-ben.
"Illetve láttam, hogy páran próbáltak csinálni belöle LIDAR-t , de a legtöbben ugyan azt másolták le egy külső motorral hajtották meg a modul házát egyenlö sebességgel. "
Hát nagyon máshogy hogy lehetne?
"kötelezően csak egyenletes sebességgel kell hogy forogjon mérés közben vagy váltózó forgási sebességnél is ugyan ugy müködik a távolságmérés?"
A mérést, mivel ahogy írtad, fénysebességgel történik, nem befolyásolja, hogy milyen sebességgel forog a szenzor maga körül, inkább az adatok könnyebb feldolgozhatósága miatt számít a szögsebesség.
Adatküldéskor kell a kondi, programozáshoz le kell húzni. Próbáld ki, kárt nem okozol vele (kivéve, ha fordított polaritással kötöd be a kondit).
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
ekkold
- Apple iPhone 14 128GB, Kártyafüggetlen, 1 Év Garanciával
- Nitro AN515-56 15.6" FHD IPS i7-11370H RTX 3050 16GB 512GB NVMe magyar vbill gar
- HP Pavilion 15-ec2057ur 15.6" FHD IPS Ryzen 7 5800H RTX 3050 16GB 512GB magyarított vbill gar
- AKCIÓ!!! GAMER PC: Új i5-14400F +RTX 5070 +Új 16-32GB DDR4! GAR/SZÁMLA! 50 FÉLE HÁZ!
- Corsair RM750
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest