Hi,
need an advice - my son got me into a new build - SonicModell Binary RC 1200mm. I never built planes, only copters before. I will use Kakute F7, have probably more than enough spare parts to do this build - only question i have - i do presume planes are mandatory to have a wind sensor onboard for speed? Is it still a requirement of can it get all it needs from a GPS sensor?
If wind sensor is an absolute requirement - which one is to use now, are there I2C models or are they all analog and require dedicated pin on the FC for the analog signal input?
An airspeed sensor is not required although you would want one for Auto Landing. You would want the digital sensor for that FC. The only Analog input is the RSSI pin which may work but you would need a voltage divider as it’s typical 3.3V max input.
Can you recommend a particular one to buy, a digital one? Also, why again GPS is not enough for indication of speed? what is airspeed sensor providing the gps cannot? just trying to understand the concept.
GPS cannot giving you an information about wind direction and wind speed around a plane.
So for auto missions, it is good to have airspeed sensor, so the plane can know the wind situation.
If you will do it for FPV, Airspeed sensor is not mandatory, because you will have control to your plane.
You can read my thread it has all the info as far as programming. Analog Air Speed Sensor
You have two choices as others mentioned. Analog or Digital. Analog conencts to ADC port and Digital can be connected to I2C port.
Gps is Ground speed which is fine for many things including Auto Missions. But for true airspeed and for best auto Landing you want Airspeed. No reaon to use an analog sensor other than to save a few $.
Makes sense, thx. I am researching now this whole sonic model binary build, it is an interesting frame. Too bad I already implanted my f765 Mateo into tarot hex’s build, kakute f7 is not really ideal for a plane but it will do. What I wonder now is if their suggested 2212 motors are suitable for such plane. To me it seems something like dys d2836 would probably be better, but it is not clear if it would fit into Binary motor bay or not. Will see.
I had a Kakute F7 AIO in a Nano Talon, it was a good choice I thought. I didn’t bother with an Airspeed sensor but you can easily hang it off the I2C port along with the compass. Unfortunately that plane crashed irreparably, now the FC sits on the bench for tinkering until it’s re-purposed.
I repurposed T7 pin and LED pins into PWMs and got total of 8 working outputs. 2 motors and 6 servos. Matek f765 has 13 working outputs… dunno, will see.
hi, i am a bit concerned - could somebody confirm please -
https://ardupilot.org/copter/docs/common-camera-shutter-with-servo.html
Manually trigger the camera shutter
Warning
This feature is currently only supported on Copter.
You can configure the CH7 switch as a manual trigger for the camera shutter and use it to capture images during normal (non auto) flight.
Tip
This is also useful for manually testing if the shutter is being activated correctly.
- Open Mission Planner and then click on CONFIG/TUNING | Full Parameters List
- Set the value of
CH7_OPTto 9
this standard camera shutter control - it does not work on the plane code at all? is it true? how come?
That code is general. What testing have you done?
hi Dave, my build is almost done - i see on the bench that a holibro digital i2c airspeed sensor constantly ‘floats’ from 0 to 2.5 m/s or so - isn`t it a bit too much of a ‘noise’ - 2.5 m/s is quite a bit different from a standstill. is it by design? by blowing toward tube i get readings up to 6-8 m/s, so, it is operational for sure. i just wonder why it deviates so much from 0 with no wind at all in my basement. 
digital sensor does not seem to need any additional scaling of the produced result, is that right?
this is the sensor i got:
http://www.holybro.com/product/digital-air-speed-sensor/
Did you try a Preflight Calibration after it had warmed up for a bit? There is an auto calibration procedure also done while flying.
I am nowhere near flying yet. Code is stuck with yaw inconsistent message. So, the sensor output should not be dancing like that? Odd.
do you know, this holibro sensor - is it supposed to have ARSPD_TYPE=1 set for it?
every time i start model with the ARSPD_USE=1 it dances horizon like crazy in the MP screen, it just does not feel right. i feel something it setup wrong, but, not sure what. sire says it uses MS5611 sensor. there is no such type in the list of params, but, i did not pay much attention to it. perhaps - wrong?
ARSPD_TYPE 1 0:None 1:I2C-MS4525D0 2:Analog 3:I2C-MS5525 4:I2C-MS5525 (0x76) 5:I2C-MS5525 (0x77) 6:I2C-SDP3X 7:I2C-DLVR-5in 8:UAVCAN 9:I2C-DLVR-10in Type of airspeed sensor.
more reading about it says it is actually 4525DO sensor, so, my setting was correct. what gives, then, it is not looking right to me…
i also did set it with the ARSPD_AUTOCAL=1, and i see it results with the ARSPD_OFFSET= 205.63 value, something from 205 to 209. looks a bit high i think. so, can it mean that it is unable to self-calibrate?
I will be testing it today. They just arrived. I will let you know what I find.
i suggest to revisit ardupilot documentation on the airspeed sensor. It says fluctuation <3m/s or so while stationary (with respect to air) is okay. Use=1 means sensor data is used for control modes where airspeed affects control outputs, like autothrottle modes. not sure about that offset, but why not do a few test flights (again, as the documentation suggests) using manual mode and then check if the airspeed value is reasonable? only way to tell I think.
I found airspeed source to be invaluable because I fly a rather unforgiving plane that is prone to stall, etc. if your plane is very low wing loading and high-powered, maybe you can power out of anything, and a sensor is not that essential.
what i see happening - if the value of ‘use’ is set to one, then the AS(airspeed) value is also showing as the GS (ground speed) value, and it looks like it then presumes model is in motion during initial controller startup and calibration - and that invokes long failsafe that switches board into the RTL mode - and it seems like it does something to EKF during that to assume there is a WP vector and then - after all that settles - it refuses to arm stating the ‘EKF yaw inconsistent by xx degrees’ - as the factual rotation of the model deviates from that imaginary vector for that waypoint for RTL that points, it seems, to the north. i am doing all that on the recent master.
all that happens in the basement where i work on the model, so, may be outside once it gets GPS 3d lock it would not act like that, not sure, i will try to test it later.
if ‘use’ param is not set then it looks like GS is not getting set by AS - but AS is still visible, so, if it is only needed for manual decisions, it seems to be better that way.
i understand documentation is stating that jumps up to 3m/s are ‘normal’, but i do not recall people having that. will see.
i’m seeing a consistent fluctuation at rest of about 3m/s. what you described sounds very odd. First off, GS should be GPS derived and never affected by airspeed at all, whether your airspeed is sensed or synthesized. When i’m setting up my plane indoors, GS stays at zero. I’ve never seen that EKF yaw warning before, but you might be able to find the reference in the documentation. Off the top of my head I don’t think it means you are off in terms of track to WP (you might not have any WP set up yet), it sounds like the EKF is having difficulty merging yaw data from different sources. Going into RTL is possible if you have RC failsafe enabled and your transmitter is not powered on.
most importantly, airspeed and ground speed have different physical meanings, measured differently, and used for different things. I suggest to look at mission planner more closely a few times to see what’s really happening. if you can fly safely in Manual, do so and fly a few patterns and analyze the logs afterwards. I’ve personally found both synthesized and measured airspeed to be quite reasonable, if noisy.
GPS is not in the lock mode yet at the time of the initial startup/powerup. GS immediately assumes AS value in that scenario and it triggers all the consequent set of actions. it is easily reproducible. all fluctuations of the AS are showing reflected to GS, it makes plane to jiggle its elevator as it thinks it is trying to stabilize in flight.it keeps jerking servos erratically for 30-40 seconds until it all settles and locks into non-arming mode complaining about EKF yaw inconsistency - between the actual correct yaw from compass and the imaginary WP vector. MP shows that vector on its screen as the orange line indicated ‘Direct to current WP’. Actual yaw is showing as the ‘current heading’.
switch to the RTL produces that WP. if GS remains at 0 then none of that happens. model is on the bench with no gps lock available, it is not about flying anything.
params on the model all set to the default from the MP with minimal alterations - i can try to drop it in here. sonic2.param (20.7 KB)
file has ‘use’ param set to 0. if i flip it to 1 - it starts that startup behavior.