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?
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
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.
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.
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?
@rmackay9 thanks - I always wait for prearm ready in poshold which I guess doesnât show on this graph. So although I took off in stab, I had waited to get good GPS lock etc. Iâve tried to zoom in on the first log (53) below to show the problem (very hard in mission planner when there are spikes in the data). What I observed was radio failsafe -> SafeRTL/RTL but no attempt made to RTL it just descends. Iâve graphed the EKF inconsistencies for this time period and none go over 1. GPS is ok, MAG just about ok despite a spike when the throttle bursts when the failsafe hits. So I would expect a proper RTL, but you can see from the baro that it just goes down. Also if itâs landing shouldnât the mode say âLANDâ? And if the EKF doesnât have a good position estimate wouldnât there be an EKF error?
Morning Randy. Hope all is well.
Wanted to share an observation I made this morning. First itâs raining stillâŚgrrr.
Second I decided I was going to flash the GNSS with new firmware so I went to the shop and pulled the connector on it to connect up the can port to USB device i just gotâŚI ordered because I had a feeling I needed it.
Much to my surprise I found the Can port terminator on the second port was missing. Well the resistor was anyway. I donât know if this is the reason for the sick GPS or not but the canbus was not terminated. I made up a new one, but this time I soldered the resistor to the connector contacts so they wonât fall out again. Of course the whole terminator plug could but thats unlikely. Anyway if it ever stops raining I will try again.
https://drive.google.com/open?id=1ICbzNjJDgmEjWEYS4H0FFMRg1s_G1Xcj
Some logs of mro pixracer on a tarot 650, number six is an autotune.
I have many vibes and donât know where they came, on autotune disapear for exemple, itâs shocking watch the vibes get off on autotune process.
Pixracer led, stays blue without gps fix, goes blue turquoise on gps fix, and deep blue on arm.
Btw, I am dreaming every night with the message âhardware safety switchâ XD
In general copter is now flying well - have not seen any more EKF issues, but have these three really concerning problems:
