kristofus

Patrząc w API ma całkiem sporo możliwości sterowania zarówno prędkością jak i akceleracją: https://www.phidgets.com/?tier=3&catid=18&pcid=15&prodid=1089#Connections I pewnie Cerea z tego korzysta. No ale jak trzeba szybko to i power musi być Aha, to szarpanie normalnie aż tak nie występuje, to były testy na linii ABcurve z pierwszego przejazdu, one zwłaszcza w C300 mocno szarpią, kolejne sąsiednie wyliczane linie są już wyraźnie wygładzone, linie ABrect to wiadomo, jak strzała

Cerea ma info ze sterownika o pobieranym prądzie, wersja 300 jest chyba nawet bardziej czuła i przy 12V wydaje się zbyt szybko reagować na piki prądu bo potrafi rozłączyć AUTO przeciążeniowo przy gwałtowniejszych manewrach na nierównym polu mimo, że zdaje się aż 6A ustawiłem. Na 24V na razie tego nie zauważam ale to dosyć logiczne, przy wyższym napięciu ta sama moc osiągana jest przy niższym prądzie. W ogóle przy 24V jest niezły power, tu już nie ma żartów, paluszki może poturbować Poszukam jakiegoś kompromisowego napięcia, przetworniczka ma regulację. Zostanie i poczeka na moda "pasek zębaty", zapas prędkości jest fajny do manewrów ale szczerze mówiąc w normalnej jeździe przy dobrym starcie blisko ścieżki spokojnie wystarcza 12V, bez kombinacji.

Kłowe... Chyba podsunąłeś mi pewien pomysł...

Zgoda, o tych luzach wspomniałem, to może być argument za czujnikiem na kołach ale jeszcze raz, wszystko zależy od skali problemu, jeśli luz będzie nienormalnie duży to sądzę, że i przy czujniku na kole precyzyjne sterowanie za pomocą silnika na kierownicy będzie bardzo trudne. Możesz podrzucić jakiś link/zdjęcie tego mechanizmu "grzechotki"? Chętnie przeanalizuję zaimplementowanie.

Ok, ale komentujesz pod kwestią dotyczącą czujnika skrętu Co do czujnika indukcyjnego dla MARC rzeczywiście, w kombajnie czy ciągniku są to de facto potencjometry z programowanym progiem zadziałania, w sumie na arduino to banalnie proste do zrobienia ale znów, dodatkowo komplikuje układ, zwłaszcza mechanicznie, bo potencjometr, dźwignie, etc. Póki co regulacja będzie tego rodzaju plus odpowiednio duża powierzchnia widziana przez czujnik w zakresie pracy. Myślę, że sprawdzi się wystarczająco dobrze, jeśli nie, kolejny upgrade to pewnie będzie dołożenie regulowanego progu zadziałania.

