Albert Kozak Email & Phone Number

Schweinfurt, Bavaria, Germany

without many details: I got an offer to work on a slightly different aspect of motor control and took it. Different from my previous experiences this time the focus wasn't on high-level mathematical algorithms running on the hardware, but instead was shifted to low-level communication of that hardware, namely the communication between FPGA and dSPACE. The issue in the beginning was that there was an unintended communication delay which negatively affected the controlling performance. After some work of getting familiarised with how software interacts with hardware on such low-level and many feedback-sessions in Zoom with a person who knew much more about FPGA programming than I did, eventually this issue was resolved and I documented the updated files using LaTeX — something I haven't used before. with more details: using a Simulink file with an HDL-coder addon a bit-pattern was generated and transmitted to dSPACE, after which it was transmitted back to FPGA, thus making a round trip. after this the original and the round-trip signals were outputted to gates of inverter and measured with oscilloscope. the delay between these two signals was too large. skipping several steps in-between, at some point it became apparent that communication logic between FPGA and dSPACE must be changed in HDL. after these changes were done, the communication had no unintended delays anymore.

Schweinfurt, Bavaria, Germany

intro: it's my very first engineering project and I've been on it from (almost) the very beginning to (almost) the very end. during this time there were so many different tasks that I've been responsible for myself or for which I shared responsibility with other team members! more about the project and the tasks in the following paragraphs. about the project: there is such a control system called "Ball-on-Beam". it's not the most useful system for an average person out there, but it's great for teaching, because it's an example of an inherently unstable system: without a controller it won't do what we want it to do! namely balancing the ball at a certain position. so, as a lab for future Mechatronics students it's just perfect! and that's what it actually is. about the tasks: - research- mechanical design, e.g. building Ball-on-Beam setup from Fischertechnik parts or designing and printing 3D parts in Fusion 360- modelling and control design, e.g. designing a classical cascaded control or a state space controller- rapid prototyping with MATLAB/Simulink and dSPACE to test and tune the controller - circuit simulation in LTSpice, breadboard prototyping and PCB design in EAGLE- measurements with a multimeter and different oscilloscopes- PLC programming with Machine Expert- documentation

Schweinfurt, Bavaria, Germany

assisted students on their way through C++ course by preparing summaries of theory from lectures in short presentations, answering their questions, giving tips, solving exercises designed by professor who held the lectures, solving previous year exams, etc. etc. etc.

Marktheidenfeld, Bavaria, Germany

shortly: using the same software and hardware as during my internship I've implemented another sensorless control algorithm on a PMSM. this time it was a saliency-based algorithm that ran at zero and low speed. longer: during my thesis I've worked towards the same goal as during my internship but with a different algorithm. skipping all the hours of work and all the consultations with my supervisors, after less than 2 months it was successfully implemented. naturally, there was a lot of room for optimisation of its estimation performance, but due to time restrictions of bachelor thesis format those were left for the future. instead several experiments with different load conditions and parameter adjustments were done and results were gathered for the next stage: writing the thesis. details for those curious: the necessity for another algorithm becomes more obvious when the example given below in the internship description is considered. there is simply no induced voltage at zero speed, thus it cannot be numerically evaluated and the position cannot be deduced. control at zero speed, for instance when withholding a load, however, is something that must be often done in servo applications, thus requiring an approach not relying on induced voltage as the utilised physical phenomenon. if you're interested which physical phenomenon was used instead and how it works, please do ask me, I wrote my thesis about the topic, I love talking about it :D

Marktheidenfeld, Bavaria, Germany

shortly: using MATLAB/Simulink in combination with a dSPACE rapid-prototyping system I implemented several sensorless control algorithms on a PMSM. one of the algorithms was a BEMF-based algorithm that estimated position in the upper speed range. longer: during my internship I've worked towards implementing several software-based algorithms that are designed to output the same physical quantity as a rotor shaft position sensor (a hardware-based solution). the target-motor for the implementation was a permanent magnet synchronous motors (PMSM). it was integrated into a dSPACE-based rapid-prototyping system where algorithms ran in real-time. in the end of the internship the estimation quality of those algorithms under different load conditions were compared and presented to several involved people. details for those curious: a sensor is physically mounted on the motor shaft and MEASURES the position, whereas sensorless algorithms are digital and ESTIMATE the position by numerically evaluating rotor-dependent terms and utilising them one way or another to deduce rotor position. one example of such a rotor-dependent term is rotor-induced voltage also known as back-EMF (BEMF). it can be utilised is by solving mathematical equations constituting the PMSM model for the term describing BEMF and then numerically evaluating it every sampling period by substituting all the necessary for calculating it quantities and parameter values. after the evaluation, rotor's magnetic flux must be calculated, and from there rotor angle can be extracted, thus concluding the estimation algorithm. in essence it's an observer for the rotor shaft position!