MacGyver

Elvis: Masz racje, jest taka opcja, wysyła dane po UARCIE. Wystarczy, je odpowiednio obrobić . W wolnej chwili przedstawię efekty. Dziękuje za poświęcony czas .

Inari: Gdyby koordynaty wyświetlały się w konsoli, nie byłoby problemu . Chodzi o to, że te dane zostają dodane do streamu online tak jak ma to miejsce w FPV. Pytanie czy z poziomu programu Motion można te dane w jakiś sposób poddać obróbce, czy to wysyłając po UDP, MySQL, czy może po prostu eksportując je bezpośrednio do pliku. Elvis: Właśnie w tym problem, że średnio mi to chciało działać, jak to testowałem. Z edycją plików źródłowych nie ma problemu. Wystarczy zmienne location.x, location.y poddać obróbce, ale zastanawia mnie czy da się to ugryźć prościej bez kompilacji plików.

Ja mam pytanie odnośnie programu "Motion". Wiem, że bez problemu można wyświetlić współrzędne (X, Y) obiektu, który jest w ruchu na ekranie, natomiast czy te dane można wysłać np. do pliku tekstowego ? Ostatecznie, zawsze można edytować pliku źródłowe i dostosować je do swoich potrzeb.

Cześć, powiedzcie mi, co trzeba zrobić aby puścić to na systemie 64bitowym?

Witajcie, tak sie zastanawiam, odnośnie funkcji konfiguracyjnej timer "SysTick_Config(SystemCoreClock / 1000);". Czy to przypadkiem nie jest błąd, że tutaj przerwanie wykona się co 1ms? Przecież analizując to, wynika jasno, że skoro zdefiniowanie SystemCoreClock na wartość 65MHz i następnie podzielenie jej przez 1000, to otrzymamy 65kHz. Idąc dalej tym tropem, czas po jakim nastąpi przerwanie będzie równy ~16ms. Dochodząc do sedna, czy to mój błąd analizy, czy po prostu ta funkcja jest tak "inteligentna", ze dzieląc wartość taktowania rdzenia przez tysiąc, funkcja potem odtworzy sobie przez ile podzieliliśmy i na postawie tego, ten tysiąc w rzeczywistości oznacza 1ms?

Paczka przesłana, podaję numer do śledzenia: 00359007736785352103.

Melduję odbiór przesyłki , wyśle jak najszybciej będę mógł

Chciałem pomóc, ale skoro mówicie, że paczki z tego samego miasta idą tak długo, to faktycznie mało sensowne Choć pomyślałem o osobach z Łodzi i myślę, że nie tylko w naszym województwie "tak liczna" grupa osób jest

Cześć, jadąc autobusem dziś, zastanowiłem się nad jednym. Czy nie lepiej przypadkiem, pogrupować ludzi ze względu na zamieszkanie(woj.)? Wtedy paczki na pewno szybciej pojawiałyby się u kolejnych osób. Minusem tego byłoby gorzej wyglądająca mapka na sam koniec . Jak myślicie ? P.S Nie, nie myślę o tym 24/7, taki przelot myśli jedynie

1. Treker 2. Bobby 3. BOTLAND 4. Hudyvolt 5. Grabki 6. fazi787 7. Chumanista 8. Mosi2 9. MacGyver

Zedytowalem post, przepraszam, ze tak pozno. Zachecam do wszelkich pytan . klonyyy, te 'iskry' to taki trik z nitro do czyzczenia opon . NITRO+ZAPALNICZKA=DRIFT . Troche zabawy nie zaszkodzi

Witam , takze podziele sie budowa swojej konstrukcji. Wszelki opis w liniu, zapraszam do komentowania (z ocena prosze sie powstrzymac ) https://www.forbot.pl/forum/topics7/line-follower-lf-lemua-vt11176.htm#95707 Pozdrawiam, MacGyver