Klikam dwa razy na wstawianym obrazku, zmniejszam mu wielkość, niby wygląda OK ale jak zapisuję posta wyświetla się z powrotem wielki. Tak swoją drogą to ostatnio kuleje mi też przechodzenie między stronami w wątku, Np. otwieram wątek, klikam 4 stronę, ok, klikam 6 stronę i... nic się nie dzieje. Przed chwilą sprawdzałem na 3 różnych przeglądarkach, i zalogowany, i nie. Co do czujnika w hydraulice rzeczywiście, pewnie to jedyny sposób na informację o położeniu kół. Przy napędzie elektrycznym powtórzę się, rozwiązanie z encoderem na silniku moim zdaniem jest zdecydowanie bardziej praktyczne i niezawodne. Koszt to droższy encoder i kontroler typu "servo", AGOpengps w tej kwestii jest do bólu minimalistyczny i czujnikiem skrętu ten minimalizm nadrabia. Nie wiem, może w przypadku jakiś wybitnie dużych luzów na kierownicy info z kół miałoby jakąś przewagę, dla mnie najważniejsze jest, co widać, że bez tego dodatkowego skomplikowania układu pracuje on naprawdę bardzo precyzyjnie. Nie możesz mieć takiego samego to mój autorski projekt: Jak zrobić? Fusion 360 (free dla hobbystów) i drukarka 3D, tak najprościej mówiąc Chyba go jednak przerobię, zasprzęglanie promieniowe komplikuje znacznie mechanizm, w kombajnie mam zupełnie sztywno a zasprzęglam opuszczając kierownicę, w drugim ciągniku silnik przesuwa się osiowo góra-dół, to znacznie prostsze, sztywniejsze i wytrzymalsze rozwiązanie. Coraz bardziej też zastanawiam się nad przeróbką na pasek zębaty tylko wtedy byłby trochę problem z łatwym i szybkim wysprzęglaniem. Jednak już teraz nowy algorytm daje popalić i uwypukla wszelkie luzy przekładni, przy 24V będzie pewnie jeszcze gorzej. Natomiast pasek to cisza i praktycznie bezluzowa praca. Tak jak Damian pisze, pedału nożnego używamy w zasadzie od początku jednak dla mnie zwłaszcza w ciągniku to zdecydowanie mniej ergonomiczne rozwiązanie, nie zawsze używam HMS-a, w kluczowych momentach nogi często są zajęte gazem/sprzęgłem. Poza tym przebieranie nogami mi zupełnie nie podchodzi. Teraz przycisk mam tam gdzie trzymam rękę, pod wolnym palcem, ergonomia jest super. Kombajn z hydro to rzeczywiście trochę inna filozofia, nogi są w zasadzie wolne a ręka na joyu bardziej zajęta. Jednak patrząc na nowe joy-e JD to mają one przycisk AUTO. W nowych ciągnikach JD zresztą AUTO też widzę jest pod ręką, nie nogą. Z czegoś to wynika, spece od ergonomii na pewno mają w tym udział. W kombajnie planuję zrobić na joyu, jedynie z wielkością przycisku będzie trochę problem ale mam już zakupione takie naklejane membranowe, zobaczę jak się sprawdzą. edit: P.S. z tymi obrazkami chyba problem polega na tym, że post wyżej wkleiłem obrazki Ctrl+V a nie załączyłem z plików. W poście są dwa załączniki image.jpg i pewnie dlatego się to pieprzy.

Nowa wersja nowy interfejs (Arduino) +5 punktów do szczęścia i komfortu, najbardziej potrzebny przycisk pod ręką, czujnik lada moment też będzie zamontowany i będzie automatycznie sterował MARK-owaniem na podstawie położenia ramienia TUZ (lub przenośnika pochyłego w kombajnie) Ale nie o tym przede wszystkim... Już pierwsze próbne jazdy mimo tradycyjnego kopania się z instalacją/konfiguracją Cerea300 sugerowały efekt "wow". Algorytm Cabin RWF... rządzi Jednak dwa kolejne dni przepracowane w uprawie..., no cóż obraz jest wart tysiąca słów https://youtu.be/amXLq_rIXn8 Po chwili strojenia 14km/h bez historii typu wpadanie w oscylacje, etc. Pole na wiosnę agregatowane, dość równe i miękkie ale mimo wszystko, taka prędkość to w starej wersji albo niemożliwość albo duże kompromisy w kwestii precyzji... A tu drugi dzień, już bez litości, twarde, nierówne, "bezorkowe", talerzowane tylko jesienią pole, wiosną w bólach przebronowane: https://youtu.be/8eDnXPHZ6Uw Widać dobrze jak przyspieszam co się dzieje na kierownicy i jak zaczyna działać magia nowych algorytmów. Jest szybki, za***iście precyzyjny. Naprawdę po pierwszych jazdach wrażenie miałem takie, że to w końcu przypomina odczucia jakie miałem po obejrzeniu filmu z fabrycznego JD na hydraulice. Brakuje może jeszcze prędkości w manewrowaniu ale już kolejny mod w drodze... Damian wykupił mi przetworniczki step-up i się cieszy szybszym silnikiem, ja ciągle czekam na dostawę... Chodzi o to, że silnik/kontroler Phidget-a jest 24-voltowy, do tej pory pracował bezpośrednio z instalacji na 12V (a na pewno <14V). Zdecydowałem wysterować go do pełnego napięcia/prędkości i podobno to robi różnicę... Druga kwestia, jakkolwiek bardzo doceniam koncepcję i tworzenie AgOpengps, tak teraz już kompletnie nie rozumiem potrzeby dodatkowych komplikacji i ewentualnych problemów związanych z koniecznością używania czujnika skrętu. Skoro algorytm może działać tak jak widać bez, to po co?? Na deser efekt wolnego przejazdu na autoprowadzeniu w tę i z powrotem dla sprawdzeni precyzji Ogólnie problemów trochę jest z Cerea300 ale w dużej mierze z niejasności językowych. To tak naprawdę beta, z jakiś powodów (autor nie zna póki co przyczyny) program na tabletach z WinPL (choć próbowałem na wszelkie sposoby przestawić też na EN(US) ) odpala się w wersji hiszpańskiej. Więc pewnie mógłbym uniknąć paru fakapów wynikających poniekąd z niezrozumienia. To jednak pewnie lada moment będzie usunięte, tak naprawdę jest kolejna fajna wiadomość, dostałem od autora plik językowy, kończymy już właściwie wstępne tłumaczenie, jest szansa, ze następna C300 będzie już po naszemu No i mam nadzieję już łatwiejsza do ogarnięcia P.S. Próbowałem z 5x edytować i pozmniejszać obrazki ale bezskutecznie, @yacenty masz na to jakiś wpływ może?

