Dron zamiast wyciągarki. Model

[Jarek]

No to jeszcze raz to samo, ale w pionie

Zgadza się Ogarnijmy najpierw poziom

[prokopcio]

Ależ to banalne - dron będzie miał kamerę i analizował w czasie rzeczywistym ruchy paralotniarza i paralotni, może również rozpoznawać sytuacje niebezpieczne.
Zbyszku - oczywiście w wszystkich kierunkach, nie tylko w poziomie.
Jarku zerknij proszę na pierwszy wpis tego tematu, tam wszytko opisałem.

[uriuk]

Dla ukladow poruszajacych sie w powietrzu nie ma wiatru, tylko ziemia sie gdzies przesuwa. Nalezy wiec ta ziemie w rozwazaniach pominac. Nie wiem, do czego ci ona potrzebna.

[Jarek]

Dla ukladow poruszajacych sie w powietrzu nie ma wiatru, tylko ziemia sie gdzies przesuwa. Nalezy wiec ta ziemie w rozwazaniach pominac. Nie wiem, do czego ci ona potrzebna.

Są zmiany wiatru (np. pochodzące od termiki). Być może trzeba będzie te zmiany jakoś uwzględnić w sterowaniu...

[uriuk]

Zmiany wiatru oznaczaja wylacznie, ze ziemia przesuwa sie na dole w sposob zmienny. Ty kiedys latales?

[prokopcio]

Jarku, wiem, że w tym temacie jest postów ponad pół tysiąca ale tak jak wspomniałem w pierwszym (na pierwszej stronie) masz wszystko wyjaśnione.
A później jeszcze razy wiele klepane, że to ma być na plecach jak napęd PPG - gdzie tam miejsce na oprogramowanie uwzględniające kierunek wiatru i temu podobne rzeczy .... ?

Nawet nie chcę sobie wyobrażać ani analizować drona ciągnącego linę o czym już wspominałem wile razy.
Do tego nikt by mnie nie namówił nawet ciacholot.

[AndRand]

Nawet nie chcę sobie wyobrażać ani analizować drona ciągnącego linę o czym już wspominałem wile razy.
Do tego nikt by mnie nie namówił nawet ciacholot.

Trzeba zrobić drona reagującego na komendy: wio! hejta! wiśta! odsie! ksobie!

Można pogadać z kimś z Islandii - tam używają tych komend w systemach:
„Vista”, czyli „OK/Zatwierdź”, i „Hætta við” czyli „Anuluj”

[prokopcio]

Złe informacje:
Symulacje komputerowe wykazują, że na powrót drona potrzeba znacznie więcej czasu niż sądziłem
powrót (z lądowaniem) z odległości jednego kilometra i wysokości 300m zajmie PGDronowi około 3 minut.
zakładałem połowę tego czasu na1 km.
Zrzut dalej niż 1,5 - 2km od miejsca lądowania będzie się wiązało z potrzebą zabrania większej ilości energii niż wstępnie przewidywałem.

[prokopcio]

Po komplecie testów..., dziś dość porywiście i wietrznie na model ale wszystkie próby ok
Jestem mega zadowolony z testów. Nagrywać z daleka telefonem nadal nie potrafimy

[Jarek]

Jarku, wiem, że w tym temacie jest postów ponad pół tysiąca ale tak jak wspomniałem w pierwszym (na pierwszej stronie) masz wszystko wyjaśnione.
A później jeszcze razy wiele klepane, że to ma być na plecach jak napęd PPG - gdzie tam miejsce na oprogramowanie uwzględniające kierunek wiatru i temu podobne rzeczy .... ?

Nawet nie chcę sobie wyobrażać ani analizować drona ciągnącego linę o czym już wspominałem wile razy.
Do tego nikt by mnie nie namówił nawet ciacholot.

A to przegapiłem/zapomniałem, że pomysł wersji holowanej upadł. Jak tak, to nie ma tematu

[JarekPG]

Po komplecie testów...Jestem mega zadowolony z testów.

