I am using the I term, it just looks different. The D term is harder to implement because of the large dt. This problem is odd because of the large resolution of the sensor, the large dt compared to the changes in direction/speed, and the large number of 0's in my variable chg (even at a larger dt than I've chosen). Please show me how to implement the conventional PID within these limits? Are you suggesting my pressure sensor is inappropriate? Then why does it nearly work with only 3 lines of pseudocode? I don't mean to be difficult. Please teach me or show me some untested code that may help?
I understand you have a large dt because the resolution of the barometer is poor so you don't get value changes very often. Changing your algorithm to hover at the boundary between adjacent values would help with that but not solve the problem. However, if you have an accelerometer then you can get a much finer resolution on the vertical velocity which gives you the input you need to the I term. You just need to ensure that if you do use an accelerometer, you merge it with the barometric input to eliminate drift and cumulative integration errors before applying it to the PID (or whatever feedback algorithm you prefer).
I think I understand. I'm experimenting. My first thought was to focus on the Ameter, even though the calculated velocity will slowly drift after 10 seconds. Because of the time between 1ft changes in position, the velocity will always be rounded greatly until you go very fast, which is not the goal when you're stabilizing a Quad. So I thought, when do you know the speed exactly? When you're going 0, and you have many 0's in a row. When that happens you can reset the velocity calculated by the Ameter to 0. But how do you get it to go 0 speed in the first place? First you have to measure the speed with the Ameter. Which doesn't help because of drift. It's a loop with no solution.
Try again. I'm going to sample the pressure every 1 sec which gives me absolute speed. The last 100-200ms of Accel will not be captured by the last data point so I will use that to adjust the speed. To give me more resolution I will spread out each 1ft move into 2x 0.5 ft changes. This will work great when the speed is in that range. I will always reset the speed to 0,0.5,or 1 ft/sec when it's moving slow, adjust by the last 100ms. When it's moving 0 for 3 in a row, I will assume I am stable and not likely to move again for a bit, or get data from the pressure sensor. Then I will be forced to keep summing the Ameter to get speed, until the pressure sensor gives me another tick. I know all this is hard to understand. Don't even bother until I tell you how well it works! I'll be back soon.
sbright33:
But how do you get it to go 0 speed in the first place? First you have to measure the speed with the Ameter. Which doesn't help because of drift. It's a loop with no solution.
That's not really true. You can use the accelerometer to detect small changes in vertical acceleration, vertical speed and height. The speed and height terms will be subject to cumulative errors. You can use the height indication from the barometer to detect errors in the height from the accelerometer. If the accelerometer says the height has changed by more than the resolution of the barometer, and the barometer does not indicate a change, then you can conclude the accelerometer is giving you an error. There are a couple of ways you can compensate for that. You could add a constant offset to the indicated height to make it consistent with the barometer reading. (In effect, you correct the error in the height but do not attempt to correct the speed.) Or you can calculate the drift between the two and offset the speed term accordingly. You can do this based on a single sample, or you can maintain a longer history and do it across multiple samples. Given the memory constraints, it probably makes sense to do it based on single samples.
Since this approach does not inherently bring the two data sources into perfect alignment, it only detects when they have diverged far enough to indicate an error, I would expect the altitude hold based on the accelerometer+barometer will drift until it reaches the boundary between adjacent barometer readings and then sit there. Of course you could help this process by designing your altitude control algorithm so that the target height is at the boundary too. This will make it easier to use averaging techniques to interpolate between multiple barometer samples, making it possible to get better than 'one bit' resolution. This in turn will enable you to detect and correct for smaller errors in the accelerometer derived speed and height.
As I mentioned previously, the process of detecting the discrepancy between the two altitude measurements and skewing the accelerometer to keep them in sync, seems like the sort of thing that PID would be good for.
I understand what you're saying. Remember the goal is to keep the speed at 0 using a feedback loop. Then slowly move the distance to match where you started. I didn't know PID was used to sync or combine 2 sensors. I thought PID was normally used in a feedback loop to modify something in the physical world which is being measured on a variable scale.
Has anyone had any success at making their own code to control attitude using pressure?
Spring is coming in a few short months! Anyone outside testing their code?