Jakby ktoś nie zauważył, w nocy wyszła długo oczekiwana Cerea300 https://www.dropbox.com/s/v5sixgily6pgt0r/Cerea300Setup.exe?dl=0&fbclid=IwAR3ot6R0k-2RiB8k_p6MDodkoTZBYyY5UZ9d9qUku2IYvh-GEC0jnHzPZPA https://www.youtube.com/watch?v=aaJsAr4SVNI&list=PLONNmDW_ni3cs9BSX8x8xzWomD8nym2Ca&fbclid=IwAR3nYhHQWQ0XebsZQfkYBao33ySdJ9A7iMU3ppDaNeY1QjBTy19KDA2OZ5M

W poście wyżej pokazałem "zoomowanie" do bardzo precyzyjnej skali na jaką pozwala Qgis, niestety coś złego dzieje się obecnie z granicami w KEIG zaciąganymi przez WMS. Kiedyś rzeczywiście schodziłem u siebie z precyzją wyświetlania na pewno grubo poniżej milimetra, teraz w moim powiecie przybliżając więcej niż do skali 1:22 granice z WMS znikają. Jest to w jakiś sposób uzależnione od powiatu, dziwne, bo np. w sąsiednim mogę sobie przybliżać do woli. Próbowałem zasięgnąć języka w Geoportalu i na razie nie dostałem jednoznacznej odpowiedzi jakie są przyczyny takiej zmiany ale wygląda na to, że powiatowe biura coś mieszają przy wprowadzaniu danych. P.S. Zrobiłem po dłuższym główkowaniu eksport punktów naniesionych ręcznie na warstwę "shapefile" do pliku .csv, który można docelowo podłożyć jako .pts do darmowej wersji MobileTopographer-a ale... jest tak zamotana, że nie jestem w stanie jej opisać Niemniej jest to wykonalne. Główna zabawa to zrobienie tabeli atrybutów dla warstwy, z polami w odpowiedniej kolejności, odpowiednich typach i odpowiednio wypełniane współrzędnymi:

Groundplane, pełna profeska... 😀😉

