PIOTR CZEKALSKI

Informacje dla studentów piszących prace inżynierskie i magisterskie

Witaj dyplomancie!

Jeśli trafiłeś tutaj, to najprzypuszczalniej znaczy, że jestem Twoim promotorem. Nadrzędna reguła mówi, że musisz się obronić w terminie. Jak to zrobić względnie szybko i bezboleśnie, a jednocześnie tworząc coś wartościowego, co potencjalnie potem możesz skomercjalizować lub przynajmniej czym będziesz mógł się pochwalić przed pracodawcą/rodziną/znajomymi/kumplami/w sieci? To proste - przede wszystkim liczy się systematyczna praca oraz myślenie, które wierz mi - nie boli. To co różni Cię od przeciętnego Kowalskiego, to te 10-20cm pomiędzy uszami, które odziedziczyłeś po rodzicach i najwyraźniej dobrze wykorzystujesz, bo jesteś studentem AEiI, a zatem należysz do elity.

Ponieważ wielokrotnie jestem pytany, jak napisać pracę dyplomową inżynierską czy magisterską i jak powinna ona wyglądać, przytaczam kilka dobrych reguł i wskazówek, które prezentują moje subiektywne spojrzenie, poparte wieloletnim doświaczeniem w tym temacie.
Nie gwarantuje ono co prawda braku uwag ze strony recenzentów, ale taka ich rola ;-).
Proszę również pamiętać, że każda praca jest inna, unikalna i niektóre z n/w wskazówek mogą się nie nadawać do konkretnego zagadnienia - należy je stosować z zachowaniem zdrowego rozsądku.
Na początek narażając się gronu akademickiemu podaję listę edytorów tekstów w kolejności wg moich subiektywnych wag:

  • Microsoft Word (szczególnie w starych wersjach, np. 2000, XP, 2003, a więc takiech, które nie usiłują myśleć za piszącego), uwaga - Word w wersji On-Line z reguły jest zbyt ograniczony w celu stworzenia sensownie wyglądającej pracy, zatem wynalazki typu MS Office-online, czy Google docs, proszę sobie na razie jeszcze odpuścić (stan na czerwiec 2015),
  • Open Office / Libre Office Write - naturalny wybór, gdy praca jest budowana w środowisku Linux oraz gdy nie posiadamy komercyjnej wersji MS Word,
  • LaTEX wraz z edytorem, np. WinEdt, TexStudio, etc. - świetny wybór, ale wymagający względem piszącego - wersja dla prawdziwych Kozaków ;-).

Dla osób piszących w języku angielskim zalecam zastosowanie narzędzia sprawdzającego nie tylko pisownię, ale również gramatykę języka, np. darmowy Ginger.

Projekty inżynierskie

Praca - projekt - składa się z dwóch, nierozerwalnych części, z których jedna dotyczy części sprzętowej / programowej (a nieraz jednej i drugiej), a druga części opisowej (potocznie zwanej "książką".
Po ustaleniu z promotorem zaresu pracy oraz tematu konieczne jest zawarcie powiązania między dyplomantem i promotorem w systemie PD. W przypadku, gdy student przychodzi do promotora ze swoim tematem i promotor decyduje się go przyjąć, student odpowiada za poprawne wprowadzenie w systemie PD wszystkich wymaganych informacji, następnie informuje promotora mailowo o gotowości dokumentu, wysyłając jednocześnie numer swojego indeksu (jest to jedyny, pewny sposób odnalezienia opisu pracy dyplomowej w PD).
W większości przypadków najpierw realizowana jest praca empiryczna (sprzęt, oprogramowanie, eksperymenty i doświadczenia) później powstaje opis - w niektórych przypadkach można te procesy zrównoleglić.
Dyplomant prezentuje osobiście empiryczną część pracy (sprzęt, oprogramowanie) promotorowi. I robi to w czasie, który pozwala na względnie bezstresową ocenę realizacji (uwaga - z założenia nie poddaję się szantażowi w stylu: błagam, wszystko musi być gotowe na jutro, bo skreślą mnie z listy studentów).
Przed rozpoczęciem pracy nad częścią opisową obowiązkowe jest ustalenie konspektu pracy z promotorem.
O ile nie ustalono inaczej, komunikacja odbywa się w następującej formie: dyplomant wysyła wersję elektronicznie (obowiązkowo w formacie PDF), promotor (ja) odsyła poprawki w postaci zaznaczonych uwag za pomocą narzędzia Microsoft One Note (w wersji on-line). W związku z tym proszę zawczasu umieszczać na stronie tytułowej adres email do korespondencji (powiadomień). Proszę mieć na uwadze, że One Note on-line wykorzystuje chmurę Microsoft One Drive. To znaczy, że synchronizacja dużych plików graficznych (a takimi de facto są uwagi do pracy) może trwać nawet do 24h.
Uwaga - promotor ocenia część merytoryczną pracy. Jakkolwiek mam w zwyczaju wskazywać błędy ortograficzne, stylistyczne i interpunkcyjne, zadbanie o poprawność językową pracy spoczywa na dyplomancie. Mając na uwadze dotychczasowe doświadczenie lojalnie informuję, że w ekstremalnych przypadkach będę odmawiał korekty pracy do czasu, gdy jej styl, ortografia i interpunkcją zostaną doprowadzone co najmniej do poziomu ostatniej klasy gimnazjum.

    Uwagi praktyczne dot. formy części opisowej:
  • Spodziewana objętość pracy wynosi około 35 stron (stan na dzień 9 stycznia 2013). Nie oznacza to jednak, że nie może ich być więcej lub nieznacznie mniej - proszę kierować się bieżącymi zasadami i statystyką.
  • Najważniejsza część to merytoryka pracy, niemniej jednak praca powinna być sprawdzona pod względem ortograficznym, stylistycznym i interpunkcyjnym. Zadaniem promotora nie jest korekta językowa tylko merytoryczna - prace napisane językiem niechlujnym bez dbałości o gramatykę, ortografię i interpunkcję będą zwracane do autora bez poprawy części merytorycznej.
  • Dyplomanci studiujący na Makrokierunku piszą prace dyplomowe w języku angielskim.
  • Tytuł pracy musi być zgodny z tytułem uzgodnionym z promotorem i znajdującym się w systemie PD.
  • Studenci dostarczają promotorowi wydrukowany egzemplarz pracy do korekty. Możliwe są inne rozwiązania, w zależności od indywidualnych ustaleń.
  • Od roku 2014 stosuję komunikację elektroniczą, opartą o poprawki udostępniane za pomocą narzędzia Microsoft OneNote w trybie on-line. Tutaj istnieją dwie możliwości - albo student udostępnia swoją pracę do oceny w OneNote, albo (co wolę) wysyła PDF, który następnie ja wstawiam do OneNote. Kolejne wersje są umieszczane w kolejnych zakładkach, opisanych datą udostępnienia / rozpoczęcia prac nad wersją przez promotora. Sugeruję zawczasu rejestrację konta w systemie Microsoft Live i posługiwanie się adresem mailowym przypisanym do tego konta.
  • Praca musi być zakończona i przedstawiona do wstępnej oceny przez promotora nie później niż na 2 tygodnie przed terminem składania prac. Proszę nie zakładać, że promotor nie ma nic innego do roboty na dzień przed terminem składania prac - mam na głowie rodzinę, dziecko oraz inne projekty uczelniane, zatem oczekiwanie, że praca wysłana o godzinie 22:30 będzie sprawdzona na rano jest nieporozumieniem. Konsekwencje postawienia promotora pod ścianą na zasadzie - "jutro muszę to oddać" - ponoszą dyplomanci.

    Zawartość pracy i style:
  • Strona tytułowa pracy jest sformalizowana - proszę stosować obowiązujący szablon, dostarczany przez dziekanat.
  • Język, którym pisana jest praca powinien być formalny, jednolity w całej pracy, najlepiej w trybie bezosobowym, bez kolokwializmów.
  • Krój czcionki powinien być jednorodny w ramach całej pracy (za wyjątkiem sytuacji specjalnych, patrz poniżej). Tak więc jeśli treść jest pisana czcionką szeryfową (np. Times), również taką czcionką powinny być pisane nagłówki, przypisy, spisy, etc.
  • Podstawowym schematem kolorowym jest czarny tekst na białym tle - należy unikać krzykliwych kolorów, choć wskazane jest umieszczanie ilustracji kolorowych. Tekst w pierwszej kolejności powinien być wyróżniany poprzez pogrubienie, kursywę, dopiero potem kolorami (nie dotyczy kodu).
  • W przypadku użycia kolorów należy stosować kolorystykę o względnie średnim natężeniu koloru, który nie będzie krzykliwy, a z drugiej strony będzie jeszcze rozróżnialny - należy pamiętać, że dokument na ekranie wygląda najczęściej nieco inaczej niż dokument na wydruku nawet mimo kalibracji urządzeń i stosowania profili ICM.
  • Kod występujący w treści oraz fragmenty kodu znajdujące się w pracy powinny być wyróżnione czcionką proporcjonalną np. Courier.
  • Wymieniane w tekście elementy szczególne, takie jak np. elementy interfejsu użytkownika powinny być wyróżnione w szczególny sposób, jednolicie w całym tekście, np. poprzez pogrubienie lub kursywą.
  • Dokument obowiązkowo musi zawierać stopkę z numerem strony. Zwyczajowo można umieścić w nagłówku tytuł lub skrócony tytuł pracy.
  • W celu łatwego wprowadzania poprawek przed rozpoczęciem pracy należy zdefiniować w dokumencie style lub użyć gotowego szablonu, spełniającego opisywane wymagania.
  • Nagłówki akapitów powinny być numerowane z wykorzystaniem list wielopoziomowych, np. 1 Akapit pierwszy, 1.1 Podakapit akapitu pierwszego, itd. Należy konsekwentnie stosować style, ponieważ potem automatycznie będą wstawiane i aktualizowane spisy, etc.
  • Referencje do akapitów należy wstawiać jako dynamiczne odwołania.
  • W przypadku stosowania akronimów i skrótów, przy ich pierwszym pojawieniu się w treści należy wyjaśnić ich znaczenie lub je rozwinąć - można to zrobić w formie przypisu dolnego lub w formie nawiasu, kolejne wystąpnienia nie wymagają ponownego wyjaśniania znaczenia.
  • Marginesy standardowe.
  • Czcionka podstawowego tekstu to od 11 do 12 pt, interlinia 1,1 do 1,25.
  • Akapity powinny być justowane do obu stron, pierwszy wiersz akapitu powinien zawierać wcięcie, po akapicie powinien być nieco większy odstęp.
  • Rozdziały poziomu pierwszego powinny zaczynać się od nowej strony.
  • Po nagłówku rozdziału poziomu pierwszego przed nagłówkiem rozdziału poziomu drugiego powinna znajdować się treść, w ostateczności jeśli nie ma już innych pomysłów natury merytorycznej, może to być treść krótka, zwięźle opisująca, czego dotyczy dany rozdział i ew. podrozdziały.
  • Tam gdzie to możliwe, wstawiana grafika powinna być wektorowa.
  • Pod każdym rysunkiem powinien znaleźć się numerowany podpis. Przynajmniej jedno odwołanie do każdego rysunku powinno znaleźć się w tekście. Podpis pod rysunkiem po numerze zawiera kropkę i odstęp, a następnie podpis. Podpis powinien kończyć się kropką. W przypadku podawania źródeł rysunku najlepiej jest to zrobić poprzez odsyłacz do literatury, a nie wstawiając np. URL.
  • Praca musi zawierać numerowaną listę - spis literatury. W tekście muszą znaleźć się odwołania do pozycji literatury w formie dynamicznie aktualizowanego odnośnika (nie należy zatem wpisywać np. [4] tylko wstawić odsyłacz / referencję do pozycji literatury nr. [4] )
  • Ilekroć w tekście znajdują się cudze tezy, twierdzenia, równania, statystyki, wzory, itp. których autorem nie jest dyplomant, należy wskazać źródło, z którego informacja ta pochodzi, najlepiej w formie odnośnika do literatury. Nie trzeba jednak podawać źródeł do informacji natury oczywistej i ogólnie wiadomej (np. fakt konieczności zatrzymania się na czerwonym świetle nie musi być udowadniany istnieniem odpowiedniego zapisu w kodeksie drogowym).
  • Lista literatury może obejmować URLe, niemniej jednak należy wtedy wskazać moment dostępu do zasobu (informację, kiedy dana treść pod wskazanym adresem była dostępna). Należy unikać długich URLi, w szczególności niedozwolone jest wstawianie URLi, które zawierają SessionID.
  • Lista literatury powinien zawierać większość pozycji książkowych - sytuacja, w której w spisie literatury są same adresy URL, poza uzasadnionymi przypadkami są uznawane jako niepoprawne.
  • W przypadku możliwości wyboru, definicje, twierdzenia, itp. należy definiować przy użyciu sprawdzonych źródeł literaturowych (drukowanych lub w formie elektronicznej, ale wydanych w postaci książki), dopiero potem korzystać z portali internetowych, Wikipedii, etc.
  • Ponieważ praca ma charakter praktyczny, nie jest konieczne specyfikowanie tezy (z reguły nawet nie jest wskazane), a nawet jej dowodzenie. W przypadku pracy zawierającej elementy badawcze, w zależności od charakteru i tematyki, istnieje taka możliwość, ale należy ją ustalić z promotorem.
  • Kodu źródłowego programów nie wolno wklejać do pracy (jedynie fragmenty prezentujące pewne rozwiązania), wskazane natomiast jest umieszczenie stosownej dokumentacji algorytmicznej, np. w postaci diagramów klas, dokumentacji w formacie UML, diagramu fizycznego bazy danych, itp., w zależności od charakteru i tematyki pracy.
  • Listy nienumerowane (wypunktowania) można przedstawiać dwojako - jesli treści w poszczególnych punktach są hasłowe, całość wraz ze zdaniem wprowadzającym należy potraktować jako jedno zdanie, tak więc przed rozpoczęciem listy należy postawić dwukropek, a po nim kolejne elementy zaczynać z małej litery i kończyć przecinkiem za wyjątkiem ostatniego, który należy zakończyć kropką. Jeśli w treści każdego punktu znajduje się wiele zdań, każdy z punktów traktujemy jak osobny akapit, zaczyna go więc duża litera, a kończy kropka.
  • Na końcu pracy należy umieścić załączniki, w których należy umieścić (jeśli dotyczy): spis rysunków, spis tabel, wyniki badań, których ze względu na objętość nie można przedstawić w treści (przy czym w takim wypadku w treści powinno byc stosowne odwołanie), zawartość dołączonej do pracy płyty CD/DVD (podział na katalogi).
  • Załączona do pracy płyta CD/DVD, nośnik USB lub karta pamięci powinna zawierać wszystkie elementy związane z pracą oraz dokument opisowy w formacie PDF. Zawartość płyty zależy od charakteru pracy, w szczególności są to: schematy i pliki projektowe do sprzętu, pliki konfiguracyjne, solucja lub workspace z projektem oprogramowania. W każdym przypadku zawartość musi być spójna i obejmować wszystkie elementy niezbędne do odtworzenia pracy, za wyjątkiem elementów ogólnie dostępnych (a więc nie wolno umieszczać kompilatorów, sdk, runtime).



Prace dyplomowe magisterskie:

  • Prace magisterskie co do zasady są podobne w formie do prac inżynierskich, tak więc ww. opis poza niektórymi punktami nadaje się również dla dyplomantów prac magisterskich.
  • Podstawową różnicą jest fakt iż praca magisterska musi zawierać element badawczy / naukowy, a nie wyłącznie praktyczny. Proszę nie zakładać zatem, że w ramach pracy magisterskiej zostanie stworzony kolejny CMS do sklepu internetowego...
  • Lista propozycji prac magisterskich znajduje się w systemie PD, nie jest to jednak lista zamknięta - jeśli jesteś zainteresowany innym tematem lub masz pomysł, zapraszam do współpracy.
  • Spodziewana objętość pracy magisterskiej to ok. 60-80 stron.
  • W bardzo wielu przypadkach prace magisterskie stanowią ciekawe źródło badań i aż prosi się o ich opublikowanie. Taką ofertę składam nieznacznej liczbie dyplomantów z czego dotychczas wszystkie tego typu przypadki zakończyły się sukcesem. Dyplomant jest wtedy z reguły co najmniej współautorem publikacji naukowej. Informację o chęci wspólnej publikacji najczęściej przekazuję na etapie ustalania szczegółów pracy magisterskiej ale ostateczna decyzja zależy od wyników przeprowadzonych badań, a w szczególności od ich jakości.
  • W związku z powyższym, w celu ułatwienia prac i komunikacji po odejściu dyplomanta z uczelni (proces wydawniczy może trwać nawet do dwóch lat), proszę o posługiwanie się kontem mailowym innym niż konto studenckie oraz o założenie użytkownika w komunikatorze Skype.

Przedmioty / Subjects

ToLC Macro M1

Lectures

Lectures are performed by prof. Krzysztof Cyran till the end of the November then by Ph.D. Eng. Piotr Czekalski. Lectures presented till end of the November cover so called combinational devices while remaining part of the semester is related to the sequential devices. There is no exam nor validating test during the lectures however students presence during lectures is obligatory.

Classes

Classes are performed similar schedule as lectures (split between 2 lecturers). There are two validating tests, one for combinational devices (late November, the exact date to be announced during classes and lectures) while the other one is related to sequential ones. The following rules apply to the sequential part (as presented and lead by Piotr Czekalski): to obtain the final grade from the ToLC each student is expected to satisfy at least 51% knowledge in every task presented to the student during each test (single test is composed of 3 tasks to complete).
Each student is requested to download and bring a printed copy of the following materials for EACH classes:

ToLC test results:

Please note - any reviews, comments, explanation take place ONLY during scheduled consultation. Emails regarding tests will be cancelled. Students that failed the test (their grade is bz) are obligated to present themselves along with satisfying level of knowledge on ToLC during next scheduled test. They have to catch up only with those tasks that they failed (those are marked with red background and present the grade less than 2.51).

Labs

Laboratory is located in rooms 320 and 321. The usual schedule is two sections are working parallel leaded by different supervisors. Please mind, there is different schedule for each section. Always consult your individual schedule in ZMITAC database.

IoT Macro M6

Lectures

Lectures are performed by Ph.D. Eng. Krzysztof Tokarz and Ph.D. Eng. Piotr Czekalski.
For the first few weeks lectures will be held during regular scheduled lecture dates and extra during laboratory time (till April, see detailed schedule below). Afterwards only laboratory activities will be performed.

    2017 Macrofaculty Schedule
  • Introduction to IOT - 27.02.2017 08:30
  • Getting familiar with your hardware - 06.03.2017 10:15
  • Programming fundamentals - 13.03.2017 08:30
  • Sensing and acting - 13.03.2017 10:15
  • Communications and communicating - 20.03.2017 10:15
  • User interfaces in IoT devices - 27.03.2017 08:30
  • Security and privacy in IOT - 27.03.2017 10:15
  • Lab organisation - 27.03.2017 10:45

Labs

Labs are performed in a form of continuous collaborative project starting April, see detailed schedule in ZMITAC database), where students work in groups implementing hardware and software components that constitute a fully operational sensor network with data storage and advanced networking capabilities, data analytic and presentation layer.
Low level components cover Arduino boards (Uno, Mega 2560), ESP 8266 autonomous modules, DHTxx sensors and Ethernet shields. An extra Raspberry Pi and Orange Pi boards are supposed to supply the intelligent network.
Network is based on IP4 and eventually 6LowPAN.
Data processing and storage covers data forwarders in microservices model (i.e. Mosquitto server), protocol converters (i.e. NodeRED) and databases (i.e. PostgreSQL, MongoDB) running heterogeneous Windows-Linux platform with Hyper-V virtualization.

AITUC Inf N1Z

Ćwiczenia tablicowe

Harmonogram wykładów oraz zajęć tablicowych (ćwiczeń) znajduje się poniżej.

Poniżej znajdują się materiały pomocnicze do ćwiczeń tablicowych, które należy mieć ze sobą wydrukowane NA KAŻDYCH zajęciach. Proszę nie sugerować się numerami plików, ponieważ nie pokrywają się z tematyką i numerami zajęć w pełni.

W trakcie semestru przewidziane są 4 kartkówki z tematyki odpowiadającej wykładom i ćwiczeniom o numerach zajęć od 1 do 4 włącznie.
Kartkówki odbywają się na początku każdych kolejnych ćwiczeń (a zatem na początku ćwiczeń nr 2 będzie test z tematyki omawianej na zajęciach nr 1, na 3 z 2, itd.).
Przypominam, że zgodnie z podanymi na początku semestru warunkami zaliczenia, każda kartkówka musi być pozytywnie zaliczona.
W ramach poszczególnych zaliczeń kartkówek ostatnia uzyskana ocena z każdej kartkówki musi być pozytywna.
Minimalna ocena zaliczająca kartkówkę (widoczna w bazie ocen ZMITAC) to 2.51 . Zatem jeśli masz ocenę 2, 2.25 lub 2.45 to znaczy, że nie masz zaliczenia.
Jeśli Twoja ocena jest niższa niż 2.51, MUSISZ pisać kartkówkę w najbliższym terminie poprawkowym (nieobecność nieusprawiedliwiona w takiej sytuacji jest traktowana jako ocena 2.0).
Jeśli masz już pozytywną ocenę i przystępujesz po raz kolejny do zaliczania kartkówki, musisz uzyskać ocenę co najmniej 2.51, inaczej stracisz wcześniej uzyskane zaliczenie (zgodnie z regułą, mówiącą, że ostatnia ocena musi być pozytywna).
Kwestia średnich - jeśli średnia ocen jest mniejsza niż 2.51, ale Twoja ostatnia ocena jest pozytywna (np. 3), uzyskujesz zaliczenie danej kartkówki niezależnie od średniej.
Przykłady (dotyczy pojedynczej kartkówki):
2;2;2.51 - zaliczyłeś kartkówkę (w trzecim podejściu)
4;2 - nie zaliczyłeś kartkówki
2.51 - zaliczyłeś kartkówkę w pierwszym podejściu

Wyniki (oceny) oraz obecność na zajęciach jest dostępna w tzw. bazie ZMITAC, dostępnej tutaj. W przypadku problemów z zalogowaniem się do bazy, przejrzyj sekcję FAQ na mojej stronie.

Laboratorium

Regulamin laboratorium znajduje się tutaj.
W celu zaliczenia przedmiotu należy:

  • Brać udział (aktywny) we wszystkich zajęciach laboratoryjnych.
  • Uzyskać pozytywną ocenę z każdych zajęć laboratoryjnych - jakkolwiek automatycznie wyliczana jest średnia z uzyskanych ocen, istotne jest aby ostatnia ocena była pozytywna, np. uzyskanie kolejno: 2,75 / 3 / 2,25 nie daje zaliczenia, ale kolejno : 2 / 2 /3 to zaliczenie daje (przykład obrazuje kolejne oceny uzyskane w ramach zaliczania tego samego ćwiczenia!). Osoby, które pisały dotychczas dwie kartkówki i nie uzyskały odpowiednio wysokiej średniej są zobowiązane do pisania kartkówki z wszystkich ćwiczeń (1,2,3), z których nie mają pozytywnej oceny (vide punkt powyżej).
  • Uzyskać zaakceptowanie raportu (nie wystarcza samo wysłanie, raport ma być zaakceptowany przez prowadzącego). Prowadzący ma 2 tygodnie robocze na sprawdzenie raportu. Proszę zatem nie zakładać, że wysłanie raportu pod koniec września załatwia sprawę. Raporty takie mogą zostać nieocenione, co będzie równoznaczne z brakiem zaliczenia przedmiotu.

Uwaga - trzeci termin zaliczenia jest przewidziany na pierwsze dwa tygodnie września. Osobom, które dotychczas nie zdały sugeruję aktywne działania w celu uzyskania zaliczenia (konsultacje, etc.).
Proszę o kontakt starostę roku celem ustalenia terminu poprawkowego.
Terminy poprawkowe są ogłaszane na stronie www.piotrczekalski.pl oraz w systemie db.zmitac.aei.polsl.pl .

JA - języki assemblerowe

Projekt

Prezentacje publiczne koncepcji i sposobu rozwiązania.

W ramach przedmiotu obowiązkowe prezentacje biznesowe projektu dla osób, które ich jeszcze nie przeprowadziły są możliwe w podgrupach, w trakcie konsultacji lub w innym umówionym terminie (patrz poniżej). W związku z koniecznością zorganizowania rzutnika, audytorium i słuchaczy wcześniej należy się zapisać na termin prezentacji osobiście u prowadzącego, czyli u mnie (droga mailowa nie jest akceptowana) wraz z pozostawieniem namiarów kontaktowych. Termin prezentacji zostanie podany po zebraniu grupy zainteresowanych osób.

Prezentacje kodu programu.

Prezentacje kodu programu odbywają się indywidualnie, w trakcie przewidzianych harmonogramem zajęć oraz później, podczas konsultacji, w miarę dostępności prowadzącego.
Kodu programu NIE wysyłamy przez bazę ZMITAC.

Wpis zaliczenia.

W celu otrzymania zaliczenia należy złożyć wydrukowaną stronę tytułową raportu lub kartę projektu (w zależności od ustaleń z prowadzącym) oraz podpiętą do strony (w sposób nierozerwalny lub w koszulce foliowej, etc.) płytę CD na której musi się znaleźć:

  • Kod źródłowy programu wraz z plikami solucji, dodatkowymi bibliotekami które nie są standardowo dostarczane z kompilatorem, a z których korzystano, jednym słowem wszystko co jest niezbędne do przekompilowania i uruchomienia programu.
  • Przekompilowana wersja programu (może być w strukturze solucji).
  • Prezentacja w formacie PDF.
  • Raport w formacie PDF.
  • Pliki niezbędne do wykonania scenariuszy testów, które opisano w dokumentacji.

Raport.

Raporty z pracy należy przesyłać do oceny po zaliczeniu prezentacji biznesowej i prezentacji kodu programu bezpośrednio poprzez bazę ZMITAC w formacie PDF. Droga mailowa nie jest akceptowana. Przypominam, że na sprawdzenie potrzebuję do ok 7 dni roboczych, w związku z tym, raporty MUSZĄ być przesłane najpóźniej w drugim tygodniu zimowej sesji egzaminacyjnej. Nie gwarantuję sprawdzenia w terminie zakończenia sesji raportów przekazanych później. Jednocześnie przypominam, że datą akceptacji raportu jest data przesłania przez studentów do bazy ZMiTAC raportu, który zostanie zaliczony (w przypadku odrzucenia i konieczności poprawek datą złożenia raportu jest data złożenia poprawki, a nie pierwszej wersji raportu). Jednocześnie informuję, że raporty należy złożyć najpóźniej 14 dni przed zamknięciem systemu EKOS. Raporty złożone po tym terminie zostaną odrzucone.

Zawartośc raportu jest ściśle uzależniona od charakteru projektu. Poniżej zawarto wskazówki n/t pożądanej koncepcji dokumentu:

  • Wstęp teoretyczny.
  • Założenia - zgodne z przesłanymi na początku semestru i zatwierdzonymi przez prowadzącego.
  • Wyjaśnienia algorytmów i technologii - może być połaczony ze wstępem.
  • Specyfikacja zewnętrzna - w przypadku DLL - specyfikacja eksportowanych funkcji, w przypadku aplikacji DOS interface użytkownika, etc. - zasadniczo jest to specyfikacja udostępnianych funkcji z części assemblerowej projektu oraz sposób ich użycia.
  • Specyfikcja wewnętrzna - algorytmy, marka, funkcje, stałe, zmienne - jednym słowem opis kodu - uwaga - proszę NIE wklejać całości kodu do raportu.
  • Testowanie i uruchamianie - przynajmniej jeden scenariusz testowy, prezentujący sposób działania programu tzw. ścieżką pozytywną - dane wejściowe, ustawienia parametrów przetwarzania, sekwencja operacji do wykonania, etc. oraz oczekiwane dane wyjściowe. W tym punkcie znajduje się również miejsce na opisanie aplikacji wysokopoziomowej, która w przypadku biblioteki DLL była wykorzystywana do prezentacji jej możliwości.
  • Wyniki testów - w tym miejscu można umieścić np. wyniki testów porównawczych wydajności algorytmu w języku wysokiego poziomu oraz w assemblerze, osiągnięte cele i ciekawe rezultaty pracy.
  • Podsumowanie.

PiA Macro M2

Lectures

Lectures are performed by Ph.D. Eng. Krzysztof Tokarz.

Laboratory

Labs are leaded by Ph.D. Eng. Piotr Czekalski, according to the individual schedule.
There are two hand-on labs. You can download the laboratory instructions here - click for PiA in the left menu then download instruction and accompanying materials (i.e. templates):

  • Ex 8. Programming assembler in MS Visual Studio 2013 in x64.
  • Ex.9. Integrating .NET and assembler x64 in MS Visual Studio 2013.

Students are graded for each task according to the results and their involvement. It is also a requirement to deliver and ensure acceptance of the report for each lab. The reports should be prepared as PDF file and submitted along with VS solution as a single ZIP file via electronic submission system.

Afterwards, there is a short project (a teamwork) section on PiA. Students are supposed to acknowledge the project subject with the supervisor during PROJ-ASSUMPT meeting, then prepare and present their conceptual presentation - a public, verbal presentation along with PDF/Power Point one - during PROJ-PREZ event, then individually present their solution to the supervisor no later than during PROJ-IMPL activity date and finally provide a report on the project to the supervisor using electronic submission system.

You can access the electronic submission system here.

Automated Learning Systems, Qafqaz University, Baku, AZ
FEHIS, Macro, M.Sc.

LEGO MINDSTORMS

Wykłady

Laboratorium