Czyli mamy rozumieć, że zabierasz się za pełnowymiarowy napęd ?

[prokopcio]

TAK

[prokopcio]

Jeszcze dla ciekawskich dorzucę filmik symulowanego zrzutu (wyłączenie silników podczas lotu drona) + rejestr lotu (wysokości).
Na filmiku z pokładu jakoś nie widać tak jak z zewnątrz utraty wysokości
wykres z tego konkretnego przykładu.

cs.png (26.76 KiB) Przejrzano 6554 razy

[prokopcio]

Niesamowite, dzisiejsza technologia dronowa pozwala analizować wszystko w pięknej formie
Dorzucając do tego track glajciarza wyjdzie piękny szkic do analizy,
Przykład z poprzedniego filmiku :

[JarekPG]

Niesamowite, dzisiejsza technologia ....

Wszystko fajne ale czy nie za dużo tej technologii jak na napęd PPG ?
Ciężko nazwać to prostym ( czyt. niezawodnym i tanim ).
ps. widzę na wszystkich ostatnich testach, że jest jedno wspólne miejsce lądowania, nie koniecznie startowe Super.

[Dronek]

Nie rób tego! Z doświadczenia wiem, że drony to bardzo niebezpieczne narzędzia i z podwórka przykładów mogę podać co najmnjej kilka, gdzie małe drony 0,5kg wyrządziły straty w ludziach i mieniu. Jestem mocno z tą branżą związany.
Taka kosiarka 20kg to jest zabójstwo i prędzej niż późnjej zrobi komuś kuku.

Drony spadają profesjonalistom podczas najzwyklejszego lotu lub lecą nie tam gdzie operator chce, bez najmniejszej kontroli.

Brak Ci wyobraźni i z tego co o zgrozo czytam jakiegokolwiek doświadczenia i chcesz zrzucić swobodnie kloca swobodnie z kilkuset metrów i ufać tylko i wyłącznie automatyce, że wszystko będzie tak jak sobie wymarzyłeś.

Zejdź na ziemię lepiej...

[prokopcio]

....

- Jasiu!, przecież pająk nie je biedronek!
- Jakich Dronek mamusiu ?

sorki ale nie mogłem się powstrzymać
a na poważnie Bardzo interesują mnie konkrety i szczegóły tych zdarzeń.
Nie ogólniki, podaj przyczyny, konsekwencje dla mnie nieistotne bo są mocno losowe.

[SP8EBC]

Ja też chciałem się nieco pobawić w adwokata diabła ale jakoś brakowało mi sił i motywacji, żeby przekopać się przez cały wątek. Do tej pory mi się nie udało ale stanę jednak po stronie 'Dronka'. Nie zrozum mnie źle, ja nie mam na myśli podcinać Ci skrzydeł czy mówić, że to wszystko jest bez sensu. Trzeba jednak rozróżnić zabawy i eksperymenty od przytroczenia kawałka elektroniki do żywego pilota. To już przestaje być zabawka a zaczyna być system Safety Critical

