Grants: finished » Grant Dziekański 2012: DisCODe MDE

KB napisał:
Hej,

Po drodze do domu zastanawiałem się nad kilkoma kwestiami które według mnie warto było by poruszyć:

1) "triger'owanie" komponentu (funkcji) jego wyjściem

Implementując sterownik do kuki w orocosie trafiłem na problem zrobienia komponentu który będzie generował nowe wyjście gdy jego poprzednie wyjście zostanie odczytane przez kolejny komponent.
Rozwiązanie poprzez utworzenie portu "buffer_empty" i pisanie do niego po odczytaniu danych oczywiście działa natomiast niezbyt mi się podoba.
Stąd pytanie czy nie można by generować eventu gdy pojawi się wolne miejsce w buforze ?

2) Wiele callback'ow w jednym komponencie
Często spotykałem się z problemem tworzenia komponentów z wieloma zestawami zdarzeń wejściowych.
Np. generator_trajektorii jedno zdarzenie odpowiada za generowanie nowego położenia zadanego na wyjściu, a drugie z przetwarzaniem kolejnego otrzymanego odcinka trajektorii.
W orocos'ie niezależnie od tego które zdarzenie uruchomi komponent wołany jest updateHook co jest dosyć uciążliwe bo trzeba samemu sprawdzać co wywołało zdarzenie.
Natomiast jeśli pozwolić na utworzenie wielu metod odpowiadającym poszczególnym zdarzeniom pojawiają się pytania :
Czy uruchamiać wszystkie zdarzenia danego komponentu w jednym wątku ?
jeśli nie to jak zapewnić synchronizację dostępu do pól obiektu komponentu ?

3) Czemu nie wykorzystać do implementacji DisCODe RTT ?
Ja chętnie wykorzystał taki system do sterowania, a niestety aktualny DisCODe jest mało rt.
Według mnie zdecydowanie szybciej będzie stworzyć coś w oparciu o RTT niż rzeźbić coś znowu od podstaw.
RTT oferuje wiele elementów które można wykorzystać bez modyfikacji, dzięki czemu można by się bardziej skupić na wprowadzeniu nowej jakości a nie odkrywaniu koła na nowo.
RTT posiada znacznie szersze grono użytkowników niż obecny DisCODe co może wpłynąć na szersze wykorzystanie i naszego rozwiązania (z moich komponentów do sterowania LWR'em korzystają inne zespoły, natomiast o zainteresowaniu DisCODe nie słyszałem) (innym przykładem jest ROCK który też jest oparty na RTT)

Pozdrawiam

PT napisał:

On Thu, Sep 06, 2012 at 08:50:29PM +0200, Konrad Banachowicz wrote:

1) "triger'owanie" komponentu (funkcji) jego wyjściem

Implementując sterownik do kuki w orocosie trafiłem na problem zrobienia
komponentu który będzie generował nowe wyjście gdy jego poprzednie wyjście
zostanie odczytane przez kolejny komponent.
Rozwiązanie poprzez utworzenie portu "buffer_empty" i pisanie do niego po
odczytaniu danych oczywiście działa natomiast niezbyt mi się podoba.

Dzięki za uwagi!

Czy możesz coś więcej napisać o tym use-case'ie? Tzn. czy faktycznie tym co
potrzebowałeś było "generowanie wyjścia po tym, jak zostanie odczytane
wejście," a może chodziło o jakiś inny mechanizm wyższego poziomu, a to co
napisałeś odnosi się jedynie do jego realizacji?

Stąd pytanie czy nie można by generować eventu gdy pojawi się wolne miejsce
w buforze ?

Jako kryterium wprowadzania pojęć do metamodelu warto kierować się tym, w jaki
sposób o systemie myśli jego projektant. To co napisałeś oznaczałoby myślenie
na stosunkowo niskim poziomie i stąd moje wątpliwości.

