Ok
I have a Canport interface coming and will have a look. Also have a regular I2C version with the same mounting that I can switch to. Just the Zubax is supposed to have better accuracy.
Thank you for checking.
I am very disappointed the Zubax is a problem…dang
I can confirm that on four different PixXXX same behaviour is showing with four different micro SD cards:
- Arducopter 3.6 on NuttX: No problem
- Arducopter 3.6 on Chibios: Bad loggin and “No IO thread heart beat”
Perhaps something isn’t right in the ChiBios drivers?
Almost certainly - but OTOH it could be our use of them as well.
Could you try a binary created from ArduPilot’s master branch to see if
whatever the problem is still with us, please?
Henri
Peter
Visit Topic or reply to this email to respond.
In Reply To[45.png]
peterbarker
November 1 @peterbarker Thank you for answering. Excuse my ignorance, I don’t know what are class 4 or 10. They’re different classifications of SD card;
it’s written on the packet when you buy it, often on the card itself. Where do I find version 777b4c8cfe09ae05795385a1f027b8d57184d959 patch? “git sh…
Visit Topic or reply to this email to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, click here.
Peter Barker | Programmer,Sysadmin,Geek.
pbarker@barker.dropbear.id.au | You need a bigger hammer.
:: It’s a hack! Expect underscores! - Nigel Williams
hi, i had a bit of a nerve-racking thing just now. flashed 3.6.0 into a model that has issues and tried to fly it.
https://drive.google.com/file/d/1XRDqsKqREzC6JK2zRCnBz4N-yKPRK9pJ/view?usp=sharing
2 questions after that. first, most important - would be nice to understand why after landing in alt hold mode and placing throttle all the way down it refused to disarm and kept spinning props. that was unpleasant to deal with.
second, upon takeoff it flew seemingly ok but sideways, with a tilt to the right side and in alt hold started to drift to the right. it was under control and would fly back and did not crash, but it was not normal. it left itself tilted and remained tilted all the way in the air.
with dev master code it did not do it - same model.
and last, why do we have a consistent deviation between dev master that got all radio commands set to the RC_OPTIONx and 3.6.0 seem to be on SERVOx_FUNCTION? it just led to quite masty results as frankly i did not remember this aspect at all and assumed if all master dev cycle was using RC_OPTION now then 3.6.0 would also be on the same notation, but it was not.
and between flashing from dev to release it somehow lost all settings there so i was left with no kill switch.
ok, i am lost now, completely.
i had old functions like ‘3’, ‘17’, etc on the RC_OPTIONS to control the craft. like, to do autotune, kill motors, etc. hope it is understandable.
what is not understandable at all - i look now at the list of functions provided in the mission planner and i think i see PLANE functions?
i got code from here: http://firmware.ardupilot.org/Copter/stable/KakuteF7/ and it says copter upon bootup. fuction 17 in the servo list says ‘DifferentialSpoilerLeft’. what spoiler on a copter? WTF?
how to map it all back now if i want to use a stable build instead dev master? motor kill switch does not seem to be in that list at all anymore.
is it an another idiocy from MP software or is it correctly showing how 3.6.0 code expects those values to be? as if i flash back dev master it shows me options inthe RC_OPTIONS, so it is still there, but 3.6.0 refuses to see it and react to it.
i just tried setting those servo options to same exact values i had on same RC channels - 17, 3, 33, etc - 3.6.0 code does not react on them. so, is it indeed set with plane servos?
boot signature:
PreArm: Need 3D Fix
u-blox 1 HW: 00080000 SW: EXT CORE 3.01 (107900)
EKF3 IMU0 tilt alignment complete
EKF3 IMU0 initial yaw alignment complete
EKF3 IMU0 initialised
EKF3 IMU0 buffers, IMU=11 , OBS=4 , dt=0.0120
EKF3 waiting for GPS config data
GPS 1: detected as u-blox at 115200 baud
INS: alloc 6144 bytes for ISB (free=178448)
Frame: QUAD
ArduCopter V3.6.0 (2eedcf56)
KakuteF7 00410023 34345117 39383339
ChibiOS: ff603d11
Barometer calibration complete
Calibrating barometer
Refresh the parameters on MP
Use the CTRL+F
Also, why don’t you start a new thread related to next version of Copter (3.7dev)?
Luis, what do you mean? why would i start anything about 3.7 when it is ArduCopter V3.6.0 that misses all settings for radio options?
posted log is from 3.6.0 that did not disarm and did not respond to any of old servo or RC codes.
I too am having trouble disarming sometimes - I think the copter has got the altitude wrong so thinks it’s still flying.
yeah, but somehow it does not think that with 3.7dev.
here is what after all refreshes and params regeneration it shows for servo options - it is BS.
0:Disabled 1:RCPassThru 2:Flap 3:Flap_auto 4:Aileron 6:mount_pan 7:mount_tilt 8:mount_roll 9:mount_open 10:camera_trigger 11:release 12:mount2_pan 13:mount2_tilt 14:mount2_roll 15:mount2_open 16:DifferentialSpoilerLeft1 17:DifferentialSpoilerRight1 86:DifferentialSpoilerLeft2 87:DifferentialSpoilerRight2 19:Elevator 21:Rudder 24:FlaperonLeft 25:FlaperonRight 26:GroundSteering 27:Parachute 28:EPM 29:LandingGear 30:EngineRunEnable 31:HeliRSC 32:HeliTailRSC 33:Motor1 34:Motor2 35:Motor3 36:Motor4 37:Motor5 38:Motor6 39:Motor7 40:Motor8 41:MotorTilt 51:RCIN1 52:RCIN2 53:RCIN3 54:RCIN4 55:RCIN5 56:RCIN6 57:RCIN7 58:RCIN8 59:RCIN9 60:RCIN10 61:RCIN11 62:RCIN12 63:RCIN13 64:RCIN14 65:RCIN15 66:RCIN16 67:Ignition 68:Choke 69:Starter 70:Throttle 71:TrackerYaw 72:TrackerPitch 73:ThrottleLeft 74:ThrottleRight 75:tiltMotorLeft 76:tiltMotorRight 77:ElevonLeft 78:ElevonRight 79:VTailLeft 80:VTailRight 81:BoostThrottle 82:Motor9 83:Motor10 84:Motor11 85:Motor12 88:Winch
Took the day off because it was sunny and flew 8 batteries 
In general copter is now flying well - have not seen any more EKF issues, but have these three really concerning problems:
-
I am getting a lot of radio fail-safes, not sure if this is hardware or software - they clear quickly - I tried mounting the aerials better (I have a lemon diversity rx) but makes little difference, but when this occurs it tries to switch to M_21 (that’s what it says in my OSD) and then tries to land. I have to quickly flip modes to recover. Graph and log below. What is “M_21” and how do I set the radio fail-safe to something sensible? APM Planner says that a radio frame was delayed and it could not initialize the fail-safe. If I switch off the TX all works as it should (RTL). Can I increase the timeout somehow?
https://www.dropbox.com/s/bw0ptkrmtqeldox/00000053.BIN?dl=0
-
My altitude is all over the place. HAlt in my OSD display seems to flip between 5m (relative?) and 190m
(msl?). Doesn’t matter in stabilize but causes all sorts of problems in RTL where the copter keeps trying to descend rather than RTL. However if I deliberately RTL all is fine. Also see Altitude in MinimOSD relative to Sea level ?! I may be confusing two issues here. Second log and graph also below.
https://www.dropbox.com/s/olhophn5wq9zdu3/00000057.BIN?dl=0
-
What @Paul_Atkin1 says - copter often does not detect it has either landed or crashed and the motors keep spinning and I cannot disarm
1 Like
ok. so, i flashed back 3.7 dev. i see now with the last master code running the values of SERVOx_FUNCTION options stay the same.
also, upon flashing 3.7 the set of RCx_OPTION options appears and model starts reacting on them.
with 3.6.0 it was all ignored. if i am doing something wrong i would love to know what that is. as no reboots, refreshes or updates with 3.6.0 did not make any of channels 7-16 to work and respond to their programmed functions.
so far i presume that in 3.6.0 all the new code for new RC options was skipped but code removing old SERVO function mappings was applied, so in result it all got screwed.
as i fixed all issues in 3.7dev i re-tested it in there on the same model landing it in alt hold and pos hold. in both cases it behaved correctly - after landing it would still spin props, then reduce props spin speed to initial one at arming state, and then in 1 sec it disarms and props stop.
with 3.6.0 it was not reducing speed of props to armed spin speed, it kept it spinning at the same rate as after touching ground, way higher than an ‘armed state’ initial speed.
As Luis says, I think it would be good to create new topics for some of these issues…
In any case, the OSD altitude issue is likely the issue discussed in this thread (I think you’ve found this issue as well). I’ll look into this and discuss what to do with the other devs as well.
The OSD displaying M_21 is probably because the OSD doesn’t know about the new modes including SmartRTL which is 21.
The log shows a very significant number of GPS Glitches and one case of an EKF failsafe (that did nothing because the vehicle was in Stabilize mode). I suspect there’s actually a compass issue. Certainly the EKF is not happy with it’s position estimate. Have you tried flying this copter on 3.5.7? 3.5.7 is still available using the MP’s “Previous Firmwares” link. I think this would be a good test because I suspect this may be a general setup issue rather than a 3.6 firmware issue.
I guess I can try it given more good weather. But why does the copter try to land? At least that’s what I think it is trying to do. I would be happier if it actually tried to RTL, but every time it just descends leaving me running around the field trying to find it. I’m 100% certain that it’s the radio fail-safes causing this behavior. FS_THR_ENABLE is set to 4.
@andypiper,
In general the failsafes do what you request but if they can’t they will just Land as a last resort. So for example with option “4” (“Enabled always SmartRTL or RTL”), it will try to SmartRTL but if it’s buffer is full it will fall back to RTL… but if the EKF doesn’t have a good position estimate then it can’t control it’s position and it will switch to Land.
Btw, I think in this log that the vehicle was armed in Stabilize mode… Normally I first switch to Loiter to ensure that I can arm in that mode (i.e. switch to Loiter and check the LED is green)… then arm. I just want to point out that the requirements for arming are less strict if arming in Stabilize mode so you can’t be sure that you’ll be able to switch to an autonomous mode later.
I think this confusion with the display of parameter values for either RCx_OPTION or SERVOx_FUNCTION may be a ground station issue. With the MP in particular it sometimes makes guesses of which firmware you’re using (i.e. beta vs stable, Plane vs copter) if it’s not currently connected to a flight controller. In particular if Plane has been used most recently then it will show Plane parameters. I’m not saying this is definitely the issue you’re seeing, I’m just pointing out that I’ve seen this.
Anyway, the RCx_OPTION stuff is 3.7 so we really should move this discussion to a new topic.
(I too am having trouble disarming sometimes - I think the copter has got the altitude wrong so thinks it’s still flying.)
I have the same problem sometimes, it started happening in Copter-3.6.0, instead it never happened in copter-3.6.0-RC12.
Re landing detection, if you have a log we can have a look. It’s unlikely that the behaviour has changed since -rc12 because the changes are so small (the list can be seen here) and not in the relevant area of the code. It’s more likely to be a tuning or environmental issue but a log will help make it clear.
As a side note, the landing detector makes the following checks:
- motors have hit their lower limits
- vehicle is not accelerating
- the vehicle’s descent rate is less than 1m/s
- the range finder (if present) reports less than 2m
The most common reason for the landing detector to fail is the first item, “motors have hit their lower limits”. if the vehicle is trying to do position hold, if the position error is too big (i.e. the vehicle is far from where it wants to be) then it will continue spinning up the motors trying to move itself… but it can’t because it’s on the ground already.
Thanks Randy,
I’ll wait until tomorrow to put the quad in the air, then I’ll see if it happens again.
I deleted all the log.
Ok, i think i am not stating it right. I was unable to use easy mode switch - option 3 - as in 3.6.0 it does not seem to be a place to put it. I was unable to set autotune switch. Code 17. Where should it go? Do i miss something obvious?