Jeśli tylko Trimble potrafi zaimportować takie linie przejazdu i nie jest to jakiś binarny, trudny do ugryzienia format danych to na 99% w Qgis jesteś w stanie go stworzyć. O precyzję bym się nie martwił, dokładność F9P to nie jest jakieś marketingowe "przejazd do przejazdu" tylko bezwzględne, stabilne w czasie, przy bazie w rozsądnej odległości 1-2 cm dokładności wyznaczania granicy. Chodziło mi coś podobnego po głowie do Cerea ale tam po pierwsze format zapisu "patrones" niby tekstowy ale jakiś taki mało intuicyjny, po drugie no cóż, miedze prostymi liniami nie są więc moim zdaniem to mogłoby się przydać do rozsiewacza, może opryskiwacza, do uprawy nie widzę zupełnie potrzeby natomiast do siania myślę, że trzeba by w to włożyć niewspółmiernie dużo pracy aby wystarczająco dokładnie skopiować miedze, przynajmniej u mnie. A przecież przy dokładności i powtarzalności RTK ślad zgrany dzisiaj za rok powinien spisać się przynajmniej tak samo dobrze. Jeśli masz szansę wytyczać linie punkt-punkt to trochę inna sprawa.

Qgis to potężne, zwłaszcza jak na darmowe, narzędzie. Warto się wgryźć bo różne fajne rzeczy mogą przyjść do głowy. Np. mapa pola którą kiedyś wrzuciłem to źródłowo wypluty z Cerea log przejazdu gdzie 10 razy na sekundę zapisywane są jakby punkty skrajne narzędzia. Po odpowiednim przeparsowaniu i "upchaniu" w jakąś geometrię do pliku .wkt (punkty, linie, wielokąty) dalej można sobie to w Qgis dowolnie wizualizować, co tylko przyjdzie do głowy, choćby mapę plonu czy profil wysokościowy, można sobie dodatkowo dołożyć do tego jakieś inne dane, choćby próbki gleby. Trochę zabawy na pierwszy raz jest ale jak się raz opracuje jakiś "flow" obróbki to już potem łatwiej. Ta moja mapka jak patrzę to w rzeczywistości jakieś 100tys linii (czyli prawie 3h pracy na polu) ze współrzędnymi oraz odpowiadającą im daną (wysokość, plon, prędkość, co tylko się zloguje). Mimo tej ilości danych Cerea całkiem żwawo sobie z tego co pamiętam z obróbką radziła.

Nie mam pojęcia, apki nawet nie odpalałem, pytaj użytkowników w sąsiednim wątku.

1:1? Jak szaleć to szaleć, do 10 miejsca po przecinku metra Tylko coś mi ładowanie granic przycina, albo net albo geoportal kuleje... Txt nic nie mówi. musisz ogarnąć jak są zapisane pozycje, dostosować format/układ współrzędnych, i albo wyeksportować np. do mobile topographera na andka (przez BT xbee) (nawet nieźle ogarnia namierzanie punktów w terenie w wersji darmowej, mapy nie widać ale jest dystans/kierunek) albo próbować jakoś podpiąć tablet z qgisem do F9P no i tak jak w Cerea ustawić ładowanie korekt do odbiornika za pomocą rtklibów, to może być trochę karkołomne na jednym porcie ale zawsze można podłączyć Ardusimple dwoma portami i na jeden ładować RTCM, drugi com z NMEA będzie dostępny dla Qgis-a. Tyle, że tego nie próbowałem (z qgis+gps), z ardusimple nie powinno być problemu, domyślnie chyba i tak ten port przeciwnie od anteny jest także ustawiony na karmienie RTCM, notabene na poziomie płytki to ten sam port odbiornika, który jest podpięty do wyprowadzeń xBee. Inna opcja do RTCM-a to windowsowa apka Lance'a: http://lefebure.com/software/ntripclient/ O, jeszcze Damian mi podrzucił przepis na qgis+rtklib+F9P po socketach tcp, wtedy nie trzeba kombinować z dwoma portami:

Można rysować na warstwach, możesz odczytywać współrzędne na dolnym pasku (RODO adres to dane osobowe ), układ współrzędnych możesz zmieniać we właściwościach projektu, na warstwach też się je określa. Dalej Ci nie pomogę bo to jest w jakiś sposób od siebie zależne ale nie pamiętam. Podobnie z rysowanie, eksportami, Qgis-a znam tylko pobieżnie. Naprawdę warto pochylić się nad kursem, z tego co pamiętam to zwłaszcza te zawiłości układów współrzędnych były tam dobrze ogarnięte.