2) Wiele callback'ow w jednym komponencie
Często spotykałem się z problemem tworzenia komponentów z wieloma zestawami
zdarzeń wejściowych.
Np. generator_trajektorii jedno zdarzenie odpowiada za generowanie nowego
położenia zadanego na wyjściu, a drugie z przetwarzaniem kolejnego
otrzymanego odcinka trajektorii.
W orocos'ie niezależnie od tego które zdarzenie uruchomi komponent wołany
jest updateHook co jest dosyć uciążliwe bo trzeba samemu sprawdzać co
wywołało zdarzenie.
Natomiast jeśli pozwolić na utworzenie wielu metod odpowiadającym
poszczególnym zdarzeniom pojawiają się pytania :
Czy uruchamiać wszystkie zdarzenia danego komponentu w jednym wątku ?
jeśli nie to jak zapewnić synchronizację dostępu do pól obiektu komponentu
?

Podążając za (moim zdaniem słuszną) motywacją Orocosa - koncepcja "zdarzenia"
służy separacji obliczeń (ang. 'computations') od innych aspektów systemu (ich
słynne "4C"...).

W szczególności jest kilka powodów, dla których nie należy mieszać obliczeń z
synchronizacją, m.in. przy takiej mieszance o wiele trudniej: (1) implementować
kod, (2) specyfikować procedury, (3) analizować i weryfikować ich poprawność.

Ze względu na powyższe argumenty zdarzenia powinny być zatem uruchamiane w
jednym wątku, a ściślej rzecz biorąc - przy wyłącznym dostępie do lokalnych
zasobów komponentu. Rozróżnienie to ma znaczenie przy kilku komponentach
przypisanych do grupy wątków - wtedy nie ma przeszkód, aby ten sam komponent
migrował w obrębie grupy. W ekstremalnym przypadku można takie migracje
ograniczać (pojęcie zbliżone do "affinity mask"), ale osobiście nie spotkałem
się jeszcze z taką potrzebą.

3) Czemu nie wykorzystać do implementacji DisCODe RTT ?
Ja chętnie wykorzystał taki system do sterowania, a niestety aktualny DisCODe
jest mało rt. Według mnie zdecydowanie szybciej będzie stworzyć coś w
oparciu o RTT niż rzeźbić coś znowu od podstaw. RTT oferuje wiele elementów
które można wykorzystać bez modyfikacji, dzięki czemu można by się bardziej
skupić na wprowadzeniu nowej jakości a nie odkrywaniu koła na nowo. RTT
posiada znacznie szersze grono użytkowników niż obecny DisCODe co może
wpłynąć na szersze wykorzystanie i naszego rozwiązania (z moich komponentów
do sterowania LWR'em korzystają inne zespoły, natomiast o zainteresowaniu
DisCODe nie słyszałem) (innym przykładem jest
ROCK<http://rock-robotics.org&gt;który też jest oparty na RTT)

Zakładając, że metamodel jest dedykowany do przetwarzania danych sensorycznych
(a z takim właśnie nastawieniem go formalizujemy), to uzasadnione wydaje się
także wykorzystanie runtime'u dedykowanego do tego samego celu.

Oczywiście pojawia się pytanie - na ile metamodel oraz runtime DisCODe są
rzeczywiście takie specyficzne i na ile są one różne od RTT? Ten temat już
kilka razy poruszałem z Tomkiem K., ale odpowiedzi nie były przejrzyste.

Mogę też odwrócić pytanie - dlaczego warto użyć RTT a nie np. SmartSOFT, który
może nie jest taki super-RT, ale też RT nie jest tutaj elementem kluczowym...
Jakie elementy runtime-u decydują o tym, że dane rozwiązanie jest dla nas
lepsze lub gorsze? Liczba użytkowników jest oczywiście istotnym kryterium, ale
przecież nie może być najważniejszym.

Z mojego punktu widzenia istotne jest przede wszystkim sformalizowanie
metamodelu oraz wytworzenie narzędzi. Takich rozwiązań w robotyce nie ma dużo,
a te istniejące wcale nie powalają swoim zaawansowaniem. Uważam zatem ten temat
za interesującą niszę. Kwestia runtime'u dla mnie osobiście jest drugorzędna,
ale pewne znaczenie ma fakt, że działamy w kontekście (finansowym) DisCODe...

Uważam, że RTT powinien być jednym z obsługiwanych runtime'ów - zaraz obok
DisCODe oraz ROS-a/ECTO. Jeżeli tylko zdążymy...

KB napisał:

W dniu 7 września 2012 00:22 użytkownik Piotr Trojanek
<piotr.trojanek@gmail.com> napisał:

On Thu, Sep 06, 2012 at 08:50:29PM +0200, Konrad Banachowicz wrote:

1) "triger'owanie" komponentu (funkcji) jego wyjściem

