Embedded Files
Introduction
Introduction
I developed this project in my spare time out of personal interest. I particularly enjoyed this project because it encompassed nearly all the fields I am passionate about:
Physical Modeling and Control Loop Design
Real-Time Programming
Embedded Electronics
Communication
Electro-Mechanical System Design
Some skills and understanding related to fling RC models
I kept this project as an idea for a long time. I was inspired by various videos on YouTube featuring creative and talented individuals who pursued similar goals. Over the years, I gained experience in almost all the necessary fields for this project. In 2010, I felt that I overcame the "critical knowledge barrier" and was ready to star5 my own design.
In this presentation, I wouldn't delve into low-level design explanations, algorithms, or mathematical concepts. Instead, I would provide a general overview of the development stages I had gone through.
Step 1 - Simulation
Step 1 - Simulation
I designed a real-time simulation to test the feasibility and theoretical foundations of my model. My simulation was based on:
Theoretical literature research on 3D transforms, system control, and aerodynamics.
Experimental data was collected on the motor and propeller, specifically thrust, torque, and RPM versus input current (measurements were taken using a device I had designed for this purpose).
Estimated weight and dimensions.
The video below shows an early version of the real-time simulation, which was created using Simulink and VRML. It gives a sense of how the angle control loops stabilize the craft. The quad is being controlled with a joystick, and the stick position sets the angle of of the quadrotor on every axis. The simulation simulates the motor, propeller thrust, torque, MEMS sensors response, body inertia and control loops to stabilize the quadrotor.
In the video below I added a velocity (m/s) controller on each axis of the quadrotor. This is suppose to simplify controlling the craft. Later, I realized that this is not practical with standard GPS due to the noise and low accuracy. That conclusion drove me to learn more about sensor-fusion and Kalman-filter theory.
Step 2 - Infrastructure:
Step 2 - Infrastructure:
I build the entire system using ready-made Intellectual Properties (IPs) from my past projects:
The communication protocol and RF link were derived from my automated garden irrigation system, designed with a 4-layer adaptation of the 7-layer model (layers 1,2,3,7). This modular design facilitated changes to the physical layer without a complete protocol redesign. The internal communication operated over RS485 PHY, while the wireless link used IEEE802.15.4 PHY through a customized bridge/access point. Using the same network simplified real-time monitoring and control of all units.
The controllers, Smart-Samplers PIC18F version, were the same type I used in my other projects. They ran the same Real-Time-Operating-System (RTOS), I already developed. Each unit can ran one preemtive user application. The user application is a compiled code that is uploaded to the controller using the existing communication protocol and without reprogramming the RTOS. Moreover, the user application can be debugged remotely as well. This simplified integration and maintenance effort.
To create a realistic model of the thrust vs power, I built a test platform for propellers and motors with my father's help. This platform measured essential parameters like propeller thrust, torque, RPM, motor current, and voltage, enabling insightful performance plots (see an example report below).
The IMU
The IMU
To build the Inertial-Measurement-Unit (IMU), I used the same MEMS sensors I am already familiar with and own.
The calibration process was done using fully computerized environmental-test-oven and 1 DOF, stepper based rotating JIG (I had to calibrate 3-axes x 3-sensors).
The environmental-test-oven TEC based which makes it small and quite. It has temperature range of 0 to 85 C that is perfect for these type of operations.
The 1-DoF Gimbal and Test-Oven are fully controlled by the computer running the calibration procedure.
The mathematics for the calibration is was developed in Mathcad and then written in AWK.
Each axis of the IMU is automatically calibrated without user intervention.
Step 3 - System Architecture
Step 3 - System Architecture
I divided the system into four (4) subsystems:
Power-Distribution Unit (PDU) and Motor Controller
Power-Distribution Unit
Delivered power from the battery to all sub systems and motors.
Included four digitally controlled FET Solid-State-Relays (SSR)s, one for each motor.
Contained four fuses and current sensors.
The SSR control signals were mapped as I/O registers for both remote and local access, while current sensor readings could be obtained manually or broadcast automatically.
Motor Controller
Manage four PWM generators for the BLDC electronic speed controllers (ESCs).
Monitor the RPM of each motor using four Hall pickups sensors.
Monitor the current consumption of each motor using four current sensors.
Monitor motors temperatures via four sensors.
Operated four state machines, each managing the states of OFF, START, and WORKING. It could identify motor faults and restart them automatically. Temperature, RPM, and state could be read manually or broadcast.
IMU and AHRS Unit
This unit featured a 6DoF IMU with a 3D magnetic compass and barometer. It implemented a sensor fusion algorithm to determine Euler angles. The AHRS utilized the IMU data to ascertain the craft's attitude, with future plans for sensor fusion incorporating GPS, to deliver improved position and velocity measurements (INS).
Flight Computer
Executes all hard real-time operations, including control loops, to stabilize maneuvers based on commands from the operator or Navigation Unit.
Navigation Unit
Comprised a standard GPS, an ultrasonic range meter for low-altitude hovering, and a barometer for high-altitude flight. It calculated flight paths using a PVT table, acting as the system’s pilot and communicating directly with the flight computer.
Step 4 - First Integration
Step 4 - First Integration
Testing the UDP to RS485 bridge and RF datalink channel
Testing the UDP to RS485 bridge and RF datalink channel
First version of a simple 10DoF IMU contains
First version of a simple 10DoF IMU contains
3x Accelerators
3x Gyros
2x Magnetometers
1x Barometer
The entire chassis and 3DOF test fixture were built with Lego blocks and an old HDD body. The setup took 2 days to design and build and cost me nothing because no mechanical design, manufacture, or material was needed.
In the first weeks the system was unstable in a very violent way. Only after 3 long weeks I finally had a relatively stable setup. It seems that the Quad stability is much more sensitive to digital delays (Latency) then I anticipated. Some of the things I learned and implemented are:
1. Latency is not a linear function. Hence I had to linearize it in order to add it in my mathematical model. But it is clear that with the current system BW the only practical solution is to minimize the delay to around 20mS.
2. Regular ESC has some kind of input FIR LPF that add around 0.1Sec delay between the input to output (When using ~50hz control signal).
Luckily, It can be reduced by over-driving it with 400hz signal. I will also add a special manipulation on the input signal that also compensates for the inertia delay of the motor.
2. The control algorithm should output it result in the current time step and not the next one (No pipe line calculation allowed)
3. I had to enhanced the respond time of the UDP to RS485 bridge and lower it from ~50ms to ~2ms.
4. Some of the control-loops include prediction algorithm, on the feedback channel, in order to over come the remaining delay.
Only After understanding and implemented the above The Quad started to show signs of stability.
The New and Improved Aluminum Based Chassis
The New and Improved Aluminum Based Chassis
The LEGO design had taken me a long way and proved to be a time- and cost-efficient setup for training and evaluation. However, I learned that the chassis needed to be larger and stiffer for the current motors and propellers. It took me a week to design and assemble the new setup (Quad & 4DOF test fixture), which ended up being much more stable. The motor spacing was 60 cm, with a total weight of approximately 700 g. It consumed around 280 W (12 V/22 A) while hovering, and the weight could be reduced by using smaller and shorter aluminum profiles.
My conclusions from the tests were as follows
I should start the design of the onboard Flight-Computer. Doing so will result in a more reliable system with a wider BW of ~100Hz.
Change the motors to low RPM/V (~750RPM/V) because current 1500KV motors are too sensitive and have a relatively long mechanical delay (inertia delay)
This is an essential step toward testing the Quadee without the test fixture.
The New and Improved Electronics (using dsPIC30F)
3rd Generation of IMU/AHRS
This version featured an Inertial-VSI and altimeter with ~0.2m accuracy. The firmware was developed with a modular concept:
A standard RTOS with specialized drivers for each dsPIC peripheral.
My standard communications stack.
The AHRS algorithm was created in Matlab/Simulink and tested using Real-Time Window Target. Finally, used the automatic code generation and deployed the algorithm as a new task for the RTOS.
This approach allowed for easy migration to different MEMS sensors while continuing the AHRS algorithm development in Matlab/Simulink.
For the Flight Control Unit (FCU), two options were considered:
Option A
Develop a new separate electrical board.
Use my standard RTOS and communication stack.
Create the FCU algorithm in Matlab/Simulink with automatic code generation under the RTOS.
Option B
Develop the FCU algorithm in Matlab/Simulink and deploy it as an additional task on the existing AHRS controller board.
Ultimately, I chose Option B and pushed the dsPIC to its limits.
Old vs. new mechanical differences
OLD: The IMU is located on top - Not a good concept because the vibrations are getting stronger farther away from the C.G
NEW: The IMU is closer to the C.G. and the entire board stack has better vibration isolation due to the usage of silicon-based dumpers (which I designed in PTC-CreoElement and printed in my Huxley 3D-Printer).
OLD
OLD
NEW
NEW
The new setup is better then the old one but it didn't delivered the performance leap I was hoping to get.
The new setup is better then the old one but it didn't delivered the performance leap I was hoping to get.
The New and Improved Motor-Controller
To enhance motor response, an RPM controller was developed for each motor. Each controller featured two control loops: a current (acceleration) loop and an RPM (velocity) loop. The algorithm was relatively simple compared to the AHRS algorithm and took about 0.5 ms to compute the next step for all four motors. Results were obtained from an unloaded 14-pole, 600KV motor driven by a 12V PWM signal at 400Hz. The current loop operated on the dsPIC at 100Hz, while the RPM loop was initially tested on Simulink for debugging purposes, but was later code-generated to run on the dsPIC at 50Hz.
Sine wave: Amplitude 75 to 85 RPS, Freq: 2hz. Response time is down to ~100ms
Square wave: Amplitude 80 to 90 RPS, Freq: 0.5hz. Response time is down to ~100ms
Open-loop results present the following:
- RPS measurement of the 4 quad motors with the reference step control signal.
- Long (~250ms) inertia delay + Dead-Time delay of ~100ms (I need to investigate the source of the 100ms Dead-Time delay)
- It can be clearly seen that each motor has a different rotation speed.
Upper graph - Current consumption of each motor
Lower graph - RPS measurement of 4 motors with the reference step RPS and step control-signal.
Close loop results present the following:
- Very short setup time of ~50ms + Dead-Time delay of ~100ms (I need to investigate the source of the 100ms Dead-Time delay)
- All motors have the same dynamic and steady-state response.
5 Years Later...
5 Years Later...
Today is the 25/11/2016. I left the Quad-Rotor project for something like ~5 years. During this period of time, I did many things :-):
1x more kid :-)
Different interesting projects for different companies.
Improved my RTOS kernel.
Developed the stand alone Smart-AHRS (I am going to use its embedded version)
Gain more experience in C programming (Naturally).
Improved my skills in mechanical design and 3D printing.
Learned to develop in Python (including GUI).
RPI (of course).
Switching from Matlab to Python and improving electronics
My conclusions from Matlab is that it is nice if you don't know how to hand code. It is a form of technical debt that can be used to speedup development. Since, I know how to code very well, I decided to pay off my debt by rewriting everything in C and Python and abandon Matlab for good.
Rewrote the function in Python
created a Python GUI interface
I also improved the electronics of the IMU, AHRS and FCU
Improved Flight-Controller electronics:
1. AHRS is done by the Smart-AHRS module with a dedicated processor - Top-Left (@200hz integration).
2. Motor-Control and Flight-Control are done on the dsPIC30F module - on the right (Borrowed from a different project).
3. The Power-Distribution board (Bottom) is the same.
4. Motor RPS is measured directly from the BLDC-ESC phase.
MODEL COntrollers viewer (MVC)
MODEL COntrollers viewer (MVC)
I followed the MVC architectural pattern to develop all GUI interfaces to control and monitor all subsystems.
COntrollers and viewers
COntrollers and viewers
Four separate applications that each communicates to a specific or multiple process on the Quad-Flight-Control program.
Left: AHRS and FCU
Top right: Motor controller
Bottom right: Operator (Pilot)
Viewer
Viewer
a separate Python application (using VPython module) that represent the AHRS Quaternion or DCM as a 3D object.
Improved the Lego frame by adding a 3D-Printer motor mountings.
The Flight-Control-Loops are not fine-tuned yet. But everything looks ok and the quad performance (stability + response) has improved.
Making a new frame
Firstly, I need to design a 2DOF gimbal that will connect the X525 to my LEGO stand.
The X525 with the pivot is secured to the Lego stand by a Lego Axle.
The fully assembled X525-Quad
The special mounting connectors that connects the electronic board to the X525 chassis.
X525 test on the new JIG.
I also fine-tuned the control-loop parameters relative to the previous video (The one on the Lego-Chassis).
Vibrations!!!
When I was preparing for the 1st test flight, I decided to test the Quad on the 4-DOF stand to verify that the motor & control loops are performing well at different working points.
A few seconds after I increased the motor's RPM, I noticed that the Quad started to bank to the side. I discovered that the vibrations have a devastating effect on the accelerometers. Too noisy readings from the Accels will cause the AHRS to ignore the gravity vector. As a result, the attitude estimation will drift over time.
So, I put on the mechanical engineer hat and started looking for better vibration isolation for the AHRS from the chassis.
I disassembled old CD-Drives - They usually have small vibration isolators for the optical reader. In addition, researched YouTube and found good videos about motor and propeller balancing (I did not know you should).
I used an old CD-Drive vibration-Isolators for mounting the FCU & AHRS on the Quad frame
Developing the QuadTan (The smaller version)
Due to the complexities of this project and its size, the Quad never flew. Instead, I used the knowledge I acquired from this project build a miniature quad (QuadTan), which was fully functional.
The more I think about the test flight, the more I understand the logistical problems that are involved with it:
- Finding a big open space outside.
- Arranging the electricity and computers.
- Doing it safely (seriously, someone can get injured)
- Doing it safely for the Quad (Minimum damage if it fails)
- Good weather. Not too sunny, not too cold, not too windy.
So I was thinking that it would be nice if I had a miniature version of the Quad:
- It will not be dangerous to me.
- It will be more robust to crashes.
- It will be easy to hold, test & feel.
- I can test fly it my working room.
I ordered a Tarot-120 with a 4x BLDC motor, ESC + props.
Build a smaller version of the FCU electronics.
- Changed the CPU of the FCU to PIC6012.
- Removed the Closed-Loop Motor-Controllers. I hope that the reduced inertia will cause the motors to response quickly and can run them in open loop.
- Same Smart-AHRS and wireless communication.
The nice thing is that the Firmware is the same. So this test is going to be a good validation for my Quadol design.
The new QuadTan test platform :-)
SmartAHRS embedded version is located on the left (back side of the Quad)
FCU is the lower board
Bluetooth is on the bottom side of the Quad-Frame
Test-Flight Day!
The configuration for the first test flight:
1. External power supply to reduce weight and remove test-time constrains.
2. Using the power harness to limit the free movement the Quad has.
3. Add Dead-Man switch for quick power cut off..
Altitude-Stabilization Control Loop and Real-Time Graphics-Cockpit application
As mentioned previously, I added a Vario-Inertial capability to the new AHRS.
In general, it is a Kalman filter on the Barometer and vertical acceleration output (in earth's axis).
The Kalman filter output consists of the following filtered measurements (estimations):
- Altitude.
- Vertical speed.
- Vertical acceleration.
By using a dual PID-Control loop on the vertical-speed and altitude. The Quad altitude can be greatly stabilized.
This feature can be activated by the pilot at any time with a press of a button (or remote command).
Page updated
Google Sites
Report abuse