Tak po krótce to czego mi tu przede wszystkim brakuje to procesu. Nie mówię żeby zaprzęgać tutaj od razu AutoSPICE (http://www.automotivespice.com/fileadmi ... PAM_30.pdf) i VDA a to tworzenia oprogramowania używać wyłącznie narzędzi certyfikowanych wedługi ISO 26262. Problemem jest jednak to, że w tym rozmyślaniach brakuje podstawowych rzeczy jak:

1. Wymagań na poziomie biznesowym i systemowych: Co chcemy w ogóle osiągnąć
2. Jakiejkolwiek architektury systemu/oprogramowania.
3. Dokumentacji.
4. Jakiejkolwiek analizy FMEA, Nawet najprostszej aby zidentyfikować możliwe 'Single point of failure' a ogólnie zdefiniowanie co może zawieźdź i jakie będą tego skutku.
5. Definicji testów jednostkowych, integracyjnych i systemowych wraz z procesem ich zarządzania, automatyzacji i archiwizacji.

Bez tego obawiam się, że w docelowym wykonaniu strach będzie do tego podchodzić a co dopiero brać to na plecy. Dron to bardzo skomplikowane urządzenie, które z jednej strony jest wyposażone w dużą ilość zakłócającej elektroniki jak mostki H i 3F dużej mocy, silniki indukcyjne/synchroniczne/BLDC itp a z drugiej strony jego nawigacja opiera się na czujnikach bardzo na wrażliwych na wszystko to co generuje to pierwsze.

Ja zacząłem karierę w SW/HW Dev od stacji pogodowych i do pewnego stopnia zjadłem na tym zęby. Wiele, naprawdę bardzo wiele czasu zajęło mi doprowadzenie tego wszystkiego do ładu i tak naprawdę od niedawna całośc nadaje się do komercjalizacji. Jeszcze kilka miesięcy temu poprawiałem bugi, które powstały kilka lat temu (!!!) a nie zostały wykryte właśnie przez brak należytego testowania albo ujawniały się w bardzo specyficznych okolicznościach. Pominę tutaj same błędy sprzętowe, sprzężenia, przesłuchy czy po prostu błędy projektowe PCB poprawione kynarem bo to osobny temat. Próbowałem swego czasu wgryźć się w kod źródłowy twojego softu do wyciągarki ale szczerze poległem. Nie znam języka Assemblera AVR i nie miałem raczej czasu żeby się temu przyglądać ale wystarczy, jeden nieobsłużony wyjątek i pozamiatane.

[Gość]

Ja też chciałem się nieco pobawić w adwokata diabła ale jakoś brakowało mi sił i motywacji, żeby przekopać się przez cały wątek. Do tej pory mi się nie udało ale stanę jednak po stronie 'Dronka'. Nie zrozum mnie źle, ja nie mam na myśli podcinać Ci skrzydeł czy mówić, że to wszystko jest bez sensu. Trzeba jednak rozróżnić zabawy i eksperymenty od przytroczenia kawałka elektroniki do żywego pilota. To już przestaje być zabawka a zaczyna być system Safety Critical

Tak po krótce to czego mi tu przede wszystkim brakuje to procesu. Nie mówię żeby zaprzęgać tutaj od razu AutoSPICE (http://www.automotivespice.com/fileadmi ... PAM_30.pdf) i VDA a to tworzenia oprogramowania używać wyłącznie narzędzi certyfikowanych wedługi ISO 26262. Problemem jest jednak to, że w tym rozmyślaniach brakuje podstawowych rzeczy jak:

1. Wymagań na poziomie biznesowym i systemowych: Co chcemy w ogóle osiągnąć
2. Jakiejkolwiek architektury systemu/oprogramowania.
3. Dokumentacji.
4. Jakiejkolwiek analizy FMEA, Nawet najprostszej aby zidentyfikować możliwe 'Single point of failure' a ogólnie zdefiniowanie co może zawieźdź i jakie będą tego skutku.
5. Definicji testów jednostkowych, integracyjnych i systemowych wraz z procesem ich zarządzania, automatyzacji i archiwizacji.

Bez tego obawiam się, że w docelowym wykonaniu strach będzie do tego podchodzić a co dopiero brać to na plecy. Dron to bardzo skomplikowane urządzenie, które z jednej strony jest wyposażone w dużą ilość zakłócającej elektroniki jak mostki H i 3F dużej mocy, silniki indukcyjne/synchroniczne/BLDC itp a z drugiej strony jego nawigacja opiera się na czujnikach bardzo na wrażliwych na wszystko to co generuje to pierwsze.

Ja zacząłem karierę w SW/HW Dev od stacji pogodowych i do pewnego stopnia zjadłem na tym zęby. Wiele, naprawdę bardzo wiele czasu zajęło mi doprowadzenie tego wszystkiego do ładu i tak naprawdę od niedawna całośc nadaje się do komercjalizacji. Jeszcze kilka miesięcy temu poprawiałem bugi, które powstały kilka lat temu (!!!) a nie zostały wykryte właśnie przez brak należytego testowania albo ujawniały się w bardzo specyficznych okolicznościach. Pominę tutaj same błędy sprzętowe, sprzężenia, przesłuchy czy po prostu błędy projektowe PCB poprawione kynarem bo to osobny temat. Próbowałem swego czasu wgryźć się w kod źródłowy twojego softu do wyciągarki ale szczerze poległem. Nie znam języka Assemblera AVR i nie miałem raczej czasu żeby się temu przyglądać ale wystarczy, jeden nieobsłużony wyjątek i pozamiatane.

Pozdrowienia/Kind regards,
*Mateusz Lubecki*

Jak by działało jak Twoje stacje pogodowe to też bym się bał

[Andrzejt]

Ja też chciałem się nieco pobawić w adwokata diabła ale jakoś brakowało mi sił i motywacji, żeby przekopać się przez cały wątek. Do tej pory mi się nie udało ale stanę jednak po stronie 'Dronka'. Nie zrozum mnie źle, ja nie mam na myśli podcinać Ci skrzydeł czy mówić, że to wszystko jest bez sensu. Trzeba jednak rozróżnić zabawy i eksperymenty od przytroczenia kawałka elektroniki do żywego pilota. To już przestaje być zabawka a zaczyna być system Safety Critical

Tak po krótce to czego mi tu przede wszystkim brakuje to procesu. Nie mówię żeby zaprzęgać tutaj od razu AutoSPICE (http://www.automotivespice.com/fileadmi ... PAM_30.pdf) i VDA a to tworzenia oprogramowania używać wyłącznie narzędzi certyfikowanych wedługi ISO 26262. Problemem jest jednak to, że w tym rozmyślaniach brakuje podstawowych rzeczy jak:

1. Wymagań na poziomie biznesowym i systemowych: Co chcemy w ogóle osiągnąć
2. Jakiejkolwiek architektury systemu/oprogramowania.
3. Dokumentacji.
4. Jakiejkolwiek analizy FMEA, Nawet najprostszej aby zidentyfikować możliwe 'Single point of failure' a ogólnie zdefiniowanie co może zawieźdź i jakie będą tego skutku.
5. Definicji testów jednostkowych, integracyjnych i systemowych wraz z procesem ich zarządzania, automatyzacji i archiwizacji.

Bez tego obawiam się, że w docelowym wykonaniu strach będzie do tego podchodzić a co dopiero brać to na plecy. Dron to bardzo skomplikowane urządzenie, które z jednej strony jest wyposażone w dużą ilość zakłócającej elektroniki jak mostki H i 3F dużej mocy, silniki indukcyjne/synchroniczne/BLDC itp a z drugiej strony jego nawigacja opiera się na czujnikach bardzo na wrażliwych na wszystko to co generuje to pierwsze.

Ja zacząłem karierę w SW/HW Dev od stacji pogodowych i do pewnego stopnia zjadłem na tym zęby. Wiele, naprawdę bardzo wiele czasu zajęło mi doprowadzenie tego wszystkiego do ładu i tak naprawdę od niedawna całośc nadaje się do komercjalizacji. Jeszcze kilka miesięcy temu poprawiałem bugi, które powstały kilka lat temu (!!!) a nie zostały wykryte właśnie przez brak należytego testowania albo ujawniały się w bardzo specyficznych okolicznościach. Pominę tutaj same błędy sprzętowe, sprzężenia, przesłuchy czy po prostu błędy projektowe PCB poprawione kynarem bo to osobny temat. Próbowałem swego czasu wgryźć się w kod źródłowy twojego softu do wyciągarki ale szczerze poległem. Nie znam języka Assemblera AVR i nie miałem raczej czasu żeby się temu przyglądać ale wystarczy, jeden nieobsłużony wyjątek i pozamiatane.

Pozdrowienia/Kind regards,
*Mateusz Lubecki*

Jak by działało jak Twoje stacje pogodowe to też bym się bał