But in my case the drone isn’t “fixed” with the cage. The cage can turn around the drone. So my question is, if I put a downward RF sometimes during flight it would be possible that a cage branch pass in front of my RF for a very short time, so what will be the reaction of the drone in altHold ?
Because I supposed the EKF fused multiple data for altitude like accelerometer, baro and RF, so if I have just a suddenly change in RF value and no changes on my accelerometer and baro the copter will not take RF values ?
No it’s a carbon cage, juste to wrap the drone like a drone soccer, but with a cage that can “turn”, I can roll against a wall.
I can draw a plan if you want to visualize the system
Carbon is a conductor but generally when it is bounded with thermo plastic like in 3D print there is much less conductivity.
A rule of thumb often used for Faraday cages to prevent transmission is that the holes need to be no larger than 1/10 of the wavelength of the signal. So depending of the frequency the holes should be bigger than 2 cm for 2,4 ghz wich seems to be the case.
Yes the holes are bigger than 2cm, I believe from memory the smaller hole is a pentagon of 10cm. So for you there is no issue if I have a branch that pass in front of my RF ?
I’m just afraid to try and when a branch passes in front of my downward RF that my drone reacts badly and suddenly gains altitude to compensate for the small measure taken by my RF.
The question I ask myself is when the branch will pass in front of my RangeFinder what will be the reaction of the drone ? Let’s imagine thaht I’m flyaing at 4m and suddently a branche pass in front of my RangeFinder, the distance meseaured by the RangeFinder will be 25cm (it will be always the same value), will my drone suddenly gain altitude to compensate for this measurement or not?
My first idea was to compile my owm version of ArduPilot and trust a rangefinder if the value is between RNGFNDx_MIN_CM and RNGFNDx_MAX_CM but parameters gave by @bigboy061293 is a good starting point
I think this is the good solution to use RNGFNDX_GNDCEAR@bigboy061293 I’ve just looked inside the source code and in AP_NavEKF3_Meseaurements.cpp inside readRangeFinder function I have
// limit the measured range to be no less than the on-ground range
rangeDataNew.rng = MAX(storedRngMeas[sensorIndex][midIndex],rngOnGnd);
I would probably use 2 rangefinders, that way your very unlightly to have both blocked at the same time. but you should be fine with 1 as the baro can hold it between readings.