Implementując sterownik do kuki w orocosie trafiłem na problem zrobienia
komponentu który będzie generował nowe wyjście gdy jego poprzednie
wyjście
zostanie odczytane przez kolejny komponent.
Rozwiązanie poprzez utworzenie portu "buffer_empty" i pisanie do niego
po
odczytaniu danych oczywiście działa natomiast niezbyt mi się podoba.

Dzięki za uwagi!

Czy możesz coś więcej napisać o tym use-case'ie? Tzn. czy faktycznie tym
co
potrzebowałeś było "generowanie wyjścia po tym, jak zostanie odczytane
wejście," a może chodziło o jakiś inny mechanizm wyższego poziomu, a to co
napisałeś odnosi się jedynie do jego realizacji?

Mój problem wygląda tak :
mam dwa komponenty sterownik robota który ma wejście zadanej pozycji i
komponent generatora trajektorii który ma wyjście pozycji.
sterownik robota potrzebuje mieć nowe dane co cykl komunikacji z robotem.
chciałbym aby komponent generatora trajektorii uruchamiał się gdy
sterownik robota odczyta dane z bufora.
w ten sposób będzie zawsze miał nowe dane w buforze.
W tym miejscu zadał bym pytanie jaka część DisCODe jest dedykowana
przetwarzaniu danych sensorycznych ?

Oczywiście pojawia się pytanie - na ile metamodel oraz runtime DisCODe są
rzeczywiście takie specyficzne i na ile są one różne od RTT? Ten temat już
kilka razy poruszałem z Tomkiem K., ale odpowiedzi nie były przejrzyste.

Z mojej wiedzy wynika że DisCODe implementuje pewien podzbiór funkcji
oferowanych przez RTT 1.x.x, może się mylę ale nie zauważyłem żadnej
"unikalnej" własności discode względem RTT.

Mogę też odwrócić pytanie - dlaczego warto użyć RTT a nie np. SmartSOFT,
który
może nie jest taki super-RT, ale też RT nie jest tutaj elementem
kluczowym...

