Looking at the Oscillation. It seems as if there is not enough D to dampen the corrective nature of the pitch PID controller. Every time a corrective pos elev command is given, the pitch responds, but it seems to take some time for the correction to stabalize, so it oscillate a little and damps out quickly. This can be seen in the last part of the pitch oscillation.
The motor signal above, which has the shape of the throttle (blue) and inverted elev signal (DesPitch, Green). The motors are what control the position of the vehicle. But the vehicle tends to oscillate up and down about its CG. So there will be a tendency for vehicle’s pitch (yellow) to oscillate after each motor correction change, which is what we are seeing above. So the pitch signal looks like an oscillator with the elev signal as it’s modulation. Ideally one would like to have enough dampening so that the oscillation converges quickly, but as we can see this is not the case in the system. We need more dampening (D) in the Pitch PID.
Hi all,
I have confirmed the problem is an oscillation in the Pitch PID controller. I tested the vehicle on the ground with the vehicle with on top of a small board under the vehicles CG, while the motors were on trying to stabilize the vehicle: Here is a picture of the Pitch and DesPitch signals and the throttle signal to show the duration of the experiment:
https://drive.google.com/file/d/1eIiaYVKV6pDqBYbeKkQNyDZgOEdidzr4/view?usp=sharing
Here is a log file of the experiment:
https://drive.google.com/file/d/1NLmSRTzsO8arLLzYkmTNljLwauK0bJtm/view?usp=sharing
Now the question is how to get rid of this oscillation. I will now try playing with the Pitch PID parameters.
William
Have you tried adjusting the gains following the tuning procedure outlined in the wiki?
Your throttle is < 15% in the log, and IIRC you said hover power was 70%.
There could be insufficient thrust at such a low throttle setting to counter the inertia of the vehicle. Also, your pivot point is certainly not at the center of mass; how much force is needed to raise the nose or tail? That will hinder pitch control and would not be an issue in free flight or with a pivot point at the CM.
Hi Mark,
True, I am doing the test at low throttle when it is on the ground. But keep in mind I have got this to stabilize this way before and the vehicle flew well. So this method does work. When the vehicle is pivoted at its CG, I can move the vehicle up and down with my little pinky at the motors, so it does not take any force at all. When I jive the vehicle a little elevator the vehicle tilts immediately with a lot of force.
William
I assuming your just using an existing airplane model for this demo. One needs to input a custom airplane model to show a proxy. In turn this uses Ardupilot and will show any major flaws before you move forward.
@William_Walker
It looks like that’s a custom model in the RF editor.
Would you be willing to share it with us?
I assume it has the correct mass and moments of inertia, but I see the rear motor also tilts. Are you planning to do that with the full scale vehicle?
I created the full scale Vehicle design as a CAD drawing using 3DS Max 2018 software. Then I input the Model into Realflight 7.5. The Realflight model flies completely manually without any flight controller. This is possible since a full scale vehicle has a lot of rotational inertia and slows down the vehicle rotations enabling to make manual stability corrections. But it is difficult to hover in one spot without a flight controller. But once it is in forward flight the vehicle stabalizes easily and flies well.
I am interested in using ArduPilot SITL to enable me to use Mission Planner to stabalize and control the vehicle in Realflight 9.5. I have started by getting a Convergence Realflight model to work with SITL on a Windows 10 laptop. Mark Whitehorn also gave sent me a SITL PR that enables the Convergence model in Realflight to fly forward by tilting only the front motors, using elevator stick control, and not the vehicle body, which is better in windy conditions.
without setting up a custom airplane model sim the above test is not valid.
Yes needed to get a real idea what going on via a sim. For an example loading a FBX and assigning let say the YAK will let you fly but will not be a proxy of the imported FBX.
Hi Mark,
Giving out the CAD model might be a problem since we are forming a company to develop the vehicle. I will have to check into this. The RealFlight model was developed many years ago and the design has changed a little since then. The nacels got longer as did the body which enclose the props. This improved the efficiency by keeping the front motor thrust from hitting the vehicles wing. Also as you noted, the vehicle now uses the front motors to yaw the vehicle in VTOL mode. This was done to make the back end lighter. But as we test, the design will continue to evolve.
William
I am making progress on reducing the oscillation by playing with the Pitch PID parameters. But I don’t think I will get rid of it completely because some of it is created by ground effect. The problem is that the back motor thrust under the vehicle is creating a slight vacuum as the gets near the ground. So this pumps the oscillation. Also not all the back motor thrust goes out under the vehicle and some of it bounces off the ground and gets traped underneath. But as the vehicle tilts forward, the more of this traped thrust escapes under the vehicle. This also pumps the oscillation. But once the vehicle is on the air these things no longer become an problem. I notice this in the good flight. The vehicle wobbles a little as it takes off, but smooths out a lot once it is in the air.
https://drive.google.com/file/d/1csnLLtug1sz9msU4BM_flKp9pHXlquIa/view?usp=drivesdk
There’s a prearm check to make sure the log is running:
https://ardupilot.org/plane/docs/parameters.html#arming-check-arm-checks-to-perform-bitmask
Hi,
We have been trying to improve the stability of the pitch PID for several weeks day and really have not made much progress.
Fundamentally the problem is that our pitch fundamental mode of oscillation about its CG is very low, on the order of 1 Hz, and the PID loop is not able to correct for this. We think this is because the PID loop has a filter at its input that filters out the low frequency input stick frequencies so the PID controllers does not respond to them. Unfortunately our vehicle fundamental pitch frequency is so low that the system thinks the oscillation is a stick command and is not getting passed onto the PID controller to correct for it.
Is there any way to change the frequency of this filter. So that the PiD controller can try to correct for this oscillation? Our vehicle has so much rotational inertia that it does not need fast stick corrections. So this filter can be reduced to help pass the oscillation signal to the PID controller.
Thanks William
Summary of progress so far and lessons learned:
-
We have tried 3 different PID values with varying levels of success: P much lager than I, I much larger than P, and large P=I. The last P=I setting seems the most promising and the signals seem to track the setpoint signals well until the motors rail, which then causes the PID loop to fail and the motor signals start to turn off an on. With low I parameter it was observed that the vehicle pitched down a lot (~5deg) with rapid reduction in throttle, whereas increasing throttle had no effect on pitch. Increasing I seemed to reduce the problem a lot.
-
The vehicle is under powered and hovers at 70% throttle, which should be ok for a vehicle that just takes off vertically and transitions immediately to forward flight. But the vehicle has a vacuum problem in back caused by the back motor thrust going under the back end of the vehicle’s side panels. As a result the vehicle will not takeoff unless the back end is popped up immediately on takeoff, which causes the vehicle to tilt forward a lot during take off. Correction of this pitch as the vehicle started to hover has caused the motors to rail, which then causes the PID loop to lose lock and start to turn off and on, crashing the vehicle. We are considering trying using PX4 to see if its PID loops behave better.
-
Adding a thrust blocking skirt to the inside of the vehicle’s side panels significantly reduces the vacuum problem in back and enables the vehicle to take off more easily, and the vehicle has hovered once well with this modification.
-
Flying the vehicle with the batteries not fully charged has caused the vehicle to hover at 80% throttle, and this reduced the headroom needed for maneuvering and caused the motors to rail more easily. So it is important to fly with the batteries fully charged.
-
Because of the problems with the PID loop instability when the motors rail, we are considering testing the vehicle without a flight controller, using only transmitter receiver mixing. The flight controller will be used only to collect flight data for log analysis. Realflight simulations have shown that the vehicle can be flown easily without a flight controller due to the vehicle’s large rotational inertia, which slows down the vehicles effects and gives time for pitch and roll corrections. A slight forward movement of the vehicle improves the stability a lot as the air starts to move over the vehicle and produce stabilizing aerodynamic forces. If successful, this will allow us to study the vehicle’s flight dynamics directly. Afterwards we will understand the vehicle better and can then try to integrate a flight controller to automate the vehicle and make the transitions more smoothly.
- 1 deg pitch and roll fluctuations at ~1Hz are observed, which do not grow with increases in PID values. This is attributed to setpoint drift due to fluctuations of the motor thrust, which is observed in all drones and keeps the drones from hovering perfectly still.
Here are the motor signals, along with associated pitch and roll desired signals from the log files of our flights:
1_PID Good Flight Motor study.pptx (624.3 KB)
2_PID Motor study.pptx (654.5 KB)
3_ IPD Motor study.pptx (595.1 KB)
4_ I=P Motor study.pptx (599.9 KB)
Hi all, here is an update on the Sky Chaser project. We think we have found the problem causing the vehicle’s motors to wildly oscillate, causing numerous crashes. Here is an example:
Motor tests without a prop revealed that the back motor ESC was sticking at high throttle and releasing only when completely throttled down. Because it was in feedback loop in the flight controller, this caused the motors to wildly oscillate from full off to full on. It is amazing we did not destroy the prototype. A simple ESC software update solved the problem.
A CAD model of the 90kg full scale unmanned Sky Chaser flown in RealFlight 9.5S revealed that because of the vehicle’s large rotational inertia, the vehicle can be flown very easily with out a flight controller. The vehicle appears to be a great flying aircraft and is incredible maneuverable.
Land based demo of 90kg unmanned prototype:
Link
Water based demo of 90kg unmanned prototype:
Link
A flight test of the real 90kg full scale prototype without a flight controller showed this was true, and the vehicle flew in a straight line for about 100 m. The test showed that the vehicle is very stable, but has about 1s time delays, between issuing a command and the vehicle responding to the command. A turn was initiated at the end, caused the vehicle to bank, but I decided to abort when I ran out of field. The back motor also stuck at high throttle, causing the vehicle to pitch down when it landed. Now we know the cause of the problem was the back motor ESC.
Because the goal of the project is to develop a fully autonomous vehicle we decided to continue trying to get the flight controller to work properly in the vehicle. Bill Geyer, a member of the community kindly helped me develop a full scale SITL model of the prototype, to develop better flight controller parameters for the vehicle, since they were based on the much smaller Convergence RC model. After some difficulty getting SITL to work reliably on my Win10 laptop, it is now working well, and the vehicle is flying well in SITL. This also helped me practice as a pilot for the test flight. I am very grateful to Bill Geyer and others in the community that helped me troubleshoot the many problems throughout the development process of this unmanned full scale prototype.
As soon as the weather gets better, will be ready for another VTOL only test of the real 90kg full scale unmanned prototype.
Here is presentation of the Sky Chaser project:
Link
Here are pictures of the 90 kg full scale unmanned prototype:
Link
Here is a video of our first successful test hover of the 90kg unmanned prototype:
Link
As you can imagine developing something like this is very expensive. It has taken 8 years and about 100k USD investment to get to this point. And it will require much more to develop the manned version. It is looking like I will soon be going to Abu Dhabi, UAE to work with a few partners there, and the UAE gov to develop a Racing Park for race cars and flying cars. It will have grandstands, several racing tracks, hotels, shopping, a school, and R&D development facility to develop the manned Sky Chaser flying car and other flying vehicles we will be developing for ourselves and others. We will showcase the Sky Chaser there as well as race it:
Link
Sky Chaser is the 1st REAL Blade Runner style roadable flying car that looks and drives like a car, and flies both vertically like a drone and horizontally like a plane, in addition it is amphibian. It has no exposed rotors, uses it body as a wing so there are no unfolding wings, and will be both manual and fully autonomous. It will be powered by a hydrogen fuel cell giving hours of range. Here is an artistic picture of what the final product may look like:
Link
William Walker