Tez No	İndirme	Tez Künye	Durumu
895319		Quadrotor dinamik modelinin ve kontrolcüsünün freertos işletim sistemi ile Raspberry Pi üzerinde gerçeklenmesi / Implementation of quadrotor dynamic model and controller with freertos operating system on Raspberry Pi Yazar:ÖMER SERHAT BÜYÜKÇOLAK Danışman: DR. ÖĞR. ÜYESİ RAMAZAN YENİÇERİ Yer Bilgisi: İstanbul Teknik Üniversitesi / Lisansüstü Eğitim Enstitüsü / Mekatronik Mühendisliği Ana Bilim Dalı / Mekatronik Mühendisliği Bilim Dalı Konu:Mekatronik Mühendisliği = Mechatronics Engineering Dizin:	Onaylandı Yüksek Lisans Türkçe 2023 83 s.
Bu tez çalışmasında bir Quadrotor'un matematiksel modellenmesi ve irtifa kontrolü Matlab ortamında yapılmış, benzetim C programı olarak çalıştırılmıştır. C programına dönüştürülen benzetim, Raspberry Pi geliştirici kartları üzerinde FreeRTOS işletim sistemi içerisinde yüksek önceliğe sahip bir görev olarak çalıştırılmıştır. Çalışma kapsamında Quadrotor aracı, matematiksel olarak modellenmiş ve sistem denklemleri için tüm kuvvet ve tork eşitlikleri türetilmiştir. Gerçeklenen benzetim senaryosu için varsayımlar tanımlanmış ve model ilk olarak sadeleştirilmiştir. Klasik bir PD kontrol stratejisi ile aracın irtifa kontrolü yapılmıştır. Kontrolcünün çalışması farklı referans seviyeleri ile test edilmiş ve çıktılar yorumlanmıştır. Matlabda gerçeklenen senaryo, C dili ile ayrı bir program olarak gerçeklenmiştir. Gerçek zamanlı işletim sistemine geçmeden önce, benzetim, C programlama dili ile dış kütüphane bağımlılığı olmaksızın gerçeklenmiştir. Buı sayede, C dili ile geliştirilmiş programları çalıştırabilen her donanım üzerine bu benzetim taşınabilir hale gelmiştir. Gerçek zamanlı işletim sistemi alternatifleri kullanılacak geliştirme kartları göz önünde bulundurularak deperlendirilmiştir. Raspberry kartlarından, Pi Zero ve Pi 4 isimli iki adet geliştirme kartı kullanılmıştır. Gerçek zamanlı işletim sistemi olarak FreeRTOS kullanılmaya karar verilmiştir. Resmi olarak Raspberry Pi için FreeRTOS desteklenmese bile, aynı işlemci ailesinden bir işlemciye sahip başka kartlarda çalışabildiğinden, düzgün taşıma işlemi yapıldıntan sonra her iki kart üzerinde de çalıştırılmıştır. Benzetim programı için, iki farklı benzetim sistem tasarımı önerilmiştir. İlk tasarım, tüm benzetim programını sadece Pi Zero kartı üzerinde çalıştıracak ve sonuçları analiz bilgisayarına gönderecek tek kartlı bir tasarımdır. Bu tasarım için, benzetim çıktıları, Matlab benzetimi ile aynı çıktıları üretmiştir. Zamanlama analizinde, tek kartlı tasarım önerisinin kabul edilebilir bir hızda çalıştığı gözlemlenmiştir. Gerçek quadrotor için Pi Zero kartı, FreeRTOS ile birlikte kullanıma uygun olduğu görülmüştür. İkinci tasarım, benzetim programını iki ana döngüye bölerek, iki farklı kart üzerinde gerçekler. Benzetim senaryosunda model dinamikleri Pi Zero üzerinde, kontrolcü ise Pi 4 üzerinde gerçeklenmiş ve iki kart arası haberleşme seriport bağlantı kanalı ile gerçeklenmiştir. Benzetim sonuçları, ilk tasarım ve model ile birebir aynı olsa da, zamanlama incelendiğinde ikinci tasarımın çok kötü performans sergilediği gözlemlemiştir. Tasarımdaki problem incelendiğinde, sorunun kaynağı seriport olarak belirlenmiştir. Kartlar yoğun veri transferi olduğundan, bu haliyle seriportu direkt olarak kullanmak, beklenenin altında sonuç vermiştir. Gerçek quadrotor gerçeklemesinde, iki kartlı tasarımın kullanılması önerilmemektedir.
In this thesis, the mathematical modeling and altitude control of a Quadrotor were performed in MATLAB environment and simulated as a C program. Simulation originally existed as a python simulation. Firstly, the simulation is converted to a MATLAB simulation program. As a second step, the simulation is ported as a C program so that it would be easier to implement this program within the RTOS environment. The simulation, which was converted into a C program, was realized as a high-priority, stand-alone task, within the task context of FreeRTOS operating system on Raspberry Pi development boards. Within the scope of the study, the Quadrotor vehicle was mathematically modeled, and all force and torque equations for the system were derived. Assumptions were defined for the implemented simulation scenario. The model is subjected to simplification according to previously defined assumptions. Using a classical PD controller scheme, altitude and the attitude of the vehicle is controlled as non-linear control scenario. The result of the controller is verified with several test conditions and the results are interpreted for several reference inputs. The scenario implemented in MATLAB was also realized as a separate simulation program in the C language. C program uses native libraries to be portable as much as possible. Before transitioning to a real-time operating system, the simulation was implemented using the C programming language without external library dependencies. With this action, simulation program become portable, and it can be ported to any platform capable of executing C programs. Real time operating system definition is given and characteristics of a real time operating system are explained. Real-time operating system alternatives are analyzed in sense of usability, portability, community support, supported CPUs and ease of access. Among the alternatives, FreeRTOS was chosen as the real-time operating system, due to satisfying all criteria. Two development boards, Pi Zero and Pi 4, from the Raspberry Pi family are chosen as implementation medium. Although FreeRTOS is not officially supported for Raspberry Pi, it can run on both boards after a proper porting process since it can work on other boards with the same processor family. To make the boards usable with FreeRTOS, operating system is compiled and build with compliant CPU architecture. The bootup sequence of pi boards are investigated in detail. The built operating system file is configured so that bootloaders of the boards, utilize the FreeRTOS files. In the end, FreeRTOS is configured and build to run on FreeRTOS. Preliminary tests and observation showed operating system is stable. FreeRTOS is mainly developed in C, therefore, previous preparations will result in ease of implementation. C simulation program is converted to a FreeRTOS real time task. As for its programming, operating system allows allocation of tasks and assigning code to these tasks. With this, simulator program becomes a real time task which calculates quadrotor model and controller equations. To realize the simulation in the real hardware, two design alternatives are proposed. The first design stays loyal to the initial port of FreeRTOS, implements the simulator program on a single task that runs the entire simulation context only on the Pi Zero board. This single board design executes the simulation, calculates the passed time and replays the state vector of each simulation step to analysis computer. Original simulation is designed as a 10 second flight simulation. The reference point is taken as MATLAB's calculation time. When the values which are read from the single board design are compared with MATLAB simulation, it was an exact match. For the data consistency, ported simulation showed satisfactory results. For timing analysis, it was observed that the single-board design proposal, operated at an acceptable speed. It was observed that the Pi Zero board, along with FreeRTOS, was suitable for use with the actual quadrotor. The second design proposition divides the simulation program into two main routines. The first routine is the controller, and it requires state vector as input, calculates motor input parameters for next step. The second routine is the plant, and it performs the mathematical calculations, takes motor inputs, runs the non-linear solving algorithm and calculates the state vector for the next simulation step. With the initial conditions defined, simulation loop is completed. Each routine is realized on a different pi board and data is transferred between boards. The model dynamics are implemented on the Pi Zero, and the controller is implemented on the Pi 4, and communication between the two boards was established via a serial port connection. After simulation completed, the state vector data is collected. The tests show that data consistency is identical to the original simulation and single board design. Although the simulation results were identical to the first design and the original simulation, when the timing was examined, it was observed that the second design exhibited very poor performance. Total simulation time exceeded the total flight duration within the simulation. Detailed investigation and additional tests are executed and it has been found that the root cause of the performance issue resides within the serial communication. Using the serial port directly with the boards resulted in suboptimal performance. As a design constraint, double board proposition uses serial port. Between the plant and the controller, for each simulation step, all motor inputs and entire state vector is transferred. This would mean a high data flow between the boards. Even with the highest possible communication rate, the best it can achieve is sub-optimal performance. Although the design performed quite good for simulation data, timing measurements proved, second design proposition is not suitable for a real flying vehicle. In addition to the timing of simulation, the customized real time operating system ports have been analyzed to show whether real time characteristics are satisfied or not. For both Pi zero and Pi 4 boards, the real time operating system contains required minimal software components such as task scheduler. To verify determinism feature, design propositions are put under stress test. Additional stress tasks are defined within the same task context. The limit of tasks can be defined as available ram area for each board. In addition, the tasks are occupied with increment counters to simulate spinning code behavior. Optimization is disabled to prevent compiler to optimize out empty tasks. In the end, including analysis computer, each simulation environment is put under test. In case of Pi zero board, system performs according to real time operating system characteristics. It is observed that task scheduler can appropriately allocate CPU time to highest priority task. As long as, simulation task has the highest task priority, the simulation time does not get effected from additional tasks. In case of Pi 4 board, it is observed that task scheduler for Pi 4 does not preempt the tasks correctly. Independent of task priority, adding more stressor tasks simply increased the overall execution time of simulation. This result showed causes a problem for double board design. The proposition contains a Pi 4 board and Pi zero board. To analyze the task behavior of double board design, Pi 4 is swapped out with another Pi zero. In this case, for double board design, Pi zero is used for both routines. As expected, overall simulation time is not changed under the stress. Both boards are put under same stress and the results showed, the simulation time is same as unstressed setup. Two zero solution also showed comparable results to Pi 4 – Pi zero solution. As previous tests showed, overall delay is caused by serial port, not the boards itself. Even tough, Pi 4 seems to perform better than Pi zero, the customized FreeRTOS port did not satisfy the real time characteristic requirements.