Kinematyka odwrotna

W dniu 2017-10-12 o 18:33, J.F. pisze:

Dawniej wyniki tablicowano.

W dniu 2017-10-12 o 18:33, J.F. pisze:

podrzuć pls na priv (arrmii małpa interia pl) namiar do siebie, pracuję z kolegą, który się w tym specjalizuje. Też Wrocław.

pozdr

a.

W dniu 2017-10-12 o 19:47, Miller Artur pisze:

Co na priv, co na priv. ;-) Też chcę posłuchać/poczytać.

Robert

W dniu 2017-10-12 o 19:52, Robert Wańkowski pisze:

on sie tutaj nie udziela niestety... a ja o tym pojęcia zielonego nie mam :)

a.

No to są liczone punkty pośrednie - tak często jak trzeba. Zobacz np. oprogramowanie Merlin do drukarek 3d - taka atmega644 spokojnie daje sobie radę z "deltą".

W dniu czwartek, 12 października 2017 18:33:41 UTC+2 użytkownik J.F. napisał:

Czemu wredne? Chodzi ci o optymalne, w sensie najszybsze plus utrzymanie jakichś stref no-go? Bo nieoptymalne to po prstu liczy sie delty między aktualnym usytuowaniem a docelowym i po prostu sie iteruje miedzy nimi. Ale wtedy nie ma omijania czegokolwiek czy brania pod uwage czy ruch/pozycja jest mozliwa dla zadanych stref no-go i katów.

Temat ciekawy ale nie mysle ze trudniejszy niz jakies 486 liczące to w realtime...

Użytkownik sczygiel napisał w wiadomości W dniu czwartek, 12 października 2017 18:33:41 UTC+2 użytkownik J.F. napisał:

zobacz np to

na stronie 22 dochodza do wzoru na kinematyke prosta ... i teraz rozwiaz to, tzn na podstawie zadanego wyniku znajdz dwa katy i lambde.

Tu masz jakis prostszy przypadek rozwiazany

Jesli wyliczysz pozycje silownikow koncowa i poczatkowa, i zaczniesz je rownomiernie przestawiac, to koniec ramienia osiagnie na koncu dobra pozycje, ale trajektoria ruchu jest blizej nieokreslona. A jak bym chial, zeby robot np spaw zrobil po linii prostej, a nie krzywej :-)

kiedys to zrobilem na 486, ale troche uproscilem, a 486 ma szybki procesor zmiennoprzecinkowy :-)

No i ciekaw jestem - fachowcy tez upraszczaja, czy dzis po prostu jakis Core2 daja, bo to i tak najtaniej :-)

J.

W dniu piątek, 13 października 2017 11:43:18 UTC+2 użytkownik J.F. napisał:

Trajektoria zalezy od tego jakie mamy katy na siłownikach. I rzeczywiscie mocno zalezy od przypadku ale czemu po prostu nie podzielić sobie ściezki na kawałki i po nich krótkimi krokami iterować? Wtedy spaw będzie prosty czy tam pojedzie po swojej ścieżce.

I będzie prosta. Ale tylko jak podzielimy calosc na kawałki. Tak daleko jak widze to przy katach przemieszczeń mniejszych niż 90stopni to te wzorki sie upraszczaja a proste metody daja "naturalne wyniki". Przy obszarze na poziomie 90-180 stopni to juz nieco fikuśnie. A poprowadzenie linii przez prawie cale pole robocze ramienia i blisko podstawy to już przynajmniej po 2 rozwiązania optymalne plus masa innych do rozważenia.

Ale jak nie ma stref no-go to proste algorytmy dają rade. A przynajmniej tak daleko jak widze. Jak dodamy ograniczenia na strefy plus wymaganie na stałe kąty narzędzia lub katy podążające za jakimś tam kierunkiem to już sie robi ciekawie...

Fachowcy to raczej aktualnie to po prostu robia motion capture. Ostatnio widzialem jakis soft co takie cos dawał projektować. Jakiś rodzaj CAM-a. Chwalili sie w nim ze optymalizuje. Ale nie mowili co i jak a demo bylo na zasadzie machania taca z puszkami miedzy pretem operowanym przez drugiego.

Nie zrobilo na mnie wrażenia.

A calosc to raczej byla taka "nagrywaczka" gkodu ktory potem ramie odtwarzało.

W tych wzorkach jakie podales nie ma za bardzo jak wskazać że narzedzie ma byc jakos tam pochylone albo ze mamy dowolnosc w zakresie tego czy np. elektrona ma byc 15st. odchylona w prawo czy w lewo a 30st. w tył od ściezki. A dla takiego spawania to dosyć istotne. No i aby dostać cobra pattern to jednak nawywijac tym tigiem trzeba.

Ale tak czy siak ja bym to tak na chłopski rozum wział: Posuw o kolejna sekcje beziera, obliczenie dx, dy, dz czubka elektrody, utrzymanie kąta narzędzia statycznie, i tu już z górki, obliczenie dwu katów, trzech posuwów i ich delty.

Drobny krok i wygląda ładnie. Ale nie za drobny :)

Użytkownik sczygiel napisał w wiadomości grup dyskusyjnych: snipped-for-privacy@googlegroups.com... W dniu piątek, 13 października 2017 11:43:18 UTC+2 użytkownik J.F. napisał:

I pewnie jest to jedna z metod. Tylko jak odcinki sa krotkie, a obliczenia skomplikowane, to prostszy procesor moze nie nadazyc :-)

A spaw jest dlugi i tych 90 stopni przekracza :-) W dodatku jeszcze trzeba utrzymac w miare stala predkosc posuwu przez cala linie, bo spawanie tak lubi :-)

To IMO caly czas bylo w uzyciu. Najprosciej, bo nic nie trzeba liczyc :-)

Tylko czy lepiej np ruch malarza tak zapamietac, czy na komputerze sobie spokojnie trajektorie pistoletu wymodelowac ...

Jak macierz 6x6 to jest jak. Tylko proces rozwiazywania sie wydluza :-)

J.

Marlin oczywiście, mój błąd.

No więc właśnie ja o układzie delta myślałem (i pisałem).

Drukarka jedzie jak jej nakazuje g-kod. A kto mi zabroni na ukos z góry na dół pojechać? Aż sprawdzę.

Aaa ... nie wiedzialem, ze to sie delta nazywa.

Pewnie pojedzie ... ale czy po prostej ? Mam mieszane uczucia - z jednej strony musieli zapewnic liniowosc dla osi XY, Z dodatkowo jest trywialna ... ale moze jakos zoptymalizowali..

no i jak to sprawdzic - wlaczyc extruder i niech "rejestruje" ? :-)

J.

W dniu poniedziałek, 16 października 2017 00:43:36 UTC+2 użytkownik J.F. napisał:

Tak apropos: