Dear Members,
Hi
Hope you guys are having a good day. For the past 4-5 weeks I have been working on this QuadCopter using open pilot revolution flight controller. With the help of this great community I figured out a lot of problems which I faced when I first started building my QuadCopter. Until now I am trying to fix some problems my design is facing. Explained below is my design and the problems I am facing in flying. Also attached is some image files, videos I made while testing my QuadCopter and the UAV file I used. The videos I made shows how my Quad is behaving.
Please have a look and suggest me where I need to focus more to fix this problem and achieve success.
Design
Frame : Quanum Vneture FPV QuadCopter
Frame size: 430 mm
Weight: 440 gram
Prop size: 10x4.7
Motors: 2213 935KV Multistar motors
ESCs: Afro 20 A
Flight controller: Open pilot revolution
Battery: LiPo 3000 mAh 3S
GPS: Open pilot V9
GCS: 15.05.2 release
TX/RX: Turnigy 6-channel
Problems
1. Lift is not smooth. Lift must be a nice smooth and stable lift
2. Vertical descend is not smooth either. It goes above very fast and then come down very fast like there is not enough thrust from the motors.
3. On increasing throttle with roll and pitch at neutral point quad is drifting as can be seen in the videos. Also it rolls and pitches at a high speed which is uncontrollable.
4. After throttled first it lifts then with time like within less than a second it starts drifting.
Regards
muscles
You need to be a member of diydrones to add comments!
Replies
Difficult vertical control? You would need a sensor such as sonar to lock the height.
Optical flow sensor can also lock drift against environmental disturbances and calibration errors or load imbalances.
Dear Alex
What do you mean by inertial unit ?
Does it mean the accelerometer, magnnetometer calibration ?
Yes it does. You could also include an electronic compass for a total of 9 degrees of freedom in the IMU (inertial measurement unit).
Calibrating these for an aircraft wouldn't be as simple as other device, and it is usually more difficult than you might think in any device.
There are 3 major considerations. The first two being: Calibrating both the magnitude and angle offsets.
Let's jsut take calibration in one dimension, say a thermistor. Calibration is always required in electronic devices. It may read 20 deg C but the actual temperature may be 19. You'd have to calibrate the offset. Now something that measures in 3 dimensions requires many offsets, an individual magnitude that corresponds to every direction. Imagine a perfect sphere of values. In reality a device measuring in 3d with have a distorted egg shape of values that need to be corrected so that they are shifted (transformed) into the sphere of expected values. Also, the center of the sphere needs to lay exactly at the 3 axis intersect points (0,0,0), 'the origin' of the coordinate otherwise readings overflow into the 'adjacent' (orthogonal) dimensions.
That just takes care of the magnitude. Also there will be angle errors. As in, when the whole egg is transformed into a sphere and then shifted to the origin, it still can be out of calibration in terms of rotations around all three axis'. This occurs as mounting error inside the sensor package. Further mounting errors in how the package is fixed on the parent's device.
The third issue is called Truth Data. What do you use as a reference to determine what the true value is? Another measurement device? How do you calibrate that? It can become an infinitely recursive problem. Fortunately there are methods to deal with that. However, the out of the box calibration tool that comes with some flight software just really doesn't deal with this problem well (documentation). You'd be told to turn the device on each side and that is it. Or roll it around. That does deal with all the different calibration problems, just some of them.
1. they assume the surface you put it on is perfectly level.
2. it assumes the orientation of the device chassis is perfectly orientated with the internals of the sensor
3. it assumes there are no imbalances in drive systems (in our case the motors/propellor) or that there is no loading imbalances.
None of these 3 things are true, especial with a quad.
magnitude errors will impact the system. But most significantly the rotations errors will effect a quad as it will be wrong about it's belief of what 'level' is. It will self stabilize around an orientation that will just keep drifting in the same direction.
You can get most of the way there with calibration routines, but there will still be some small offset that you are going to have to determine. EIther you you do that manually through repeated trails and error test (you'll be doing it this way to start), or, build a complex intelligent feed back system that measures some property of the environment that it correctly evaluates as truth data. In typical systems this would be by use of a camera, and interpreting motion from the flow of identified objects in the image. That's the best way as once it is built it can always be run on demand and works well. However it is a lot more work to build in the first place.
In the short term manual calibration wins for time cost. In the long term automated systems win. Any changes to your system will require recalibration, so after a while many manual calibrations will add up to more time cost. And it's a pain in the butt. The first time you can call it science and pat yourself on the back for using a pen and paper and doing it properly. The 100th time you want to put the pen in your eye.
This usually it isnt so much of a big deal with ground based vehicles. Obviously it is a big deal for a flying lawnmower.
Alex
Alex,
Thank you for taking the time to write such a detailed and technical response. Our level of understanding is not as experienced as yours and we could use all the feedback that you can provide, The controller card that we are using is the open pilot revolution board. The frame is an FPV suited for a Naza. I am uncertain if this make any difference. My guess is probably not that much. I posted a couple of flight test videos in my first post in which the quadcopter is experiencing some serious drift. A number of members on the openpilot and rcgroups forum responded with comforting and supportive feedback. While I appreciate the encouragement I cant accept the "as is" configuration of our quadcopter satisfactory. Some suggested fly and have fun and don't worry about the drift but the thing is that we cannot ignore it. Drift is a safety issue and we need to address it for a safe and enjoyable experience.
I don't believe they were able to properly evaluate the magnitude of drift and speed from the video. In some cases videos are not as helpful as they lack reference. As you point out we need to optimize our settings. Here is what we have already done thus far: (1) Sensor calibration which is encompassing of fine tuning the accelerometer, magnetometer, gyro calibration, and putting the quad on a level surface, I don't think my sensor calibration is 100% perfect. In order for us to achieve perfection we would need to work with robotic precision on an absolutely flat surface. Help me out here as I am not that experienced. So we require six sigma level of perfection here for a flight that has minimal drift. Not too digress to much would you agree that if the surface mount components on the PCB were not installed with 6 sigma perfection that we would have drift or other undesired performance issues. The reality of the matter is that we don't have a three axis gyroscopic rig to optimize the physics i.e. center of gravity, etc although such a device would be very good to have. IS there such a thing? Hypothetically speaking even if we had such a rig I am certain we would still need to input off-set PID (XYZ) values for the best possible results. Correct me if I am incorrect up to this point. Our goal is to achieve godly if not near godly performance if that is possible. What are our options? How do we tackle this problem? We have done the best that we can in terms of sensor calibration and inputting offset value using OPNG tune. How does one go about programming off-set values. Is this a trial and error exercise. You mention "include an electronic compass for a total of 9 degrees of freedom in the IMU (inertial measurement unit" You have us lost with this approach. Is this the holy grail that we are looking for? A device that we need to incorporate that will be the fix all to our drift problems?
Hi muscles
Well first off, if you have calibrated the accelerometer, magnetometer, and gyro, then you have a 9 Degrees Of Freedom IMU
It kind of sounds to me like you know what you are doing...
I would think the drift is a result of the sum total of errors in the chassis, flight board mounting, and the sensor itself. If you have sensor manufactured to 6 sigma, well then that eliminates a large potential source of error. Mine is Chinese, god knows what they did. Either Way, I'd say we are talking about each axis being truly orthogonal within the sensor, and that the sensors axis (frame?) are perfectly aligned with the sensor package. And then did the fight board manufacturer solder the device onto the board aiming for 6 sigma? The answer could very well be yes, if you are looking for that kind of precision in your system, you likely paid for quality electronics.
But, I seriously doubt there was any 6 sigma consideration when it came to building the chassis. Or even the housing for the flight control board within what product you have. You could put your quad on a perfectly level surface, and have 6 sigma precision electronics, you are still going to have rotation offsets as a result of cheap plastic quad body. Even if the mounting screw were not all sunk to the same depth, all these tiny errors add up.
Hypothetically, even if you did nail down all the frame and mounting errors to a point where you could calculate the correct offset, I would think aligning the motors so they are perfectly plumb would be very difficult. They too I would think come into play here. It could be that a perfectly calibrated chassis and flight board needs to maintain a slightly tilted pose to remain motionless due to mounting errors associated with the motors? I'm not certain there. I am just throwing that out as a potential source of further error.
The point I am trying to make with this is we are not trying to make the quad believe it is level while sitting on a level surface, level is defined by flying level, no drifting. To grossly exaggerate, the vehicle could be totally cocked to one side at 30 degrees and holding steady, and we could say it is calibrated and flying level.
All these tools you are talking about are really helpful. A three axis gyroscopic rig would be awesome to have. I have thought of maybe throwing one together myself, could be a fun little project. That still leaves the problem of just calibrating the board with a small one though, and building a large one that incorporate the chassis is a bit absurd?
I'd think if you have drift that is consistent in the same direction, you are going to have to deal with it by manual tuning on your first build. That is in fact where I am with my quad. Stuck for some time to be honest :D I find this stuff a bit tedious, I'd rather solve with closed loop solutions. With my 650 frame I need to go to a field to perform that work.
You do make a good point though bringing up the PID values. If your tuning has left you with any kind of damped controller, you never will achieve the target level value. You most certainly want to be slighting overshooting in this application for all sorts of reasons. But yes this could completely overshadow the source of error. You could perhaps dial in something that was obviously overshooting. That way you would eliminate that as the source of error in testing if you are worried about it and get soem sort of visual feedback. Even if you had an unstable oscillation coming from the controller you still observe drift? Though I'd say you should be able to visually observe if you have a very good slightly overshooting PID. Perhaps too if the PID values were the cause, wouldn't the expected result be drift, but a drift in different directions at different times? I'd say if you are consistently drifting in the same direction every time then it would be orientation errors affecting the accelerometer. Maybe you could test that by tugging on the landing gear while in flight and seeing if you can get it to drift in another direction.
Also, if your are looking to use out of the box sensor calibration tools (i don't mean PID) I'd read through them well and make sure they really do cover everything. For example you could find an algorithm with some really fancy looking maths that adjusts all your magnitudes, but in the end skips the part about shifting all the values to lay centered around the origin and never mentions other calibration matters. I can't say I am very well read in this area, it's just that I have seen a few methods that i know were incomplete solutions, addressing only a slice of the overall problem..
You are also going to run into this issue when you mount your camera if your are looking to build a robotics system. You'll have to figure out a way to capture the mounting error there too which can be tricky. My experience there is with a humanoid robot. We had to have the robot look left and then right over and over again to sort out the correct rotations matrix values. That could get tricky with a flying lawnmower.
Ultimately the best solution here is a closed loop self calibrating one that uses optics to evaluate if the robot is moving or not. Integrating an optical flow sensor might be simple enough. But that decision comes after a few manual attempts.
I'd say you best bet is to rule out underdamped PID.
Then just sit down with a pen and paper and do an old school trial and error, observing the result.