-
Fototrend
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
Breaker
#11118
üzenetére
Vettél egy 800mAh lítium akksit, amit egy belső step‐up converter 9V‐ra konvertál, így már csak 300mAh körül képes leadni, ha jóindulatú 90%‐os hatásfokkal számolok (ha 70%‐al számolok, akkor már csak 230mAh!). Ezt visszakonvertálod 5V‐ra (majdnem a felét elfűti), amit a D1 még lekonvertál az onboard konverterével 3,3V‐ra (még elfűt belőle egy kicsit). Jól értem?
-
Vettem nemrég egy wire wrap tool-t, nem is gondoltam, hogy én is ilyen menő kötéseket tudok majd vele csinálni.
-
Kedves esp32 szakértők! Egy játékot készítek most lolin32-vel (végre találtam neki egy jó kis feladatot
), néhány gpio-t bemenetként akarok használni rajta internal pullup-al, okozhat-e gondot, ha ezek a boot alatt közvetlenül GND-ra vannak kötve?
Ennek az oldalnak a leírása alapján olyan lábakat néztem ki, amik állapota nem zavarja a boot-ot, nincs se fel, se lehúzva és nem ad ki rajta PWM jelet se boot közben (16,17,18,19,23). A kérdés inkább arra irányul, hogy boot közben ezek a lábak hi-z állapotban vannak-e, vagy nem, utóbbi esetben tegyek-e áramkorlátozó ellenállást a GND és a bemenetek közé. -
válasz
gyapo11
#11080
üzenetére
Sajnos azt nem tudom, de vannak régebbi, laptop akksiból bontott celláim, amik a névleges kapacitás felét, 2/3-át tudják még, de normális minőségű (Xtar vc-4) li-ion töltőben töltve soha nem áll le a töltés, viszont elkezd melegedni a cella. Ezekből a cellákból használok 8db-ot egy power bank-ban (több mint 2 éve), de abban töltve sem áll le soha a töltés, az elektronika nem érzékeli, hogy 100%-on vannak a cellák, csak elkezd melegedni az egész, úgyhogy nekem kell lehúzni a töltőről, mielőtt kigyulladna.
Ebből én arra következtetek, hogy ezen a feszültségen létezés az akku természetes tulajdonsága, lehet hogy árt neki
Nem, a teljes töltöttségen tartózkodás hosszú távon károsítja, nem véletlen, hogy a li akksikat 40% körüli töltöttséggel tárolják és szállítják.
-
válasz
Attix70
#11075
üzenetére
Ha mindenki csak arra válaszolna, amihez ért, akkor most kit oktatnátok ki habzó szájjal?
Semmi megalapozatlant nem írtam, csak felhívtam a figyelmet valamire, ami a nagytudásúak figyelmét elkerülte, tudniillik ha teszem azt egy 500mA töltőáramú egységre köt 4cellát, és az a töltőáram 1/10-énél kapcsol le, az 12,5mA cellánként, egy gyengébb minőségű vagy elhasználódott cella ennyit feltöltve is képes folyamatosan felvenni, nem áll le a töltés, véletlenül éjszakára rajta hagyja, reggelig ki is gyulladhat. Melyikőtök vállalja érte a felelősséget?
"Ez persze hosszú távon valamelyest csökkenti az akku élettartamát"
Mert ez aztán egy szakmailag megalapozott, szakszerű tanács. Gratulálok. -
"Az okosabb töltők lekapcsolnak a
kezdeti töltőáram x (általában 10) %-ánál"Hát nem pont erről beszélek? Két cella -> fele töltőáram -> hosszabb töltési idő kisebb árammal, mert a töltőnek senki se szólt, hogy most a 20% a 10%.
"de ez nem jelenti azt, hogy ennél
kisebb árammal tovább töltve (továbbra is max. 4,2V-on) tönkremenne az akku."Pedig pont ez történik, a lítium alapú cellák nem bírják a csepptöltést (szemben a Ni-MH-del, aminek még jót is tesz). Kristályosodás indul meg bennük gázfejlődés kíséretében, és előbb-utóbb zárlatosak lesznek. Eleve az sem tesz már jót egy lítium alapú akksinak, ha túl sokáig van 90%-os töltöttség felett.
(És még én ragadtam le a Ni-Cd/Ni-MH akkuk töltési mechanizmusánál...)
-
válasz
Teasüti
#11069
üzenetére
Sejtettem.
De megnéztem mégegyszer a kódot, és megvan a hiba.
pinMode(button, INPUT_PULLUP);
}
void loop ( )
{
bool buttonState = digitalRead(button);
if (buttonState == HIGH)
{Stateállapota, mivel adigitalRead(button);mindig magas értéket ad, de a gomb azINPUT_PULLUPmiatt eleve magasan van.
if (buttonState == LOW)esetén a kód működni fog, persze ha a gomb jól van bekötve. -
válasz
vargalex
#11059
üzenetére
A másik pedig, hogy a töltő az áramfelvétel csökkenése alapján figyeli a töltöttséget, és több akkunál, még ha történetesen egyformán is veszik fel a töltést, annyifelé oszlik ez az áram, ahány akksi össze van kötve. Így könnyen túl lehet tölteni a cellákat, mert nem áll le a töltés időben.
-
#11058
Aryes
nagyúr
---gabika---
#11057
válasz
---gabika---
#11057
üzenetére
Első körben cseréld ezt a sort:
if (buttonState == HIGH)
erre:
if (buttonState == true)
mert a bool változónak nincs olyan állapota, hogyHIGH, de ha mégis lenne, akkor viszont a pergésmentesítés hiánya lehet még a probléma. -
-
válasz
zsolti_20
#11002
üzenetére
Én ezt a Tescoban vettem, úgy 4 évvel ezelőtt...
De például ez itt tudja. De vigyázz, mert ez csak egy ház, az akksit neked kell bele előteremteni!
"charging and discharging at the same time" <- ezt keresd a leírásban.
Ez a linkelt olyan jól néz ki, lehet én is veszek egyet. :) Van már egy hasonló, 8db cella fér bele, de az például nem tud egyszerre tölteni és töltődni. Bontott laptop akksi cellákat tettem bele. -
válasz
lac14548
#10984
üzenetére
Puff neki...
Elvileg az adat vonalnak nem kellett volna károsodni, ha tudsz szerezni külső tápos usb hub-ot, esetleg tegyél egy próbát vele, hátha csak a táp része égett meg. Laptop vagy asztali gép? Szerencse, hogy az alaplapot nem vitte magával.
Hogy lehet, hogy polyfuse nélkül is kiadnak arduino-t? Úgy emlékszem, ami nekem van nano, azon is van. De lehet rosszul emlékszem. Annak idején kezdő koromban ezek szerint sokszor megmentette a gépet az uno-n lévő polyfuse, amikor rajta felejtettem egy motort. Akkor csak bosszankodtam rajta, hogy lekapcsolta magát a lap, pedig rosszabb is lehetett volna ezek szerint... -
válasz
lac14548
#10982
üzenetére
"A windows-os Arduino nem látja."
A gép usb portját már tesztelted?
A linkelt képen nem látszik a polyfuse, ami a portot védi a túlterhelés ellen, ha a másik oldalán sincs, akkor könnyen lehet, hogy nem a nano, hanem az usb port f.ngott ki... A szervo akár túl is terhelhette. -
válasz
ecaddsell
#10937
üzenetére
Én smd-re nem használnám, de pl. chip lábakat beforrasztani kevesebb tököléssel járna, talán szebb lenne az eredmény még egy egyszerű pillanatpákával is. Most külön bekenem a nyákot tisztítás után a zsírral, ha ügyes vagyok, mindenhová egyformán jut, de általában nem. Utána takarítani kéne, de nem igazán megy.
-
Ez a második (Y) paraméter beérkezése után hajtja végre a kódot:
megVarokParametert=false;
token="";
for (byte i = 0; i <= messageSize; i++) {
if (isAlpha(Message[i]) || isPunct(Message[i])) {
switch (Message[i]) {
case 'R':
token='R';
parameter = atoi(& Message[i + 1]); break;
case 'G':
megVarokParametert=true;
token='G';
parameter = atoi(& Message[i + 1]); break;
case 'X':
parameterX = atoi(& Message[i + 1]); break;
case 'Y':
megVarokParametert=false;
parameterY = atoi(& Message[i + 1]); break;
}
}
if (megVarokParametert==false){
hajtsdVegreAKodot(token);
} -
válasz
Teasüti
#10903
üzenetére
Én állapotgéppel csinálnám, akkor semmit nem kell bonyolítani a beolvasáson, csak olvasod szépen sorba a tokeneket. Ha Gxx érkezik, az állapotgép átbillen paraméter állásba, így a következő beolvasások mind az előző parancs paraméterei közé kerülnek, és ha újra Gxx érkezik, akkor az állapotgép visszabillen parancs állásba, ekkor hajtod csak végre az előző parancsot az összes paraméterével együtt.
-
válasz
Teasüti
#10901
üzenetére
Ha jól értem, te nem akarsz kompatibilis lenni semmivel, hanem építesz egy saját protokollt egy meglévő alapján. Vagyis amíg kerested rá a megoldást a kódban, akár meg is írhattad volna.
A leírás alapján nagyon egyszerűnek tűnik a megoldás, csinálni kell egy tömböt, amiben leírod, hogy a G01 után lesz még két paraméter, és akár betűtől függetlenül a következő kettőt beolvassa, legyen X0 Y0 vagy akár újra G0 G0 (vagy használd csak erre az X Y betűket és akkor még hibaellenőrzésre is használhatod). -
válasz
zsolti_20
#10843
üzenetére
Ha a Q1 egy LDO, akkor meg kell nézni az adatlapját, mekkora a minimum tápfesz, és mekkora árammal terhelhető. A 3db AA akksira kell kötni a nano lap 5V-ját, az Oled kijelző Vcc-jét, és ha a konverter engedi, a rádiót a konverter kimenetére kötném, hogy megkapja a stabil 3,3V tápot, mert a kisebb táp miatt a nano 3,3V kimenete nem lesz alkalmas tápnak. Illetve ha a rádió 5V-ról is üzemeltethető, akkor azt is a 3db AA akksira.
Ha a Q1 mégsem konverter, és se az oled, se a rádió nem tud 5V-ról üzemelni, abban az esetben kelleni fog egy plusz 3,3V konverter is. -
válasz
zsolti_20
#10803
üzenetére
Akkor a szűk keresztmetszet itt a lapon lévő 3,3V konverter lesz, gondolom az oled és az rf modul is arról van táplálva. Annak kell utánanézni, illetve tesztelni, hogy mekkora az a táp, amiről még megbízhatóan elő tudja állítani a 3,3V-ot.
Ha ennek is kell +0.6-1.2V a voltage drop miatt, akkor az elemes táplálást máshogy kell megoldani. Akkor én úgy csinálnám, hogy egy 3,3V buck konverter-re kötném az egész cuccot, aztán arra már olyan tápot kötsz, amilyet jól esik (mármint 3,3V feletti tápot). Vagy maradna a 3db AA elem, és az oled+rf modulnak beteszel egy buck konvertert, ami mondjuk 3,5V-ig el tudja látni őket.
Boost konverterrel két ceruzaelem (3V) is elég, ha a méret számít. Egy boost-buck konverterrel meg egészen szárazra lehet szívni az elemeket vagy mehet egy 18650 celláról, vagy akár 1db 1S li-polimer akksiról (méretben, súlyban ez a legjobb).
Végülis a 9V elem is opció lehet (Vin lábra!), próbáld ki, hogy meddig bírja, és ha túl kevés, akkor a fentiek közül válassz egyet. -
válasz
zsolti_20
#10797
üzenetére
Hát egy 9V elem jó ha 800mAh-t le tud adni, ráadásul abból egy csomót maga a konverter fog elpazarolni.
Egy pár, illetve inkább 3db AA elem vagy ceruza akksi több mint 3x ennyit bír. Az a kérdés, hogy a rádiónak mennyi az áramfelvétele és hajlandó-e működni 5V alatt, mert 3db új AA elem konverter nélkül 4,8V-3,3Vig fogja ellátni a cuccot, 3db AA ceruza akkumulátor mondjuk 4,2-2,4V közt. Maga a kontroller 3V alatt is működik (kisebb órajelen 1,8V-ig is, mint azt tegnap megtudtam )t72killer: ki mondta, hogy baj van vele?
-
válasz
szuszinho
#10773
üzenetére
Olyan nincs is... 8 meg 16MHz-est látok.
Régebben teszteltem úgy az uno-t (ATmega328), hogy az 5V lábra ceruzaelemeket kötöttem konverter nélkül, és egészen 3V-ig stabilan működött. Szóval ha oda kötöd, működni fog, de ha érzékelők is vannak rá kötve, akkor azok már nem biztos, hogy ezt tolerálják. 4V alatt a 3,3V kimeneten se lesz 3,3V. -
válasz
t72killer
#10765
üzenetére
Ez esetben még mindig ott van az a lehetőség, hogy olyan routert veszel, ami tud egyszerre két wan kapcsolatot kezelni, az egyik a mobilnet, vagy free wifi, a másik pedig a kamera lenne, így mégis csak a routeren keresztül tudnád elérni, pl vpn-en keresztül. Ekkor megint nem kellene a raspberry, mert közvetlenül otthonról tudnál rá kapcsolódni, a többit pedig az attiny elintézi (ki-be kapcsolgatás, exponálás). De akkor még mindig ott van az a probléma, hogy free wifi-re kapcsolódva nem fogod tudni elérni kívülről az egész cumót publikus ip cím nélkül, sőt szerintem LTE modem mögül se biztos, ha NAT-olt.
-
válasz
t72killer
#10756
üzenetére
Az a baj, hogy egyszerre akarsz mindent is.
Amit most leírtál, azt valószínű legjobban tényleg raspberry-vel lehetne megoldani, de nem azért írom itt a raspberry-t, a raspberry topikban meg az arduino-t, hogy szivassalak.
Az attiny felesleges redundancia lenne a projektben, mert az esp simán tudná vezérelni a gombokat és wifi-n keresztül http parancsokat adni. Ahogy én csinálnám: egy routert beállítanék repeater módba, ami a környéken fogható free wifi-re csatlakozna, erre kapcsolódna a kamera és az esp is, így nem kéne két hálózatot kezelni. Az esp szerintem képes arra, hogy 4Mbyte-os jpeg-eket leszedjen a kameráról és továbbítson, ha tényleg http parancsokkal ezt meg lehet oldani (az esp szakértők majd kijavítanak, ha tévedek), ez esetben viszont nem világos, hogy ha már a kamera a netre van kötve, miért nem próbálod otthonról a neten keresztül letölteni a kameráról a képeket és az esetleges videó streamet?
A kamera vezérlésről http protokollon keresztül tudsz leírást adni? -
válasz
Gergosz2
#10749
üzenetére
Én meg pont úgy tudom, hogy az atmega328 lábai gyárilag boot alatt input (nagyellenállású) módban vannak (ezt éppen hívhatjuk lebegésnek is). Az persze lehet, hogy a bootloader állítgatja közben őket, de a legjobb lenne a kérdéses lábakat külső ellenállásokkal földre húzni. Én először biztos ezt csinálnám, mielőtt nekiesek kiirtani a bootloadert. Plusz tennék egy nagy puffer kondit a nano tápjára.
-
-
-
válasz
Teasüti
#10677
üzenetére
Azért off, mert már túl sok vagyok ebben a topikban, nem akarom ingerelni a többieket.
Hát a koncepció az, hogy egyforma teljesítménnyel adom le a jelet, de elhangolom a vivő frekvenciát 38kHz-ről, hogy a vevő nehezebben érzékelje.![;]](//cdn.rios.hu/dl/s/v1.gif)
Azt hittem, hogy ez egyszerű dolog: addig növelem a frekvenciát, amíg már nem tudja fogni a vevő a jelet, de tévedtem: gyakorlatilag minden frekvencián képes fogni a jelet, 2kHz-től 100kHz-ig. 
Viszont vannak frekvenciák, amikre kevésbé érzékeny, ezeket vagyok kénytelen használni.(#10678) tvamos: nem igaz, hogy nem számít, biztosan jobb lenne az egész, ha cm pontossággal tudnék mérni, de egyrészt nem akartam lehetetlen célt kitűzni, másrészt pedig az említett Lego robot is így lett kitalálva, és így is jól használható. Már akkor boldog lennék, ha azt a pontosságot sikerülne elérnem.
-
válasz
Teasüti
#10672
üzenetére
Abszolút hatótávolságot.
Most annyit tudok mérni, hogy az adó 0-50cm-en belül van, 50-100cm közt, vagy 100cm-en túl. Én pont ennyit akartam eredetileg. És amiért ez szerintem érdekes, az az a tény, hogy az ir vevőn és két ir leden kívül csak egy előtét ellenállást használok, minden más szoftveresen van megoldva. -
válasz
Teasüti
#10668
üzenetére
"Én ezt megoldanám frekvencia modulációval"
Mit? Vagy 6 különböző funkciót írtam le az előbb csak 1 tankhoz. És még vannak ötleteim. Például a beacon jel jelenthetné, hogy sikeres volt a találat, vagy akár a tank egészségi állapotát. És valahogy össze is kell hangolni a kommunikációt, ha nem akarom, hogy az összes tank egyszerre beszéljen."különböző jelerősségekhez is lehetne saját frekvenciát rendelni. Mondjuk az első tank 30-33 Khz között sugároz, a második 34-37 közt "
És honnan vegyek ennyi különböző ir vevőt? Arról nem is beszélve, hogy a 38kHz-es tsop vevő 25 és 45kHz között simán vesz minden frekvencián. -
válasz
Teasüti
#10666
üzenetére
Pedig eddig azt hittem, figyeltél.
A beacon jelben benne kell lenni a tank azonosítójának, vagyis, hogy ki sugározza éppen a jelet. Ebből tudja a másik, hogy kit lát (terv szerint kettőnél több tank is részt vehetne egy harcban, bár elsőre örülök, ha kettőt meg tudok építeni...
), illetve, hogy nem a saját maga által küldött jelet látja mondjuk egy falról visszatükröződve.
A másik, hogy mivel analóg jelet nem tudok kivenni az ir vevőből, kell egy trükk, hogy távolságot tudjak mérni.
Több különböző "fényerővel" fogom kiküldeni a beacon jelet. Mondjuk 5mA lesz az 1-es fényerő, 10mA a 2-es, stb. A különböző fényerők más-más távolságról fognak látszódni. De honnan tudom, hogy ha látok egy beacon jelet, az egy közeli tank gyenge jele, vagy egy távoli tank erős jele? Hát onnan, hogy maga a jel tartalmazni fogja, hogy ki küldte és milyen erősséggel.
Tehát mondjuk így fog kinézni az 1-es tank 5-ös erősségű beacon jele: 0x15. A lövés meg legyen mondjuk 0x1F. Akár még azt is bele lehet írni, hogy a tank eleje vagy a hátsó része sugároz, így az egyik tank egy jelből meg tudná állapítani, hogy a másik tank menekül előle, vagy éppen célba vette.
-
válasz
Teasüti
#10664
üzenetére
A GCR kódolás. Az volt a baj, hogy ha túl sok 0 vagy 1 jött egymás után a soros adatfolyamban, megzavarta a vevőt, elmászott a gain (begerjedt?
), az adatlapon lehet olvasni, hogy bizonyos jelhosszúság (0) után kötelező szünetet (1) beiktatni.
Először az 5 bites, Commodore-féle változatot próbáltam, de az csak az egymást követő 0 bitek számát maximálta 2-ben, az 1 biteket nem, így akár 8db 1-es bit is jöhetett egymás után, és nem akart úgy működni, ahogy vártam. Ezért kitaláltam egy 6 bites kódolást, ahol se kettőnél több 0, se kettőnél több 1 nem jöhet egymás után, és ezt már szereti a vevő. Plusz két ellenőrző bitet használok az átviteli hibák detektálásához. Így a normál soros kommunikáció 11 bitje (1 start + 8 adat + 1 paritás + 1 stop) helyett ugyan 16 bitet küldök (1 start + 2x6 adat + 2 ellenőrző + 1 stop) egy byte átviteléhez, de azt akár 4000baud sebességgel (~230byte/s), és majdnem minden átviteli hibát ki tudok szűrni. 
A hibás adatot felismeri a rendszer és eldobja.
Így most nem az történik, hogy bizonyos távolságból elkezd a hasznos adat közé mindenféle szemét keveredni, hanem van egy
határozott távolság, ahol egyszerűen megszűnik a kommunikáció. És ez volt a cél. -
Az a poén, hogy miközben próbáltam tervez(tet)ni egy workaround megoldást az ir receiver "hisztis" viselkedése miatt, sikerült olyan jól módosítani a softwareserial lib-et, hogy most már együtt tud működni a tsop vevővel és elkezdett úgy működni, ahogy eredetileg vártam.
Úgyhogy ezen a vonalon megyek tovább, és egyelőre ejtem a high pass filteres mókát. Köszönöm a türelmet és a segítséget mindenkinek!
-
válasz
Gergosz2
#10655
üzenetére
A NEC protokollal két gond van. Az egyik, hogy l-a-s-s-ú.
Kb. 50 baudos adatátviteli sebességet lehet vele elérni, az kb 6byte egy másodperc alatt, iszonyú kevés... 
A másik, hogy a hozzá kapcsolódó library csak egy darab ir vevőt képes kezelni, míg a softwareserial lib többet is, egyidejűleg!Ellenben a softwareserial libet mostanra annyira átírtam, hogy 4000baudos sebességgel tudok küldeni vele adatot GCR kódolással és magas hibatűréssel.
-
válasz
tvamos
#10657
üzenetére
"Raadasul demodulalnod kene elotte a jelet"
Azt hiszem most kezdem érteni, hogy miért kérdezed azt, hogy hogy akarom demodulálni. Ugyanis összekevertem a felül áteresztő szűrőt az alul áteresztővel.
Eddig azt gondoltam, hogy a high pass szűrő után kapok egy, a jel amplitúdójával arányos feszültségszintet, de valójában csak a négyszögjelet kapom vissza, amit eredetileg küldtem.
És ha ezt a négyszögjelet integrálom egy kondenzátor+diódával? -
válasz
Teasüti
#10651
üzenetére
Te tényleg értesz.
"Az adó-vevő hókuszpókusz"
Ez sajnos kudarcba fulladt, mert nem bírok belőle analóg jelet kifacsarni. De maga a soros kommunikáció már egészen jól működik. Viszont távolságtól függetlenül néha egészen közelről is hibák jelentkeznek, amit képtelen vagyok visszafejteni, ehhez már vagy egy oszcilloszkóp kéne, amit linkeltél, vagy egy digitális jelanalizátor, amit Janos250 kolléga ajanlott régebben, de egyik sincs itthon sajnos. Gyanítom már nem a kommunikációban van a hiba, inkább valami esp specifikus dolog lehet, ami néha megzavarja a pontosan időzített küldést."38 Khz-es négyszögjel esetén - vagy ami átjön a bandpass filteren - húzza GND-re."
Analóg jel esetén ez úgy működne, hogy a jel mindig valahol 3.3V és 0V közt lenne, az adó távolságától és az adás teljesítményétől függően. A kettő közt félúton van egy választóvonal, ami alatt 0-nak, fölötte pedig 1-nek veszi a feszültségszintet, tehát bizonyos távolságból az adás egyszerűen csak el fog tűnni. Persze tudom, hogy van egy sáv, ahol határozatlan lesz a, mondjuk 1.8-2.5V közt, itt valószínűleg véletlenszerű adatokat fogok kapni. -
Nem rossz ötlet, de pont a lövéssel nincs gondom, ott nem kell távolságot mérni.
Beacon jelnek tényleg lehetne használni, de az a baj az ultrahanggal, hogy egyrészt nagyon irányított, tehát 360°-ra kellene vagy 8db adóvevő, másrészt 80cm-en túl gyakorlatilag használhatatlan. Ezen kívül nagyon érzékeny a visszaverődésekre (hiszen ez a dolga), és ha két robot széklábak és játéktároló dobozok közt bújkálva keresi egymást, annyi visszhang lenne, hogy nem lehetne használni.
De tartaléktervnek azért elteszem. -
válasz
Janos250
#10639
üzenetére
Egy nagyon vázlatos rajz:
Az IR led bizonyos időközönként kiküld egy 1-2 byte-os beacon üzenetet, amit vagy látnak a körülötte lévő robotok, vagy nem, az üzenet tartalma pedig a robot azonosító száma, és egyéb rendszerüzenetek, pl. lövés (ez utóbbi üzenet csak egy dedikált, irányított LED-ből fog érkezni, vagyis csak az fogja látni, akit "eltalál" vele).
Ezt az üzenetet több különböző teljesítményen (pl 5mA - 100mA) szándékozok küldeni egymás után, ami reményeim szerint csak bizonyos távolságokból látható (pl az 1-es erősségű jel csak 20cm-ről, az 5-ös erősségű meg mondjuk 3 méterről), ebből a vevő robot egy hozzávetőleges távolsági becslést fog tudni számolni az alapján, hogy melyik infra vevő melyik jelet fogta. Az üzenetben természetesen benne lesz, hogy milyen erősséggel lett kiküldve. Példa: "15" <- az 1-es számú robot 5-ös erősségű beacon jele.
Nem kell se a távolságot, se az irányt pontosan tudni, elég, ha annyit tud az egyik robot, hogy a másik előtte van, vagy tőle jobbra, közel, közepesen távol, vagy valahol messze.
Mondjuk egy ilyen koordináta rendszerben:
A piros a közel, a zöld a távol, a többi meg látszik a rajzon.Amit most leírtam, pontosan ezt tudja a Lego Spybotics robot, 76kHz-es IR vevőkkel és ledekkel. Azt szeretném lemásolni.
-
válasz
tvamos
#10635
üzenetére
Meg mernék esküdni, hogy az utóbbi két napban legalább háromszor leírtam már (én ugyan high pass filtert írtam), de legyen:
Szükségem lenne egy bandpass filterre, ami egy ir tranzisztor jelét szűri olyan módon, hogy megfelelő amplitúdójú 38kHz-es négyszögjelre alacsony jelszintet hozzon létre egy esp8266 bemenetén.
Hiába van ez a tervező, ezzel a rajzzal nem tudok mit kezdeni:
Nem a számolás részével van problémám, nincs kész kapcsolási rajzom!
Hova kössem az ir tranzisztort? Hogy fog ez nekem alacsony jelet produkálni az arduino bemenetén? -
válasz
brickm
#10632
üzenetére
Most az egész projektet nem érted, vagy azt sem, hogy kellene egy 32kHz vágási frekvenciával rendelkező high pass filtert tervezni ir tranzisztorhoz, ami egy esp8266 bemenetét vezérelné? Bemegy egy 38kHz négyszögjel, ennek az amplitúdóját szeretném megkapni analóg módon az esp bemenetére.
-
válasz
Janos250
#10630
üzenetére
"Tehát van egy mozgó kocsi, aminek infókat akarsz küldeni IR-en. Ez alapján akkor a vevőnek a kocsin kell lenni."
Igen, és az adónak is! Így beszélgetnének egymással. Minden kocsin 1 vagy 2 LED az adó, és 3-4 vevő. A ledek fényét pedig valamilyen kerek, fényvisszaverő felülettel szórnám, hogy 360°-ban le tudjam fedni a környezetét.
"Ahhoz, hogy elfogadható pontosságot kapj, muszáj lesz (szerintem) a vevőt egy pincurka servo- vagy léptetőmotorral az adó, azaz a maximális jel erősség irányába állítani"
Ez biztosan nem így lesz, vagy 3db vevő lesz körben az autón, egymással kb 120°-os szögben, vagy ha ennek túl nagy lenne a holt tere, ami elég valószínű, akkor 4 vevő, 90° szögben. A háromszögelés pedig 1 adó + két vevő között történne.
"b.) Egyszerre akarod a kódot is és a távolságot is megkapni. Akkor jön a vér izzadása, hogy mindenféle szűrésekkel megold."
Ezt akarom. A vért pedig már izzadom vagy 3 hete. -
-
válasz
Janos250
#10622
üzenetére
" a jel erőssége nem csak a távolságtól függ, hanem pl. attól is, milyen szöget zár be a vevő és az adó."
Ez tény, sajnos nem tudok vele mit kezdeni. Max annyit, hogy a LED fényét nem direkt módon irányítom kifelé, hanem szétszórom, tükör vagy fényvisszaverő felület segítségével."Az IR-rel a távolságmérést nem a jel erőssége, hanem a visszavert jel visszaérkezési idejéből számítják."
Na ezt majdnem biztosan állítom, hogy ebben a formában nem igaz, a sharp távolság szenzornál a beesési szögből számolják, CCD érzékelő segítségével. Sima ir tranzisztorral pedig a fény intenzitásából, itt van olyan variáció, ahol egy 555-ös IC-vel szaggatják a fényt, a vevő oldalon pedig felüláteresztő szűrővel szűrik ki a jelet a környezeti fényből, ezt akarom én is, csak szoftveresen.
Aminek a visszaérkezési idejéből számítják a távolságot, amit írtál, szerintem az a lézeres mérő, de annak már igazán nem hobbista az árszabása... -
válasz
tvamos
#10623
üzenetére
"Szerintem nem uszod meg a haromszog beiktatasat"
Persze, hogy nem, azzal szeretném az adó irányát megbecsülni, de ahhoz kell, hogy sikerüljön valami távolság adatot is végre kinyerni."En azt javasolnam, hogy eloszor dugd ossze az aramkorod, ... szaladj korbe a lakasban, kulonbozo napszakokban, "
Pontosan ezt fogom tenni. Amit nem tudok kiszámolni, azt mindig empirikusan szoktam megoldani: addig próbálgatom, amíg nem sikerül. Csak ez sajnos időigényes, és ennyi időm nincs.
Oscilloscope-om sincs sajnos. Tervezem, hogy veszek, aztán mindig másra kell a pénz. Kicsit körülményes, de megoldom valahogy anélkül. Elvégre az uart kapcsolat már összejött, pedig azt sem volt egyszerű összehozni. -
válasz
tvamos
#10620
üzenetére
Köszönöm az észrevételeket, ezekkel már tudok mit kezdeni.
"Tehat, ha a nap besut az ablakon, es a robotod azzal szembe megy, akkor nem lesz jeled."
Igen, ez egy kompromisszum, a smart car-ommal szerzett tapasztalatok alapján direkt napfényben nem hatékony a szimpla ir tranzisztor, nem akarom a fizika törvényeit megszegni, ha kell, lehúzom a redőnyt.
De ha a tsop képes direkt napfényben is működni, akkor valamilyen megoldásnak létezni kell."hogyan tudnad a tavolsagot merni, ha nem mashogy, mint egy masik tavmero szenzorral, vagy haromszogelessel."
Két ir szenzor + háromszögelés
"A terhelesed nincs impedancia illesztve. Ha a kimeneted feszultseg, akkor az R2 legalabb 100k kene legyen"
Ha jól értem az esp bemeneti impedancia számít, ami ez esetben ha jól tudom MΩ nagyságrendű. Az R2 azért ennyi, mert erre találtam példát az egyik fórumon.
"Ha mondjuk 200mVpp az AC, es 3.3V a a tap, akkor 3.2V es 3.4V kozott lesz a kimeno feszultseg. Ez kell neked?"
Igazából 0V és 3.3V közti értékeket szeretnék kapni. Hogy ezt milyen áramkörrel lehet elérni - na azt szeretném most megtudni... Gondolom kellene bele egy(-két?) dióda, ami nem engedi a jelet a tápfeszültség fölé menni.
-
válasz
Janos250
#10616
üzenetére
Én nem analóg jelet akarok átküldeni, hanem digitális információt. Emellett a küldő oldal jelerőssége alapján szeretnék hozzávetőleges távolságmérést csinálni. Tudom, hogy nem ördögtől való az ötlet, mert árulnak arduino-hoz való ir távolságszenzort, ami egy egyszerű reflektív optokapuból + némi elektronikából áll, ahol az ir led fényét frekvenciamodulálják, hogy ne zavarja a környezeti fény.
Elvileg az adat vonalnak nem kellett volna károsodni, ha tudsz szerezni külső tápos usb hub-ot, esetleg tegyél egy próbát vele, hátha csak a táp része égett meg. Laptop vagy asztali gép? Szerencse, hogy az alaplapot nem vitte magával. 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Azt hittem, hogy ez egyszerű dolog: addig növelem a frekvenciát, amíg már nem tudja fogni a vevő a jelet, de tévedtem: gyakorlatilag minden frekvencián képes fogni a jelet, 2kHz-től 100kHz-ig. 
Viszont vannak frekvenciák, amikre kevésbé érzékeny, ezeket vagyok kénytelen használni.
A hibás adatot felismeri a rendszer és eldobja.
Új hozzászólás Aktív témák
ekkold- „Új mérce az Android világában” – Kezünkben a Vivo X300 és X300 Pro
- Motoros topic
- Garmin Instinct – küldetés teljesítve
- Futás, futópályák
- Béta iOS-t használók topikja
- Gumi és felni topik
- Autós topik
- EAFC 26
- SzDavid99: Van 20 perced? Akkor tanulj meg koreait olvasni!
- Házimozi haladó szinten
- További aktív témák...
- Béreljen minikotró gépet már 24 órától, akár hosszabb időre is
- Bomba Ár! Lenovo ThinkPad E15 Gen2 AMD - Ryzen 5 I 8GB I 256SSD I 15,6" FHD I HDMI I W11 I Gari
- Bomba ár! Lenovo ThinkPad T14s G2 AL - i7-1185G7 I 16GB I 1TSSD I 14" FHD Touch I W11 I Cam I Gari!
- Bomba ár! HP ProBook 645 G4 - Ryzen 7 PRO I 8GB I 256SSD I HDMI I 14" FHD I Cam I W11 I Garancia!
- Bomba ár! HP ProBook 645 G3 - AMD A10-8730B I 8GB I 256SSD I 14" HD I Cam I W11 I Garancia!
- LG 39GS95UE - 39" Ívelt OLED / QHD 2K / 240Hz & 0.03ms / 1300 Nits / NVIDIA G-Sync / AMD FreeSync
- Azonnali készpénzes félkonfig / félgép felvásárlás személyesen / csomagküldéssel korrekt áron
- Vállalom telefonok,tabletek javítását ,(szoftveres hibát is,frp lock-ot is)márkától fügetlenűl
- Akciós Windows 10 pro + Office 2019 professional plus csomag AZONNALI SZÁLLÍTÁS
- ÚJ BONTATLAN Apple Macbook Air 15,3 M4 10C CPU/10C GPU/16GB/256GB - Égkék - HUN - mc7a4mg/a 3 év gar
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Laptopműhely Bt.
Város: Budapest