Witam wszystkich , po raz trzeci, pragne przedstawić kolejnego robota. Wlasciwie to moja perelka, ktora miala sprawic, ze zbuduje robota swiezszego, odmienionego, szybszego i niekonwencjonalnego. Tak zrodzila sie kobieta wsrod moich linefollowerow- ognista i drapiezna Le'Mua. Ze wzgledu, ze kazda konstrukcje buduje dla kogos, tym razem dedykuje go mojej super dziewczynie . «Zalozenia projektowe» Jak skonczylaby sie praca, gyby nie ten wazny wyznacznik. Uprzednio zbudowalem juz kilka konstrukcji, tym razem chcialem zrobic cos innego od moich poprzednich dzieciaczkow . Nie bede sie rozpisywal w tym podpunkcie, po prostu ponizej podam zalozenia, ktore chcialem osiagnac. •Lekka stabilna, konstrukcja, pozbawiona, zbednych "bajerow"; •Jak najmniejsza bezwladnosc(silniki jak najblizej srodka, lekka listwa); •Wykorzystanie wlokna weglowego podczas budowy; •Korpus robota, wydrukowany w oparciu o technologie druku 3D; •Felgi i opony charakteryzujace sie dobrymi wlasciwosciami trakcyjnymi; •Ulepszony model pilota START/STOP; «Modeluj, modeluj, trac godziny, a potem zamiast naprawiania, poswiedz czas dla rodziny...- Projekt w Inventorze.» Rzadko mi sie zdarza, aby projekt, ktory tworze, nie zostal rozpoczety w srodowisku do projektowania i wizualizacji w 3D. Tradycyjnie, w moim przypadku jest to AutoCAD Inventor, dzieki ktoremu jestem w stanie zaoszczedzic czas, na dopasowanie i polaczenie ze soba wszystkich elementow w calosc. Tym razem takie projektowanie bylo takze podyktowane takze tym, ze korpus robota mial zostac w pozniejszym czasie wydrukowany na drukarce 3D. Do tego zalezalo mi na dobrym dopasowaniu ze soba elementow(lozysko-wal-silnik). Ponizej zrzut z programu. Zrzut ekranu z programu AutoCAD Inventor. «Czujniki zwesza wszystko» Tym razem mala zmiana! Chcac uzyskac jak najlzejsza wage, musialem zdecydowac sie na ograniczona liczbe czujnikow. Zdecydowalem sie uzyc 8 czujnikow. Dlazego tak? Liczba 8 symbolizuje trwalosc i wykonanie powierzonego zadania , a tak powaznie, to wykorzystujac mikrokontroler ATmega328, jestem swiadomy, ze najszybciej beda wykonywane operacje wlasnie na jednym bajcie, zatem takie czujniki moge zdeklarowac w jednym rejestrze. Co do elementow, nowosci tutaj nie ma, znane i lubiane KTIR, ktore cechuja sie bardzo duzym "podobiestwiem" produkcyjnym, tj. parametry kazdego z sensorow, sa niemal identyczne. Tutaj niestety mala chlapa, bowiem prototyp stworzylem na laminacie w domowym zaciszu, wiec sama linijka z czujnikami wazy duzo za duzo, ale znalazlem pomysl na szybkie odchudzenie, szlifujac warstwe laminatu(plytka jest jednostronna). Solder maska wykonana z markera wodoodpornego. Ponizej zrzut. Linijka czujnikow. «Plyta glowna.» Poczatkowo, zaprojektowalem plytke sam, lecz niestety wewnetrzne pull'upy procesora podlaczaone do kolektorow czujnikow posiadaja zbyt duzo wartosc i sensory nie dzialaly tak jak powinny. Zdecydowalem uzyc sie mini plytki Orangutan Baby, w sklad ktorej wchodzil mostek H, TB6612, ATmega328, kwarc 20Mhz i "dorobic" do niej plytke z rezystorami pull'up, zlaczem ffc, padami do komunikacji z odbiornikiem RF. Projekt plytki w programie Eagle. «Opony i Felgi.» Aby robot byl wstanie osiagnac wysokie predkosci, nieodzownym elementem sa odpowiednie opony. Tutaj odrazu moge powiedziec jak diametralna roznica jest miedzy kolami pololu, a np oponkami Mini-z. Za przyklad podam, ze moj robot z turbina zwiekszyl swoja predkosc o 20%. Felgi wydrukowalem na drukarce 3D, jej wymiary to 21x11(srednica, szerokosc), na felge ciasno wchodzi opono od Mini-z, o trwalosci 20°. Tutaj zamieszcze "palenie, gumy/drift". Felgi x2. «Korpus.» Chcialem, aby konstrukcja byla dosc zwarta, wydrukowalem ja na drukarce 3D, dzieki czemu 'szaszi' robota mialo bardzo mala wage. Aby robot byl szybki zwrotny, postanowilem silniki skupic w centrum robota. Klopotem moglo okazac sie przeniesienie napedu na kola, rozwiazalem to, poprzez przedluzenie walu silnika pretem z wlukna weglowego(pret i tulejka). Minusem takiego rozwiazania bylo zwiekszenie bezwadnosci rotora silnika, lecz w porownaniu ze zmniejszeniem bezwaldnosci calego robota nie ma o czym mowic. Robot zyskal dynamike, dzieki temu rozwiazaniu. Korpus robota. «Akumulator.» Waga, waga, i jeszcze raz waga, szukalem jak najlzejszego pakietu Li-Po 2S, udalo sie wyszukac takie o pojemnosci 150mAh,napieciu znamionowym 7.4v, wydajnosci 20C i wadze 7g. Pakiet jest przyklejony na rzep techniczny do tylniej sciany robota. «Ahmed odpalaj- modul zdalnego startu» Kazdy zna to uczucie, kiedy robot wypada z toru, a my nie jestesmy w stanie go wylaczyc i powstrzymac od urazow . Dlatego ulepszylem wczesniejsze rozwiazanie, pilot-nadajnik RF317Mhz, Atmega8, USART. Calosc dziala tak, ze po wscisnieciu przycisku w pilocie, nadajnik wysyla parenascie razy komende startu- '3'. Robot aby wystartowal potrzebuje zebrac 10 takich komend w przeciagu ~200ms, jesli sie uda-START, jesli nie czeka na kolejny raz. Po wcisnieciu przycisku na pilocie powtornie, nadajnik wysyla sygnal Stop-'1'(jeden przycisk, takie TOGGLE BIT) i calosc dziala adekwatnie do startu. Obudowa pilota zostala zbudowana z laminatu fr3 oraz plexi . Pilot zdalnego startu. Film z Zawodow w Wideniu na RObot Challenge 2015 WIeden nie okazal sie udany , mialem problemy z silnikami, dlatego robot jezdzil znacznie wolniej niz normalnie Serdecznie przepraszam, za brak polskich znakow, niestety jest to podyktowane anglojezyczna wersja systemu Linux. Zachecam do glosowania , Pozdrawiam, MacGyver

