Rušení

[jrt]

Co myslíte tím svodem?Jesti neprobíhá reset samovolně? Mohlo by to dle Vašeho názoru být i špatným kontaktem mikrokontroléru a paticí ikdyž bez motorů to funguje?

Změřte napětí na vstupu reset při běhu motorů a hned uvidíte, zda nedochází k nějakým problémům. Svod = když je mezi kontakty spínače nějaký měřitelný odpor i v rozepnutém stavu. U miniaturních tlačítek se to občas stává, pokud je přehřejete při pájení.
Špatný kontakt v patici dokáže pěkně pozlobit, takže vždycky měřte až na vývodu součástky, ne na pinu patice.

Ale nezoufejte, takovéhle problémy se stávají i v "lepších rodinách", zvlášť pokud člověk spěchá a říká si, že tenhle obvod prostě chodit musí na první zapojení. Příště alespoň budete vědět, kam sáhnout.

[petr-kubac]

Jelikož robot začne bláznít když se spustí motory mám ještě jednu ideu
Máte odrušené motory ?

Kupte 3 ks 10 - 22nF keramické kondů na každý motor a zapojte vždycky jeden mezi přívodní dráty a dva další od každé svorky na plechový obal motoru tím se vysokofrekvenční vyzařování z kartáčů motoru udrží uvnitř.

[ezowiki]

Jeste mne napada, nikde jsem nevidel, jak je provedena baterie.

1/ Pokud jsou to 8xAA tuzky v pozdre, tak muze byt problem v kontaktech. Preci jenom si ty motory neco vezmou, obzvlaste pri rozbehu, takze prechodove odpory, pokud je neco zoxidovane, pripadne maly pritlak na baterie muze zpusobovat neprijemnosti. Zkuste je ocistit, pripadne zkuste jine pouzdro na baterie.

2/ Nektery ze clanku je vadny, to muze byt moznost pokud jsou AA i pokud je to akupack.

Zkuste to povesit na chvili na poradny zdroj nejlepe laboratorni, zda problem trva.

[haas]

.

[haas]

Bože za co mě trestáš?

Tak jsem přepájel všechny patice a také prohřál již zapájené místa, jestli tam není studený spoj a zapl jsem to a jsem tam kde jsem byl.POKUD MOTORY STOJÍ VŠE JEDE, ALE JAK SE ZAPNOU KONEC.Nefunguje to na společné napájení (8xAA) ani na samostatné napájení ani na napájení ze zdroje ze sítě.
Podle mě je už problém i v posílání dat po sběrnici, nemůže mcu při spuštění motorů být nějak zaneprázdněn tak, že si dat přicházejících z druhého mcu nevšímá?
Jak programujete komunikaci po I2C.

Pokud je vše zapojeno na jeden mikroprocesor tak senzor čáry šlape, s ultrazvukem je horší, protože se sem tam sekne a problikává nepravidelně dioda signalizující měření, ale funguje to.Dokonce ikdyž se otáčí servo ve kterém je také dc motor tak to nevadí.

Nyní master neustále měří data ze senzoru a pořád je posílá slevu a ten spíná motory.Co když to otočím?Master bude vysílat požadavek na měření a sleve změří jen jednou a pošle to zpět, může to mít nato vliv?

[AlesH]

Osobně bych se ještě pokusil pomocí testovacích programů alespoň trochu zúžit oblast, která je příčinou problémů.

Například nějak takto:
1. do slave procesoru (který řídí motory) nahraj program s pevně nastaveným časováním motorů (sekundu vpřed, sekundu vzad, atd.)
- pokud to bude šlapat podle očekávání alespoň minutu, tak tím eliminuješ možnost, že se procesor resetuje (při chodu motorů)
- pokud se to kousne, tak se musíš zaměřit na odrušení motorů a celý HW u slave procesoru
2. pak dej do slave standardní program i se čtením z I2C, ale z masteru posílej jen "vymyšlené" hodnoty (bez měření ultrazvukem)
- pokud to bude fungovat správně, tak by měl problém souviset s ultrazvukem
- pokud se to bude kousat, tak bude problém zřejmě v přenosu po I2C (v takovém případě zkus přenášet naměřené hodnoty pomocí pulsout a pulsin [mě se to osvědčilo])

