No match for North Korea's 7 missile salute, but we tried.All flights have to take off pointing North & turn into the wind because of the 3DOF IMU. Managed to pull off some stiff wind without blowing string into the propellers. Forget about underslung payloads unless everything from takeoff to landing is automated.
I will test it soon in an airframe as soon as I actually get my plane in the air :), and once I can ensure that the altimeter signal input updates fast enough for use with at least 20-40 mph speed. And of course, still need to interface it with ArduPilot 2.2 with the myrad of other loops already running.
You have all you need. You just need to start flying it. Maybe you need a confidence boost. There's not much to gain from calculating update rates & making sure. Your next step is to connect the data to a control surface.
Thanks for the post. Yes, the .1 provides much better accuracy assuming its values are closer to the actual altitude. How are the "flyers" eliminated?
I have some serious gaps in my understanding of data conditioning, and I have no clue how to figure out the update rate, hack I am not even sure what are the results I am reading half of the time...and still probing around only...but here we go...
This is one of the (posted on internet) codes I have been modifying to see which smoothening value works best with the SCP1000. Without testing all the ranges between 0-1, I tried some points between.
I moved up\down the SCP1000 about 2.5-3 feet. The time measurement on these graphs I would estimate around 30-40 seconds, but the movements of the sensor are not in sync between the two graphs. The scattered results were using around .60 filter value, and the solid line in the graph was with values higher than .75 filter value.
I also played around with the original pressure reading value of the code (in pascals) by multiplying it between 2-8 times to increase the amplitude of the signal.
I need to measure things a little more in an organized way. Also, should try to repeat and time the same up\down movements in order to be able to compare them later with different filter values. Once I find a good set point, I am thinking of adding averaging as well.
I think the values in the lower graph can be used already, but the question is, how do I calculate the update rate and making sure it's as close to real-time as possible in order to get some usable in-flight data inputs?
Well, he claimed the equivalent of the highest resolution at the highest speed. You need to understand least squares minimizing & low pass filtering to use the data from these sensors. You can get any resolution out of anything at any update rate by changing the bandwidth. Let's look at 50 seconds of altitude data from the SCP1000.
In both lines, the update rate was 8Hz but the precision improved dramatically for bandwidth 0.1 It must be at least 8cm accurate.
Hopefully when these sensors get more popular, there will be more tutorials on filtering.
What kind of accuracy and resolution are you getting with the SCP1000?
I am in the process of playing around interfacing the SCP1000 with ArduPilot, and (with my limited programming skills) working on applying various smoothing and averaging loops. The code that I am modifying now places it in the "high-speed mode".
I read that AttoPilot was able to combine the highest bit resolution (via coding) and the "high speed mode" for the SCP1000 at 1m consistent accuracy. Did anyone able to get the 8cm resolution this sensor is capable in theory?
Comments
SCP1000 filter tests.doc
Thanks for the post. Yes, the .1 provides much better accuracy assuming its values are closer to the actual altitude. How are the "flyers" eliminated?
I have some serious gaps in my understanding of data conditioning, and I have no clue how to figure out the update rate, hack I am not even sure what are the results I am reading half of the time...and still probing around only...but here we go...
This is one of the (posted on internet) codes I have been modifying to see which smoothening value works best with the SCP1000. Without testing all the ranges between 0-1, I tried some points between.
I moved up\down the SCP1000 about 2.5-3 feet. The time measurement on these graphs I would estimate around 30-40 seconds, but the movements of the sensor are not in sync between the two graphs. The scattered results were using around .60 filter value, and the solid line in the graph was with values higher than .75 filter value.
I also played around with the original pressure reading value of the code (in pascals) by multiplying it between 2-8 times to increase the amplitude of the signal.
I need to measure things a little more in an organized way. Also, should try to repeat and time the same up\down movements in order to be able to compare them later with different filter values. Once I find a good set point, I am thinking of adding averaging as well.
I think the values in the lower graph can be used already, but the question is, how do I calculate the update rate and making sure it's as close to real-time as possible in order to get some usable in-flight data inputs?
In both lines, the update rate was 8Hz but the precision improved dramatically for bandwidth 0.1 It must be at least 8cm accurate.
Hopefully when these sensors get more popular, there will be more tutorials on filtering.
What kind of accuracy and resolution are you getting with the SCP1000?
I am in the process of playing around interfacing the SCP1000 with ArduPilot, and (with my limited programming skills) working on applying various smoothing and averaging loops. The code that I am modifying now places it in the "high-speed mode".
I read that AttoPilot was able to combine the highest bit resolution (via coding) and the "high speed mode" for the SCP1000 at 1m consistent accuracy. Did anyone able to get the 8cm resolution this sensor is capable in theory?
3 * adxrs150
uBlox 5
scp1000
The DIY way to celebrate the 4th! :) Great photos....!
One question: what do you use for altitude control?
That has to be one of the coolest things I've seen yet!