Skocz do zawartości

lukix

Użytkownicy
  • Zawartość

    103
  • Rejestracja

  • Ostatnio

Wszystko napisane przez lukix

  1. O, SpeedCrunch jest znacznie bardziej zbliżony do mojego programu niż Matlab, Mathematica itp. Wygodnie używa się w nim jednostek. W SpeedCrunchu brakuje mi jednak możliwości edycji wprowadzonych wcześniej wyrażeń. Da się odwoływać do zadefiniowanych wcześniej zmiennych, ale nie ma możliwości zmiany ich wartości, tak aby wszystkie zależne od nich wyrażenia automatycznie się przeliczyły. Pewnie jest to trochę zrekompensowane możliwością tworzenia własnych funkcji, ale to nie to samo
  2. Miałem trochę doczynienia z Matlabem, o pozostałych programach, które wymieniłeś jedynie słyszałem. Wydaje mi się, że są one dobre do robienia bardziej zaawansowanych rzeczy, natomiast do prostszych obliczeń mają stosunkowo wysoki próg wejścia - powiedziałbym, że porównywalny z nauką programowania.
  3. Cześć, Przez ostatnie kilka miesięcy pracowałem nad aplikacją internetową służącą do wykonywania obliczeń matematycznych/fizycznych i chciałbym poznać Wasze opinie na jej temat. Aplikacja ta umożliwia budowanie ciągów zależnych od siebie wyrażeń matematycznych i obliczanie wyników dla zmieniających się danych wejściowych. Bardzo prosty przykład - wyznaczenie długości przekątnej prostokąta: a = 6 b = a / 2 d = sqrt(a^2 + b^2) Wpisując powyższe działania, na ekranie wyświetli się wartość zmiennej b, oraz zmiennej d. Dowolny fragment działania może zostać zedytowany i całość zostanie natychmiast przeliczona od nowa (na przykład zmieniając wartość zmiennej a, dostaniemy nowe wartości b i d). Może to przypominać mocno ograniczony język programowania, jednak w założeniu ma być łatwiejsze i wygodniejsze w użyciu. Dużą zaletą jest obsługa jednostek fizycznych - nie musimy zajmować się ręcznym przeliczaniem cali na metry, dżuli na kilowatogodziny itd. W dodatku obsługa jednostek (analiza wymiarowa) pomaga znaleźć błędy w obliczeniach (np. próba dodania metrów do kilogramów zakończy się poinformowaniem użytkownika o błędzie). Z aplikacji można korzystać bez tworzenia konta (jednak posiadanie konta pozwala zapisywać obliczenia). Adres: calcspace.com Czy taka aplikacja może być dla Was przydatna? Jeśli nie, to czy jest coś co musiałoby się zmienić, żeby zaczęła być przydatna?
  4. Prawdopodobnie dlatego, że bateria 9V ma bardzo małą wydajność prądową. Mimo wyższego napięcia nie jest w stanie dostarczyć wystarczająco dużego prądu.
  5. Dedykowane kamery do raspberry właśnie to robią. Nie w procesorze kamery, ale w procesorze graficznym maliny. Dzięki temu konwertowanie do np. jpeg nie obciąża CPU.
  6. Ja u siebie rozwiązałem to tak, że w momencie gdy żaden czujnik nie widzi linii, robot wie w którą stronę skręcić na podstawie tego pod którym skrajnym czujnikiem (najbardziej wysunięty w lewo albo w prawo) ostatnio widział linię. Czyli podobne rozwiązanie, które już stosujesz (na podstawie kodu w pierwszym poście), ale bierz pod uwagę tylko skrajne czujniki. Gdybyś miał skrajne czujniki przesunięte lekko do tyłu względem pozostałych to prawdopodobnie nie było by tego problemu nawet przy obecnym programie.
  7. Nie miałem styczności z tymi oponami, więc nie wiem jak dobre one są. Ja na zwykłych pololu osiągałem (jeśli dobrze pamiętam) coś około 32% pwm. Później zmieniłem koła na takie: https://www.fingertechrobotics.com/proddetail.php?prod=ft-minisumo-wheels-1125 I teraz jestem w stanie osiągnąć 45 - 55% pwm na trasie z kątami prostymi. Opony muszą być często czyszczone, bo przyczepność bardzo szybko spada. Przy tych 50% wydaje mi się, że można już zaczynać myśleć o jakiś miejscach na zawodach, ale na to też wpływa bardzo dużo czynników. Trzeba też pamiętać, że pwm nie przekłada się idealnie na prędkość robota.
  8. Kilka razy się upewniałem z tym znakiem, a i tak się pomyliłem Masz rację - jest dobrze. Ja już chyba za wiele nie wniosę. Musisz eksperymentować i obserwować wyniki. Nie wiem jakie masz silniki i koła, ale np. 22% PWM dla silników Pololu 10:1 z kołami 32mm to nie jest taki zły wynik (choć da się lepiej) EDIT: Ważne są też mechaniczne kwestie - moment bezwładności, odległość czujników od osi kół itd. Może to tu jest większy problem?
  9. 1) Zauważyłem, że masz w kodzie zły znak w liczeniu zmiennej derivative. (powinno być previousError - error). 2) Ostre zakręty w dosłownym znaczeniu (mniej niż 90 stopni)? 3) Problem z wyjściem z zakrętu możesz rozwiązać w ten sposób, że będziesz tylko zmniejszać pwm dla jednego silnika, bez zwiększania dla drugiego. 4) Jak dalej nie będzie efektów to może pokaż jakiś filmik jak to wygląda.
  10. Człon P powinien być liczony jak najczęściej. Ograniczenie do 5ms powinno być stosowane tylko do członu D (i ja bym je zwiększył do około 20ms, ale z tym trzeba po prostu poeksperymentować). A wagi czujników dobrałbym bardziej liniowo w zależności od odległości.
  11. http://eblaszki.pl Nie korzystałem, ale piszą, że wykonują zlecenia od 1 sztuki (bez ceny minimalnej). Jest tam też automatyczna wycena online.
  12. Przełącznik już ląduje na płytce głównej Co do rozmieszczenia czujników: Spotkałem się z opiniami że na środku powinna być jak największa gęstość rozmieszczenia czujników, a dodatkowo po bokach dwa oddalone skrajne. Nie zgadzasz się z tym? Wysunięcie czujników w przód/w tył - widziałem roboty z czujnikami rozmieszczonymi i tak i tak, a wysunięcie w przód było dla mnie wygodniejsze... Czyli jakie będzie najlepsze rozmieszczenie Twoim zdaniem? Te dwa skrajne dać tak samo jak reszta, tylko trochę do tyłu? Tak? A o ile do tyłu?
  13. Nie dało się zmniejszyć ilości pinów w tym złączu. Mógłbyś sprecyzować? Nieznacznie, czyli o ile? Zaprojektowałem płytkę z czujnikami: Oczywiście później rozleję masę.
  14. Uwzględniłeś że grubość miedzi to 70um a nie 35? Według kalkulatora grubości ścieżek, którego stosuje 12 mil wystarczy na 1.6A. No ale ok, na wszelki wypadek poszerzyłem do 16 mil. Jeszcze zauważyłeś coś do poprawy?
  15. Jeszcze pewnie coś pozmieniam, aby płytka była jak najmniejsza, ale chciałbym wiedzieć gdzie robię ewentualne błędy. Jakiej pojemności Waszym zdaniem powinien być akumulator? Czy 220 mAh to za mało? (mogę mieć takie dwa, żeby móc szybko wymieniać na naładowany). IMHO nie jest to konieczne, ale gdybym jednak to robił - żeby odciąć te piny od schematu i w projekcie PCB, mam edytować bibliotekę z tym elementem?
  16. To były jakieś zawody w Chorzowie? Szkoda że nie było tego w kalendarzu zawodów, bo chętnie bym przyjechał :/ Jakiego lipola używasz w robocie? Ile mAh?
  17. Zwiększyłem. Czemu mam dwa wolne piny w listwie? A czemu nie? Potrzebowałem tylko 12, a nie 14 Mniejszych listew nie ma w sklepie, w którym chcę je kupić.
  18. Poprawiłem, dzięki. Reszta kondensatorów na schemacie jest dobra? Wszędzie poza jednym przy mostku i dwóch przy stabilizatorze są ceramiczne.
  19. Yyy... To gdzie mają być elektrolityczne, a gdzie ceramiczne? Tak jak mam teraz na schemacie, tak jest w dokumentacji stabilizatora.
  20. Dziękuję za odpowiedzi. Trochę zmieniłem schematy: Filtracja zasilania przy uC jest już ok? Podłączenie stabilizatora jest na tyle proste że nie powinno tam być błędu, ale na wszelki wypadek rzućcie okiem W schemacie z czujnikami jest tylko zmiana sharpa. Jeśli schematy są ok to biorę się za płytki PCB.
  21. Hehe, wiem. Problem w tym że nie wiem czy ma takie same wymiary i wyprowadzenia. Wygląda podobnie, natomiast nazwa obudowy w Eaglu to TO252, a na stronie botlandu DPAK. Niby inna, ale może jedna z tych nazw jest jakoś bardziej ogólna...?
  22. Odłożyłem ten projekt na dosyć długi czas, ale nadchodzą wakacje i dużo wolnego, dlatego powracam do pracy. W związku z tym kilka pytań: 1. Stabilizowanie napięcia na silnikach nie jest konieczne. Częste ładowanie akumulatora powinno rozwiązać problem różnych prędkości w zależności od napięcia. Zgadzacie się? 2. Czy stabilizator 5V MC7805 SMD będzie dobry do stabilizowania napięcia logiki? 3. Czy w Eaglu mogę zastąpić ten stabilizator np. tym - 7818DT? Nie umiem znaleźć w internecie biblioteki do tego elementu.
  23. Na androidzie ICS działa, ale: Czemu aplikacja ma takie uprawnienia, które są IMO niepotrzebne? Tak poza tym świetny pomysł
  24. Gdybym użył komparatora z atmegi to: 8 czujników do ADC, 1 przez komparator A teraz mam: 8 czujników przez komparatory, 1 do ADC Więc i tak jest ten podział, a do tego nie tracę dwóch pinów na wewnętrzny komparator. Na stronie botlandu pisze że przy wykrywaniu tylko biały/czarny mogą działać na odległości nawet kilku centymetrów. No ale jak mówicie że za wysoko to jeszcze pomyślę jak to rozwiązać.
  25. dondu, zabrakłoby mi jednego ADC. Carpe Diem, ok, rozumiem - trzeba poprawiać
×
×
  • Utwórz nowe...