Tą ikonką dopinasz różne źródła, między innymi jest tam WMS, wybierasz sobie co chcesz z geoportalu https://www.geoportal.gov.pl/uslugi/usluga-przegladania-wms, granice to pierwsze źródło KIEG, łączysz się, wrzucasz odpowiednią kategorię, tworzona jest warstwa. Tą samą drogą możesz dodać inne warstwy, na przykład fotograficzną ortofotomapę, rastrówki, schematy sieci gazowniczej, elektrycznej, etc., sporo jest zdigitalizowane w tych źródłach, warto się pobawić. Punkty/linie, jeśli masz je z jakiegoś źródła ładujesz tą samą drogą ale na warstwy wektorowe, nie wiem, gpx, kml, co Ci tam używany do zbierania program ogarnia. Co do pomiarów na osnowie POLREF to są na pierwszej stronie wątku.

Tu nie chodzi o mapę, zwłaszcza jakąś rastrówkę, w Geoportalu masz wms-y z bazą danych punktów osnów, ich też jest kilka kategorii, o różnej dokładności, ten pobliski z którego kiedyś korzystałem to chyba był najwyższej klasy referencyjnej, o ile pamiętam pozycję miał podaną co do milimetra, w ogóle jak pogadać z geodetami to sposób osadzania/stabilizowania/weryfikacji takim punktów (betonowy kloc odpowiednio stabilizowany w ziemi) jest dość ciekawy i skomplikowany. Takie punkty też są okresowo weryfikowane i w bazie jest info czy są wiarygodne choć nie wiem w obecnej dobie precyzyjnych GPS jak często i czy w ogóle to jest robione. Co do układów współrzędnych to w Qgis można korzystać z przeróżnych, i tych geoidalnych i płaskich "geodezyjnych" X/Y, o ile pamiętam Mobile Topographer też podawał prawidłowo w X/Y, choć tam za dużego wyboru nie ma (w samej Polsce jest kilka "pasków" współrzędnych) od zachodu do wschodu, nie pamiętam dokładnie trochę jest zabawy aby przyswoić te systemy, nie jestem na bieżąco. Gdzieś chyba w tym wątku są moje pomiary odczytów z F9P karmionego moją bazą oraz z najbliższej stacji Asgeupos, wszystkie były bardzo precyzyjne, o ile pamiętam w 2 cm praktycznie wszystko się mieściło względem rzeczywistych współrzędnych punktu osnowy z bazy Geoportalu. Qgisem Damian coś próbuje zbierać ale to trochę nieporęczny tablet z W10 do targania (androidowy qgis to chyba ciągle jakaś beta) MobileTopographer ma z kolei bardzo fajną funkcję uśredniania pomiaru, nawet w podstawowej darmowej wersji, po prostu stawiasz tyczkę a program zbiera kolejne odczyty i wylicza ich jakby środek, to jeszcze w pewnym sensie poprawia i tak bardzo dokładne odczyty z RTK a w szczególności uśrednia odczyty tyczki, to nie takie proste utrzymać ją w idealnym pionie , geodezyjne dedykowane odbiorniki mają żyroskopową kompensację przechyłów więc geodeta ma trochę łatwiej od nas Ale precyzja właściwie jest ta sama, choć oczywiście na taki pomiar nie będziesz miał papierka. Co do dokładności Geoportalu to po inwentaryzacji, jaka akurat jest u nas i pewnie w wielu innych powiatach przeprowadzana dane (niebieskie, nie te stare szare czy kiedyś czerwone linie) w geoportalu są na bieżąco aktualizowane z Powiatowych Biur Geodezyjnych, nie wiem do którego miejsca po przecinku oni wprowadzają pozycję ale jak jesienią chwilę po geodecie przeszedłem się z tyczką z F9P to na powbijanych kołkach, w stosunku do odtwarzanej granicy (niebieskiej na geoportalu) sporo pomiarów siedziało mi w 1cm. Polecam ten materiał, sam jeszcze go nie przerobiłem ale po pierwszym 1-2 rozdziałach wiem, że warto. Cena jest aktualnie ok, na tej platformie najlepsze chyba co było to 35zł/kurs: https://www.udemy.com/course/gis-od-podstaw-w-qgis-3/