Podczas zajęć laboratoryjnych studenci zaznajomią się z praktycznymi zagadnieniami programowania robotów mobilnych i miniaturowych. W ramach zajęć przewidziano pracę zespołową (w tym interdyscyplinarne zagadnienia z zakresu projektowania konstrukcji robotów, ich budowy, programowania niskopoziomowego, programowania koncepcyjnego ruchu, programowania w warstwie abstrakcyjnej / behawioralnej. Studenci odbędą szereg zajęć, w czasie których w praktyce wykorzystają nabytą wiedzę, w szczególności z zakresu programowania sterowanego przepływem danych (NXT-G, Microsoft Robotics Studio), programowania robotów w językach Java, C#, wykorzystania środowiska symulacyjnego do weryfikacji założeń algorytmicznych, itp.

  • Organizacja pracy, podział na sekcje, omówienie zasad pracy i bezpieczeństwa pracy. Laboratorium 1 - regulamin zajęć (PDF).
  • Podstawy programowania w NXT-G. Programowanie różnych modeli robotów w języku NXT-G. Programowanie sterowane przeływem danych. Laboratorium 2 (PDF).
  • Zaawansowane programowanie robotów różnych klas w języku NXT-G. Laboratorium 3 (PDF).
  • Programowanie robotów klasy Tribot w języku Java. Wprowadzenie do NXJ. Laboratorium 4 (PDF).
  • Programowanie robotów klasy Tribot w języku Java (NXJ) z wykorzystaniem klas nawigatorów. Programowanie behawioralne. Laboratorium 5 (PDF).
  • Programowanie robotów klasy Tribot w języku Java (NXJ) w trybie nadzorowanym z wykorzystaniem bibliotek PC API. Laboratorium 6 (PDF).
  • Programowanie robotów klasy Tribot w MSRDS 2008 - programowanie graficzne w VPL #1 (zdalne sterowanie robotem). Laboratorium 7 (PDF).
  • Programowanie robotów klasy Tribot w MRDS 2008 - programowanie w C#. Modyfikacje projektów serwisów (zdalnie sterowane). Laboratorium 8 (PDF).
  • Programowanie robotów klasy Tribot w MRDS 2008 - programowanie w VPL #2 oraz praca w środowisku symulacyjnym. Laboratorium 9 (PDF).
  • Programowanie w języku C# z wykorzystaniem biblioteki MindSqualls. Laboratorium 10 (PDF).
  • Laboratorium 11 i 12*. Programowanie zaawansowanych modeli robotów w różnych językach. Heterogeniczne systemy kontroli. Laboratorium 11 i 12 (PDF).
    *-laboratoria opcjonalne, prowadzone zależnie od rozkładu zajęć w semestrze i postępów w pracy grup studenckich..

Lectures & labs - Macrofaculty

Lectures and related materials are presented below:

  • Part 1 - NXT hardware, software, robot models and programming overview. NXT-G - a LabView based IDE for data-driven programming in NXT-G language (autonomous mode).
  • Part 2 - programming in Java with LeJOS environment (autonomous and remote controlled mode), programming in Microsoft Robotics Studio (remote controlled mode), programming in C# using Mindsqualls and Visual Studio.

Laboratory instructions are presented below:

Resources

Grades and reports on the laboratory are maintained by the ZMITAC database.

Schedules:

GIS

Egzaminy i zaliczenia ISL

  • Wyniki egzaminu, oceny, zaliczenia, wyniki laboratorium ISL 2016.
  • Termin 1 SGIS ISL - 21.06.2016 10:00-11:00 (sala 328)
  • Termin 2 SGIS ISL - 13.09.2016 10:00-11:00 (sala 328)
  • Termin 3 SGIS ISL - 20.09.2016 10:00-11:00 (sala 328)

GIS and Flight Simulation Systems: Macro, M.Sc.

GIS and Flight Simulation Systems: Reykjavik Technical University, Reykjavik, Iceland

FSX - scenerie oraz dodatki

Scenerie w FSX są dodatkami do oryginalnego wyglądu symulatora, zastępującymi przestrzeń generowaną automatycznie poprzez Autogen przestrzenią, która odpowiada (w znaczącym stopniu) rzeczywistości.

  • Lotnisko Aeroklubu Gliwice (budynek główny, hangar główny + hangar firmy Flytronic).

    Projekt powstał podczas zajęć z przedmiotu Systemy GIS na kierunku Informatyka, specjalność ISL, Politechniki Śląskiej w Gliwicach.
    Autorzy: Paweł Gumiński, Dawid Mroczek, Marek Suwała. Opiekun: Piotr Czekalski.
    Pobierz tutaj.
  • Lotnisko Aeroklubu Gliwice v2 (budynek główny, hangar główny, restauracja, teren wokół).

    Projekt powstał podczas zajęć z przedmiotu Systemy GIS na kierunku Informatyka, specjalność ISL, Politechniki Śląskiej w Gliwicach.
    Autorzy: Andrzej Będkowski, Krystian Domian, Paweł Matynia. Opiekun: Piotr Czekalski.
    Pobierz tutaj.
  • Miasteczko akademickie Politechniki Śląskiej w Gliwicach

    Wydział Elektryczny, Wydział Górnictwa i Geologii, Wydział Chemiczny, Ośrodek Sportu Politechniki Śląskiej (budynek naprzeciw AEiI), Wydział Budownictwa, Wydział Matematyki Stosowanej wraz z Biblioteką Główną, Wydział Mechaniczno –Technologiczny wraz z budynkiem A Wydziału Inżynierii Środowiska i Energetyki, Budynek B Wydziału Inżynierii Środowiska i Energetyki, Budynek C Wydziału Inżynierii Środowiska i Energetyki, Zakład Miernictwa i Automatyki Procesów Energetycznych przy Wydziale Środowiska i Energetyki, Instytut Techniki Cieplnej przy Wydziale Środowiska i Energetyki, Centrum Edukacyjno Kongresowe).
    Projekt powstał podczas zajęć z przedmiotu Systemy GIS na kierunku Informatyka, specjalność ISL, Politechniki Śląskiej w Gliwicach.
    Autorzy: Tomasz Cieślar, Tomasz Załoga. Opiekun: Piotr Czekalski
    Pobierz tutaj.
  • Miasteczko akademickie Politechniki Śląskiej w Gliwicach - 2

    Stołówka studencka oraz klub Mrowisko.
    Projekt powstał podczas zajęć z przedmiotu Systemy GIS na kierunku Informatyka, N2W, Politechniki Śląskiej w Gliwicach.
    Autorzy: Łukasz Dreja, Łukasz Wierzba. Opiekun: Piotr Czekalski
    Pobierz tutaj.
  • Dzielnica Nikiszowiec

    Budynki-opracowane, kościół-z biblioteki, drzewa z biblioteki.
    Projekt powstał podczas zajęć z przedmiotu Systemy GIS na kierunku Informatyka, specjalność ISL, Politechniki Śląskiej w Gliwicach.
    Autorzy: Krzysztof Korus, Piotr Tomala. Opiekun: Piotr Czekalski
    Pobierz tutaj.
  • Lotnisko Muchowiec

    Budynki-opracowane, pas startowy.
    Projekt powstał podczas zajęć z przedmiotu Systemy GIS na kierunku Informatyka, Niestacjonarne Studia Magisterskie, Politechniki Śląskiej w Gliwicach.
    Autorzy: Artur Przybyła, Adam Kubica, Jacek Siuda. Opiekun: Piotr Czekalski
    Pobierz tutaj.
  • Muzeum Śląskie

    Budynki-opracowane.
    Projekt powstał podczas zajęć z przedmiotu Systemy GIS na kierunku Informatyka, Niestacjonarne Studia Magisterskie, Politechniki Śląskiej w Gliwicach.
    Autorzy: Tomasz Gębka, Marek Mrowiec. Opiekun: Piotr Czekalski
    Pobierz tutaj.
  • 3D Connexion Space Navigator - FSX Camera control. Free.

    A camera control for FSX using 3D Connection Space Navigator.
    Designed and developed during GIS labs on Macrofaculty M.Sc. Course, Silesian University of Technology.
    Authors: Tomasz Depta, Adam Kornacki, Abdul Ameer Hassan. Supervisor: Piotr Czekalski
    Download installer here.
  • Pałac w Pszczynie

    Budynki i otoczenie pałacu w Pszczynie.
    Projekt powstał podczas zajęć z przedmiotu Systemy GIS na kierunku Informatyka, specjalność ISL, Politechniki Śląskiej w Gliwicach.
    Autorzy: Dorota Czajka, Marzena Szlapa, Łukasz Klimek. Opiekun: Piotr Czekalski
    Pobierz tutaj.
  • Schronisko Murowaniec w Tatrach (Hala Gąsienicowa)

    Budynek schroniska.
    Projekt powstał podczas zajęć z przedmiotu Systemy GIS na kierunku Informatyka, specjalność ISL, Politechniki Śląskiej w Gliwicach.
    Autorzy: Klaudiusz Stawski. Opiekun: Piotr Czekalski
    Pobierz tutaj.
  • Zamek w Malborku

    Projekt powstał podczas zajęć z przedmiotu Systemy GIS na kierunku Informatyka, specjalność ISL, Politechniki Śląskiej w Gliwicach.
    Autorzy: Paweł Nocoń, Tomasz Guźniczak. Opiekun: Piotr Czekalski
    Pobierz tutaj.
  • Banjul Airport, Gambia

    Project created during labs on GIS systems / Marcofaculty course, Silesian University of Technology, Gliwice, Poland.
    Author: Buba Conteh. Supervisor: Piotr Czekalski
    Download here.
  • Silesian Library, Katowice, Poland

    Project created during labs on GIS systems / Marcofaculty course, Silesian University of Technology, Gliwice, Poland.
    Authors: Ferdynand Naczyński, Dawid Bednorz, Mikołaj Matejko. Supervisor: Piotr Czekalski
    Download here.
  • FSX Plane Tracker (old) - a stand-alone map for FSX and ESP simulator

    Project created during labs on GIS systems / Marcofaculty course, Silesian University of Technology, Gliwice, Poland.
    Authors: Elena Primachova, Michał Dolibóg, Michał Sobolewski. Supervisor: Piotr Czekalski
    Download here.
  • Zamek, Chudów

    Projekt powstał podczas zajęć z przedmiotu Systemy GIS na kierunku Informatyka, N2W, Politechniki Śląskiej w Gliwicach.
    Autorzy: Dawid Szydło. Opiekun: Piotr Czekalski
    Pobierz tutaj.
  • Schronisko na Turbaczu

    Projekt powstał podczas zajęć z przedmiotu Systemy GIS na kierunku Informatyka, specjalność ISL, Politechniki Śląskiej w Gliwicach.
    Autorzy: Piotr Wierciński. Opiekun: Piotr Czekalski
    Pobierz tutaj.
  • Symulator awarii dla FSX

    Projekt powstał podczas zajęć z przedmiotu Systemy GIS na kierunku Informatyka, specjalność ISL, Politechniki Śląskiej w Gliwicach.
    Autorzy: Jakub Szyguła, Jakub Zwoliński. Opiekun: Piotr Czekalski
    Pobierz tutaj.
  • FSX Plane Tracker - a stand-alone map for FSX and ESP flight simulator

    Project created during labs on GIS systems, Silesian University of Technology, Gliwice, Poland.
    Authors: Dariusz Marek, Artur Balsam. Supervisor: Piotr Czekalski
    Download installer here.
    Docs
    FSX Tracker requires Simconnect library

CONTACT ME!

Silesian University of Technology, Gliwice, Poland.

Faculty of Automatic Control, Electronics and Computer Science

Institute of Informatics

room 316/317,
Akademicka 16 street,
44-100, Gliwice,
Poland.

Tel. +48-32-237-2577
eMail. piotr.czekalski (a.t.) polsl.pl