Nawet ograniczając się do systemów wizyjnych RT staje się czasami
koniecznością, np. DLR system wizyjny do łapania lecącej piłeczki
realizował nie bez powodu na QNX (gdy dla innych zadań implementacja
była na Linux'ie).

Jakie elementy runtime-u decydują o tym, że dane rozwiązanie jest dla nas
lepsze lub gorsze? Liczba użytkowników jest oczywiście istotnym kryterium,
ale
przecież nie może być najważniejszym.

Ja nie upieram się przy RTT, natomiast jako że DisCODe jest bardzo
podobny do RTT oraz tego że korzystam z orocosa (w którym niema
narzędzi do projektowania systemu, przez co "ogarnięcie" sekwencji
wywoływania komponentów staje się dosyć czasochłonnym zadaniem) do
sterowania manipulatorem, wykorzystanie RTT w celu stworzenia
ogólniejszego rozwiązania wydaję się naturalne.

Z mojego punktu widzenia istotne jest przede wszystkim sformalizowanie
metamodelu oraz wytworzenie narzędzi. Takich rozwiązań w robotyce nie ma
dużo,

Gdyby było ich dużo podobnie, tworzenie nowego podobnie jak
implementacja "własnego RTT" było by kontrowersyjnym posunięciem.

a te istniejące wcale nie powalają swoim zaawansowaniem. Uważam zatem ten
temat
za interesującą niszę. Kwestia runtime'u dla mnie osobiście jest
drugorzędna,

Dla mnie w sytuacji w której mam ~100us na wysłanie nowego rozkazu (i
spóźnienie się oznacza błąd systemu) to właśnie runtime man najwyższy
priorytet, a nie to który system jest prostszy w obsłudze czy posiada
lepsze narzędzia do projektowania.

TK napisał:

Ja tylko dodam krótki ogólny komentarz. Cieżko mi dyskutować nad wyższością DisCODe nad RTT - bo wiem, że RTT jest rozwijane dłużej, ma więcej użytkowników, i ma mechanizmy RT o jakich my w DisCODe nawet nie myślimy. No więc przyjmuję z pokorą, że z założenia "lepsze". Ecto z kolei ma jakieś inne swoje fajne ficzery, SmartSOFT ma supermechanizmy generacji kodu, itp. itd.

Natomiast ja podchodzę do DisCODe jako do "runtime'u" naszych pomysłów. Projekt ten ewoluuje i wierzę, że daje to "nam" unikalne doświadczenie. Wczoraj opracowaliśmy kierunek zmian, który wynika wprost z przemyśleń z naszych doktoratów. - chodzi mi o predykaty odpalania "funkcji przejścia", tudzież komponentów. Coś tak lekkiego jak DisCODe umożliwia nam łatwe zweryfikowanie tej teorii w praktyce praktycznie "od ręki", nie wyobrażam sobie, żeby to łatwo wbić np. w ROS - ale tutaj może wychodzi moja ignorancja, bo po prostu nie znam ROSa na tyle dobrze...

Z drugiej strony kierunkiem jest MDE, w który chcemy wejść jednak bardziej niż mniej - w 200% popieram PT i uważam, że jest to kierunek na przyszłość. I znowu, na czym mamy zebrać praktyczne doświadczenie? Na ROSie, który jest megaklocem? Wydaje mi się, że w pierwszym kroku jednak powinniśmy wziąć na warsztat DisCODe - bo jest lekkie i jednak w 100% nasze, łatwo możemy operacować metamodel (co w sumie wczoraj prawie ogarnęliśmy) i narzędzia do generacji kodu. A jak to zrobimy, to czemu nie zrobić tego dla RTT - przecież to początek naszej "zabawy" z tym podejściem? Zresztą, mając takie doświadczenie PT będzie mógł walić do Bruyninckxa na Postdoka z gotową propozycją prac i oczywistym dowodem, że jest kompetentny w tym temacie (szczególnie jak podeprzemy to jakąś publikacją)...

Podsumowując, czerpmy jak najwięcej z innych, omawiajmy każdy use-case, który jest problematyczny, ciekawy, ważki i może wnieść coś nowego. Ale olejmy natenczas dyskusję na temat czemu DisCODe, a czemu nie YARP, Orca, URBI, Player, ROS, ECTO, ORoCoS, ViSP, SmartSOFT czy inny MRROC++, aaaaajt ;)

Pozdrawiam,
Rysiek

KB napisał:

Według mnie DisCODe jest właśnie zbyt lekki aby zweryfikować słuszność
stosowania MDE.
Potrzeba (zysk z) stosowania MDE pojawia się dopiero przy pracy z
odpowiednio złożonymi systemami.
Czy w discode mamy przykłady takich systemów ?
Czy realizowane przez nas systemy wizyjne mają odpowiednio dużą
złożoność aby wykazać skalowalność proponowanego podejścia ?

PT napisał:

On Fri, Sep 07, 2012 at 09:21:33AM +0200, Konrad Banachowicz wrote:

Mój problem wygląda tak : mam dwa komponenty sterownik robota który ma
wejście zadanej pozycji i komponent generatora trajektorii który ma wyjście
pozycji. sterownik robota potrzebuje mieć nowe dane co cykl komunikacji z
robotem. chciałbym aby komponent generatora trajektorii uruchamiał się gdy
sterownik robota odczyta dane z bufora. w ten sposób będzie zawsze miał nowe
dane w buforze.

Dzięki, rozumiem. Faktycznie jest to dosyć powszechny problem - pojawia się
przecież na linii EDP-ECP (ale tam jest rozwiązany paskudnie) i kilka razy
wyskakiwał na liście mejlingowej Orocosa.

W tym miejscu zadał bym pytanie jaka część DisCODe jest dedykowana
przetwarzaniu danych sensorycznych ?

Sam mam podobne odczucia, ale chyba jest parę unikalnych elementów, jak np.
gotowe komponenty do akwizycji/przetwarzania obrazu oraz stosunkowo dobrze
wspierany interfejs komponentów z użytkownikiem. Przy czym w samym rdzeniu moim
zdaniem nie rzeczy specyficznych.

Mogę też odwrócić pytanie - dlaczego warto użyć RTT a nie np. SmartSOFT,
który może nie jest taki super-RT, ale też RT nie jest tutaj elementem
kluczowym...