Witaj, wydaje mi sie, ze program jest ok, natomiast samo przerwanie wywoluje sie za szybko. Wedlug moich obliczen zakladajac czestotliwosc taktowanai procesora rowna 1MHz, przerwanie wywoluje sie co ~195Hz(1MHz/64/80)zatem ludzkie oko ze wzgledu na swoja zawila budowe, (konkretnie chodzi o bezwladnosc), nie bedzie w stanie dostrzec tak szybkich zmian. Choc z drugiej strony powinny swiecic sie wszystkie z tego powowdu, a nie jak piszesz zadne. Slowa dioda, nie odmienia sie na "di"u"d", tylko diod

Zerknalem na Twoj kod, dodalbym jeszcze warunek: if(aktualna_pozycja ==0) { silnik_L(0,predkosc); silnik_R(0,predkosc); } Jest fajny myk jak sprawdzic czy robot zapamietuje po ktorej stronie sie znajdowal. Poloz na lini robota, wlacz go, ale tak, aby caly czas miec nad nim kontrole(utrzymuj go reka ). Teraz daj mu swobodnie jechac i w trakcie spychaj z lini po obu stronach, zobacz jaka jest reakacja . Jesli robot wraca za kazdym razem jest super, natomiast jezeli po "przepchnieciu go poza linie nie wraca na nia, to bedzie oznaczalo, ze problem lezy prawdopodobnie po stronie czujnikow. Mialem podobny problem, kiedy po raz pierwszy zbudowalem detekecje lini w oparciu o wykorzystanie wewnetrznego przetwornika ADC. Okazalo sie, ze wewnetrzne rezystory podciagajace kolektory czujnikow podowodwaly problemy. Musialem zrobic nowa plytke z rezystorami zewnetrznymi, problem zaniknal . Warto nadmienic, ze w ATmedze 8(innych takze tez) w obudowach SMD, mamy dodatkowe dwa kanaly ADC. Nalezy pamietac, ze nie sa to wejscia/wejscia cyfrowe, lecz jedynie kanal przetwornika, zatem nalezy tam bez wzgledu na wszystko dolaczyc zewnetrzny pull'up. Jesli masz multimetr, a zakladam, ze kazdy robotyk powinien go posiadac, przelacz go na pomiar napiecia stalego i sprawdz jakie napiecia masz na wyjsciu kolektora swoich czujnikow. Problemem moze byc fakt, ze posiadasz multiplekser. Sprawdz kazdy czujnik po kolei zarowno dla czarnej, jak i dla bialej barwy. Podziel sie wynikami . Jeszcze jedna sprawa, Widze, ze napiecie progowe lini masz ustawione na 850, odniesieniem jest wewnetrzne zrodlo =VCC, zatem po szybkich obliczeniach, wychodzi ze przy okolo 4.15v czujnik wychwytuje linie, wydaje sie to ciut przesadzone. W jaki sposob dobrales taka, a nie inna wartosc? obserwacja, czy raz "na pale" ustawiles taka wartosc i potem jej juz nie zmieniales ? Na przyszlosc polecam wyprowadzic sobie zlacze od komunikacji szeregowej UART, pod ktory bedziesz mogl podlaczyc poprzez np. Bluetooth, RF, czy tez komputer swojego robota i zdalnie sprawdzac co sie dzieje we wewnatrz procesora. To naprawda znacznie ulatwia prace! Swoja droga, super, ze pracujesz w Eclipsie, tez od ostatniego czasu postanowilem sie przerzucic na to srodowisko, z przestarzalego juz AVR Studio 4 . Jak Ci sie w nim pracuje ? Korzystales wczesniej z dobrodziejstw innych programow?