Ale nadal nie widzisz odbiornika w Ucenter czy już tylko sygnałów z satelit? Warto profilaktycznie załadować w odbiorniku fabryczne ustawienia, często w konfigach odbiorników aby nie przeładowywać transmisji przy 10Hz wycina się komunikaty zawierające infa o satelitach a tym samym w Ucenter nie są pokazywane ich sygnały. Na poddaszu przez eternit podbity drewnem już jest loteria z sygnałem, jeśli masz nad sobą strop to raczej zapomnij. Odbiornik autonomicznie powinien złapać jakąś mało dokładną pozycję, najlepiej od razu zapiąć się do NTRIP poprzez Ucenter, bez korekt będzie pewnie gorszy w działaniu od gps-u w telefonie... Tak w ogóle to ten odbiornik w ogóle nie ma zaimplementowanego SBAS/DGPS gdyby ktoś szukał...

Cerea jest komercyjna, AgopenGPS społecznościowy, za co trzeba zapłacić wiadomo, co lepsze nie wiadomo... Zupełnie inne algorytmy, Cerea nie potrzebuje czujnika skrętu, ma za to droższy kontroler do silnika z enkoderem czyli defacto serwomechanizm. AgopenGPS ma jakby "bezmyślny" silnik lewo-prawo sterowany prostym arduinowym modułem a feedback właśnie z czujnika skrętu, który w ciągniku może nie mieć łatwego życia... Nie widzę tam też rozłączania przeciążeniowego, które realizuje sterownik Phidget-a w Cerea. AgopenGPS ma opcję sterowania hydrauliką, Cerea nie. Potencjalnie AgopenGPS wydaje się bardziej rozwojowy, lepiej napisany i udokumentowany, no ale to tylko soft, który się zmienia no i kwestia czego oczekujesz... Teoretycznie oba systemy mogą sterować sekcjami opryskiwacza, jednak i tu i tu to są raczej takie dodatkowe Arduinowe protezki niezbyt łatwe do wdrożenia w praktyce. No i co do softu, wsparcie w Cerea jest słabe, kontakt z autorem niby jest ale od ponad roku nie było w zasadzie aktualizacji, teraz właśnie się pojawiła a w drodze jest całkiem nowa wersja, która ma szansę dość istotnie zmienić obraz sytuacji... To tak z grubsza, być może coś istotnego pominąłem, AgopenGPS znam tylko z internetu

Dzięki za ceny, w sumie dużo się nie zmieniło względem 217€ jakie kiedyś płaciłem. Co do wyboru Windows/Android sprawa nie jest prosta. Przede wszystkim o tym ECU za wiele nie wiadomo ale chyba ogranicza ono podczepianie rozwiązań typu dodatkowe przyciski, czujniki (np podniesienia TUZ), monitor plonu, etc. Szczerze nie za bardzo mu się przyglądałem. Z drugiej strony trochę kusi bo tablet z Androidem to skądinąd fajne rozwiązanie. Przemyślałbym jeszcze kwestie licencji, ta Androidowa przypisana jest do ECU czy tabletu? W przypadku Windowsa do tabletu i to trochę problem. Niby druga w rezerwie w razie utraty urządzenia ale tablety w ciągniku to niezbyt trwała rzecz... W moim zdążyłem stłuc digitizer (50zł z Ali i sporo stresu przy wymianie ), innym razem upadł i stracił złącze zasilania USBC, teraz ma "wszczepa" bezpośrednio w aku i zewnętrzny BMS do ładowania... Także ten limit może kiedyś zaboleć, gdyby licencja była na ECU miałoby to raczej większy sens. Jeśli chodzi o tablety to używamy głównie Chuwi Hi10 i on w zasadzie jest wystarczający, tym bardziej, że z nową wersją odpada już uruchamianie dodatkowych modułów RTKlib. Poza tym czasy gdy Rtklib odwalało także całą skomplikowaną arytmetykę RTK szczęśliwie minęły już wcześniej. Najrozsądniejszy wydaje się trochę pancerniejszy model z "dużym" USB A ("Plus") ale to chyba tylko używka, do drugiego zestawu kiedyś kupiłem dość tanio Hi10 "Air", nie używałem jeszcze w pracy ale wydaje się tak samo ok. Na wrodzoną nadaktywność i ADHD Windowsa O&O ShutUp lub inny czyściciel i do całości trudno mieć jakieś zastrzeżenia.