Nawet ograniczając się do systemów wizyjnych RT staje się czasami
koniecznością, np. DLR system wizyjny do łapania lecącej piłeczki
realizował nie bez powodu na QNX (gdy dla innych zadań implementacja
była na Linux'ie).

Zgadzam się. Pod tym kątem RTT jest zdecydowanie lepsze, ponieważ z tego co się
orientuję, to umożliwia także uruchamianie mieszanych aplikacji, tzn.
RT/non-RT.

Dla mnie w sytuacji w której mam ~100us na wysłanie nowego rozkazu (i
spóźnienie się oznacza błąd systemu) to właśnie runtime ma najwyższy
priorytet, a nie to który system jest prostszy w obsłudze czy posiada lepsze
narzędzia do projektowania.

Mnie w tym temacie interesuje przede wszystkim semantyka metamodelu, tzn. czy
może on być zaimplementowany w sposób, który gwarantuje deterministyczne (oraz
efektywne) działanie. Na jakiej platformie zostanie to zrealizowane jest
oczywiście bardzo ważne z punktu widzenia zastosowań praktycznych, ale dla mnie
jest to raczej sprawa drugorzędna.

W swojej pracy rozwiązuję to zagadnienie w ten sposób, że z metamodelu generuję
kod zgodny z profilem Ravenscar języka Ada: "The Ravenscar Profile is a subset
of the tasking model, restricted to meet the real-time community requirements
for determinism, schedulability analysis and memory-boundedness, as well as
being suitable for mapping to a small and efficient run-time system that
supports task synchronization and communication, and which could be certifiable
to the highest integrity levels."

Ograniczenia profilu Ravenscar są znacznie bardziej restrykcyjne niż to co
oferuje Orocos. W ten sposób upewniłem się, że do metamodelu nie przemyciłem
nic, co uniemożliwiałoby implementację RT (a jednocześnie takie mapowanie
metamodelu na kod determinuje jeden z aspektów semantyki języka specyfikacji).

PT napisał:

On Fri, Sep 07, 2012 at 09:53:56AM +0200, Tomasz Kornuta wrote:

[...] Coś tak lekkiego jak DisCODe umożliwia nam łatwe zweryfikowanie tej
teorii w praktyce praktycznie "od ręki", nie wyobrażam sobie, żeby to łatwo
wbić np. w ROS - ale tutaj może wychodzi moja ignorancja, bo po prostu nie
znam ROSa na tyle dobrze...

Moim zdaniem wbicie omawianej wczoraj semantyki w jakikolwiek z popularnych
runtime'ów nie nastręcza zasadniczych trudności. No może z wyjątkiem MRROC++,
który pod tym kątem jest zupełnie beznadziejny...

TK napisał:

W swojej pracy rozwiązuję to zagadnienie w ten sposób, że z metamodelu generuję
    kod zgodny z profilem Ravenscar języka Ada: "The Ravenscar Profile is a subset
    of the tasking model, restricted to meet the real-time community requirements
    for determinism, schedulability analysis and memory-boundedness, as well as
    being suitable for mapping to a small and efficient run-time system that
    supports task synchronization and communication, and which could be certifiable
    to the highest integrity levels."

Ograniczenia profilu Ravenscar są znacznie bardziej restrykcyjne niż to co
    oferuje Orocos. W ten sposób upewniłem się, że do metamodelu nie przemyciłem
    nic, co uniemożliwiałoby implementację RT (a jednocześnie takie mapowanie
    metamodelu na kod determinuje jeden z aspektów semantyki języka specyfikacji).

Hmmm, ciekawe podejście. Czyli przez otrzymanie "poprawnego" kodu wynikowego stawiasz tezę/wnioskujesz, że jest "poprawny" model?

PT napisał:

On Fri, Sep 07, 2012 at 04:16:23PM +0200, Tomasz Kornuta wrote:

Hmmm, ciekawe podejście. Czyli przez otrzymanie "poprawnego" kodu wynikowego
stawiasz tezę/wnioskujesz, że jest "poprawny" model?

Trudno powiedzieć co to jest "poprawny" kod wynikowy... Dlatego wolę mówić, że
układ sterowania opisany danym modelem jest możliwy do zaimplementowania w
sposób (najogólniej ujmując) zgodny z wymaganiami stawianymi systemom RT. W
praktyce sprowadza się to do determinizmu działania.