If you’re able to test out that specific error case then create a mission with a LAND command with the Lat and Lon field specified. The bug was that the vehicle would always do terrain following (regardless of what Alt Frame was specified) as it flew to the specified Lat,Lon.
Here’s an example mission that would demonstrate the problem.
With this beta the vehicle should obey the “Frame” setting. So if the user specified Terrain then it will follow the terrain (using either Lidar or the onboard terrain database). If the user specified Relative or Absolute it will just fly at the current altitude.
So flying this kind of mission 3 times (each time with a different “Frame” specified) and just make sure the vehicle doesn’t do any weird altitude changes would be great.
Thanks very much for pitching in on the beta testing!
@rmackay9
I have flown all three missions with no issues (well issues I believe were my own fault see bonus log). Seems like the second attempt on all these auto missions would complete first attempt would loiter at WP2 without ever going to WP3 (land), again see bonus log as it was my first attempt on the absolute mission, this could also be because I have not tune the navigation at all and all are defaults. I never saw any negative behavior on the final land param it never would raise altitude to an unexpected level (well within baro and gps drift) Param File Terrain Absolute Relative Bonus terrain mission absolute mission relative mission @Leonardthall I have over 32 models (betaflight, arduxxx, and bench testing stuff) to keep up with in my radio and when I updated one I failed to load just that model and had overwritten all calibration info to the radio, these auto mission all yawed in the correct orientation after redoing calibration. We should stress that any changes in the radio you should always recalibrate it makes a huge difference!
On a side note I cannot find the param that would allow me to arm in auto and it seemed my takeoff was ignored when throttle was not above idle(more than likely normal behavior). I am sorry for my ignorance but a lot had changed in the 1-1.5 year hiatus so I am learning all over again!!!
Txs again for testing. I think the issue with the vehicle getting stuck could be that the WPNAV_RADIUS parameter set very tight (5cm). There’s no real advantage to setting it this low, it doesn’t improve accuracy of the navigation, it just sets a tighter check for the vehicle’s position before it can move to the next waypoint. Could you try increasing this to 100 (=1m) and see if it resolves the problem?
I wonder how this got set as I haven’t purposefully set that param unless scrolling with touch screen I accidentally set it (which I have accidentally done before) but again out of ignorance I could have misinterpreted a param and set the wrong thing on accident. I had a suspicion that it could be something easy like that or the nav controller as I haven’t tuned any of that yet. will set to 100 and repeat but I suspect you are 100% right!
On a side note i’m impressed that it did hit that wp radius, great job ardu dev team that’s impressive.
It can also be easily set from MP’s PLAN screen. I suspect we should remove it from this screen (for Copter at least) because it rarely needs to be changed.
So I 100% had that set to 0.05 from when I was messing with tiny rover using rtk, and I had not done any auto missions with any quads since then so it remained 0.05. What I guess I don’t understand is why it continued to stay 0.05 even through beta updates seems like it should always default back to a reasonable number each boot?
X4 using Pixhawk 6X (MP & QGC on Linux)
Further to my earlier post I have noticed issues with Accelerometer Calibration after bad Gyro health messages.
Had sensors already successfully calibrated using copter daily. But after changing to 4.2.3 beta got bad gyro health messages.
Tried to calibrate in QGC but failed just after placing drone level. Also in parameter list appears there is uncertainty about some sensors - This may be linked to my earlier report above.
In MP managed to get Accelerometer Calibration done and appeared to be OK after.
However, when using QGC again it once again reported bad gyro health.
…Needless to say I won’t attempt flying under those conditions.
I’ve (probably) reproduced the issue that you faced and it’s an issue with Mission Planner not the flight code in case that matters.
The issue is that MP maintains this “WP Radius” value on the local machine and it writes it to the vehicle when the mission is written to the autopilot. That “WP Radius” value does not appear to ever be fetched from the vehicle so if you ever set it to 0.05 then it will stay like that.
Yeah I am not sure why I set it that way (still a rookie but learning with all your great help) but had completely forgot about it. I would say its more of an “issue” with a novice user not really MP, shouldn’t be fiddling around with stuff fully don’t understand but thats why I built a rover they don’t fall out of the sky when you screw something up hahaha. I set it back to 100 and have had no issues hitting all WP.
Sorry I should have updated to latest beta when I flew today my bad. Will try and keep up on beta’s when I fly. I flew a bit today in loiter as well to run some magfit on the logs to fine tune the compass and what not. Auto mission log Magfit log
@andyp1per
Had originally also problems but then about two weeks ago it did work. But kept updating to latest versions as they became available.
Since I’ve posted the test result I’ve noticed there appears to be a difference between QGC daily (which I was using at the time) and the regular stable version.
The calibration never worked in QGC regardless of version copter I’ve used. Only in MP was it successful.
Despite my earlier remark couldn’t help myself and done a tethered flight this afternoon. Appears mostly working as expected but not sure as to how many sensors are actually working compared what’s shown in QGC summary page.
However, noticed a difference when arming in stabilise compared to arming in loiter (would usually never do this but stumbled across by accident).
Arming in stabilise = as expected.
Arming in loiter = appears for some reason front motors start spinning much later than rear motors. → Thinking about this I suspect it may be linked to the ground not being perfectly flat. In which case it may try to level drone but as rear is slightly lower than front it may attempt to level first prior to becoming airborne. (…but that’s just my thought). Will do more testing soon. (takeoff from a different surface)
Further testing / information.
“Interesting” is the very least I can say…(no offence intended, appreciate all that work going into making this work).
Whilst doing some testing today I suddenly got “gyros not healthy” message. But no matter what I’ve tried nothing resolved it. The calibration didn’t work at all (other than plain level), not in MP or QGC and couldn’t work out how I possibly can rectify this issue.
After taking a break I’ve decided to look at a few more parameters but didn’t find anything unusual. Eventually started FC again and the “gyros not healthy” message was gone. Thinking that would allow me to arm I turned RC on. → Suddenly the “gyros not healthy” message was back. I then had my suspicion in regards to arming checks as in between tests I’ve actuated a few more options. After disabling the “INS” option the “gyros not healthy” message was gone and I was able to arm.
But when I’ve downloaded the latest log file suddenly a series of beeps was heard in sequence and the LED flashed different colours and indicated different state of arming / disarming, GPS lock no GPS lock…at least that’s what I could make of it.
That message is a serious problem, you should resolve before flying. It’s worth trying to figure out which IMU is giving the issue by selectively disabling via INS_ENABLE_MASK (not sure which variant you have but there are 5 possibilities so try the values 1,2,4,8,16). Some of these IMUs have very recent support, so its possible there are driver issues.
Can you send a picture of HWID from MP?
Downloading logs causes CPU overload so the behaviour you see is not unexpected
@andyp1per
That is the weird thing: Neither before or after using the “INS” option in pre-arm settings did any message pop up regarding any Gyro problems. This only occurred during that option being used & the RC turned on. - No Gyro related message until RC was turned on.
Ok, so please try setting INS_ENABLE_MASK to 4, 8 and 16 respectively and see whether you still get the error. For each setting you should only see one IMU in HWID. My guess is that it is the 42670 which is the cryptic id “58” that you see there.
Will do.
But as mentioned there hasn’t been any messages at all since I’ve turned “INS” off again.
But will do as you suggest and see what happens when I activate that pre-arm option again.
Thanks
→ First confusing matter: In QGC (daily) - The options I have is 1,2,4 for the different IMU’s.
→ In MP I have the option of activating 1,2,or the 3rd. IMU, but no number option provided.
Now I know I may have that option in Full Parameter list, but that doesn’t really work due to screen alignment issue in MP when used on Linux systems. (I’m aware Michele Oborne fixed this issue recently but haven’t been able to get latest MP)