Podle výsledku se pak můžeš zaměřit přesněji na problémovou oblast. Z tvých dosavadních popisů nedokážu zatím určit, kde by mohla být hlavní příčina problému.

P.S.: Faktem je, že rušení od motorů se někdy dost těžko eliminuje. Před pár roky se mi stalo něco podobného a podařilo se mi to potlačit jen zcela náhodou, lepším propojením na kostru robota. V dalších konstrukcích už jsem si na to dával větší pozor a problémy s rušením už nenastaly.

[haas]

No ještě to prozkouším jednou, dřív už jsem něco podbného zkoušel:nechat jen hlavní mcu a střídavě zapínat motory a fungovalo to, ale to bylo ještě před úpravami.
Zatím jsem zkusil jen samostatně za běhu resetovat slave a master jsem nechal běžet, po resetu okamžitě přijmul data z i2c zobrazil na lcd a zastavil nebo spustil motory, ale pak opět přestal komunikovat.Bude to asi špatnou komunikací nebo programem.Vše ještě prozkouším, díky za radu.

Jako to děláš přes pulsin?

[AlesH]

Data (číslo 0 - cca 1000) lze poslat z PICAXE např. takto (ven jde třeba pin C.4):

Kód: Vybrat vše

  cislo = cislo + 10  ; +10 aby i nejkratší pulz měl rozumnou délku
  low C.4  ; začínáme v LOW, aby pulz byl v HIGH
  pulsout C.4,cislo  ; délka HIGH pulzu odpovídá hodnotě "cislo" (v desítkách mikrosekund)

Ve smyčce se to může posílat třeba 100x za sekundu. Ve Tvém případě by to byl "master".

Na "slave" straně lze toto "cislo" přijmout např. takto (vstup jde třeba z pinu C.6):

Kód: Vybrat vše

  pulsin C.6,1,cislo ; zjištění délky HIGH pulzu
  cislo = cislo - 10  ; přepočet na původní hodnotu

Funguje to spolehlivě a přesně.

[haas]

Díky.Teď zkouším střídavě přepínat otáčky jen s jedním mcu a motory točí pořád jedním směrem, ale na lcd se zobrazuje střídavě "dopředu" "dozadu" a na výstupu z mikroprocesoru do h můstku jsem na pinech 4 a 6 kde se má střída log 1 a 0 naměřil v log 1 4.93V ale v log 0 je napětí 1.83V.Tohle by měl být zakázaný stav ne?
Tohle se mi nikdy nestalo.Měnil jse i hámůstek i mikroprocesor, ale je to pořád 1.83V.Pokud hmůstek vytáhnu ven tak na pinech měřím v log0 0.5V.
Čím to?Zase je něco špatně.
Tady kod:
//SLAVE


#include <LiquidCrystal.h>
LiquidCrystal lcd(11, 12, 10, 9, 8, 7);


void setup()
{
lcd.begin(16, 2);

}

void loop()
{


lcd.clear();
lcd.print("DOPREDU");
analogWrite(3,130);
digitalWrite(4,LOW);
analogWrite(5,130);
digitalWrite(6,LOW);



delay(5000);

lcd.clear();
lcd.print("DOZADU");
analogWrite(3,130);
digitalWrite(4,HIGH);
analogWrite(5,130);
digitalWrite(6,HIGH);
delay(5000);

}

[AlesH]

No, to vypadá docela "podezřele". Jak velké odpory máš mezi procesorem a H-můstkem? Z té fotky schématu to nedokážu rozluštit. Možná by se ty vstupy H-můstku daly "přizemnit" (přes vhodný odpor [cca 10 kiloOhm?]). Ale podle všeho by to mělo fungovat i bez "přizemňování", takže skoro bych to opravdu viděl na nějaký problém s propojením "zemí" (jak už tu jiní zmiňovali).