Fajnie, fajnie, po to jest ten wątek Pewne rzeczy można by skatalogować, opisać, porobić schematy blokowe, etc. Idealnie byłoby aby powstała polska wersja językowa tej nowej Cerea300... Zachęcam tych, którzy się aktualnie wgryzają w temat i są na bieżąco przy zakupach, kompletowaniu, składaniu etc. do dzielenia się swoimi doświadczeniami. Osobiście jestem już trochę poza tematem. Zrobione, działa, poskładam do pudełek drugi zestaw na wiosenne prace i tak naprawdę czekam tylko na zmiany w sofcie usuwające pewne przypadłości obecnej wersji. Jeśli nowy algorytm/wersja będzie tak wyraźnym krokiem w przód na jaki wygląda i w aplikacji zapanuje porządek to naprawdę niewiele więcej mi potrzeba do szczęścia. Auto-zawracanie przy napędzie na kierownicę raczej nie będzie dla mnie efektywniejsze od ręcznej szybkiej nawrotki. AgopenGPS choć skądinąd jest ciekawym projektem ze sporym potencjałem raczej też z podobnych powodów (napęd) nie zrobi dla mnie rewolucji. W hydraulikę ciągnika/kombajnu raczej nie zaingeruję bo i koszty i trudne do oszacowania ryzyko. Wizualizacja sekcji opryskiwacza jest sama w sobie na tyle pomocna, że w moich warunkach automatyczne sterowanie nimi niewiele by usprawniło. Tak czy inaczej, zwłaszcza patrząc na zmiany pokazane w nowej wersji myślę, że warto w Cerea inwestować. Od technicznej strony dla samego auto-sterowania rozwiązanie niewymagające czujnika skrętu oraz tworzenia dodatkowej elektroniki, łączone praktycznie tylko kablami usb i zasilaniem jest i bardziej eleganckie i potencjalnie mniej awaryjne, jak dla mnie wygrywa, przynajmniej dopóki inne go nie przebije jakością samego sterowania

Jeśli tylko o to Ci chodziło to nie widzę powodów aby miała nie zagadać. Sądziłem jednak, że chcesz zbudować coś więcej niż zabawkę...

To nie jest RTK tylko DGPS. RTK pod Cerea Damian zbudował na Ardusimple (sąsiedni wątek). I w kontekście ceny to jest najlepsze rozwiązanie jeśli chcesz myśleć o autosterowaniu.

Technicznie BT od strony Windowsa to zwykły port COM. Ale jeśli chcesz myśleć o autosterowaniu na takim porcie musi się pojawić NMEA z wysoką precyzją a aby ją uzyskać sprowadza się to do anteny (odbiornika) RTK "karmionego" w taki czy inny sposób sygnałem z bazy (lub asgeupos, etc.). Tu masz możliwe rozwiązania: http://agopengps.gh-ortner.com/doku.php?id=gps:start Jeśli nie napiszesz co to za antena to można sobie "gdybać"... "Antena z BT" to może być np coś takiego http://racing.qstarz.com/Products/BT-Q818XT.html Tyle, że takie "anteny" były już 10 lat temu jednak ich przydatność w takich rozwiązaniach jest żadna. Choć np. na laptimery nadawały się bardzo dobrze...

Do Ardusimple można dołożyć moduł BT Xbee jeśli o to Ci chodzi. Tylko akurat w tym układzie nie za bardzo widzę sens takiego rozwiązania.