I mean, where is the sample rate configured? I tried to compare a very old config and the latest one, and could not find anything related except for INS_FAST_SAMPLE, which was 1 out of the box. Shall that not mean that it engages 8kHz anyway even in the default configuration pre-loaded for PixRacer?
A few issues I’ve encountered prior to attempting first flight:
(Using X4 configuration, Pixhawk6X GS running on Linux)
Firmware upgrade not possible in regular fashion - need to use .apj file
- MP (1.3.77) list of firmware files is updated and beta version showing. However, despite regular connection working via USB, when trying to upload firmware a connection error -serial port- is displayed. (I do know can’t have live connection whilst doing firmware upload)
- QGC (daily) getting stuck on “downloading list of available firmware”
However, .apj file upload works fine, at least on QGC - haven’t tried MP.
Next issue:
In overview in QGC it shows a question mark under accelerometer. Does this mean a sensor has not been recognised ?
(Sensors ICM-42688-P & ICM-42670-P appear to be missing)
And finally (at least in regards to pre-filght issues):
RC-pre arm warning not working as expected.
- When FC is started whilst RC still off, no pre-arm warning relating to this is shown.
- However, when RC is power cycled (off-on-off) then warning will come up as expected.
(PS:Don’t take notice of the other warnings as always comes up when starting indoors - will disappear outdoors)
Sample rate is configured via INS_FAST_SAMPLE on Invensense CPUs. It is either 1Khz or 8Khz
I flew 2 batteries on two different quads with no issues what so ever, did a quick auto mission, loiter, guided and rtl. I saw no issues other than the yaw behavior seemed a bit off in auto and guided compared to last time I flew. please see attached logs.
FC: Pixracer R15
Firmware: 4.2.3-rc1
Frame:250mm on 6" props
ESC: SucceX 50A 2-6s lateset version of blheli_32 (39.2 I think)
BAT:3S
Power monitor: MRO ACSP7
Log 1 is a little hover flight to get some data for the notch filters
Log 2 is some loiter, guided and just general flying around
Log 3 is a little auto mission and a RTL
One thing maybe its me but it seems guided and auto yaw behavior has changed but again that could be me here is a log with some guided and what not on same quad running 4.2.2.
I am sure the yaw behavior was something that I failed to set right or am miss remembering how it was in 4.2.2. Either way dang you guys have made it so fun to test stuff now. I have about 5 quads that I will have to be setting up various notch filters on from ESC telem, to throttle based so I look forward to helping clarify some of the confusing stuff and making it easier for not so advanced users to use features. @Leonardthall had requested a user do a mission to test a bug and I cannot find the post but would be more than happy to test it out if he could refresh my memory on what it what it was something about auto mission and rtl with the quad climbing but I cannot for the life of me find it. I have logs from another 6" quad that I did identical mission and flight on but it was pretty non-eventful so I didn’t post them but I could.
1 Like
Hi @anon53993083,
Thanks for your help. The thread is here:
Unless you can reproduce the same problem it isn’t worth spending any time on it. I think Randy has already found and fixed this problem so I hope it is all done.
Your yaw performance looks pretty tight in the log so I am not sure what you are describing when you say it looked a bit off.
Its the behavior pointing the nose into the next guided point or way point in auto. In the pre 4.2.3-rc1 the quad would point its nose toward thew next way point (at least I thought it did) but in this is seems to not and I did not change any params just uploaded 4.2.3.
Hi @anon53993083,
RC4_TRIM 1495 PWM
RC4_DZ 20 PWM
So your yaw command is going below the 1475 and commanding a slow yaw. This is overriding the auto yaw control.
1 Like
@Leonardthall
I was just asking about this on edge tx discord as on all my models (with this radio) I have triple checked why this is as I do not have any trim or anything programmed into the yaw on my radio. I did just get new AG01 gimbals and have been fighting this since then.
I assume you calibrated your radio after changing the gimbals (both on the radio and then in the autopilot). A stupid question maybe, but better to ask a stupid question than miss a simple fix.
If you have calibrated your radio (I mean in mission planner on the autopilot) and you are getting this problem, then the centre stick position or reading must be changing. Maybe something loose in the physical gimbal?
Yes I have recalibrated within edgetx and arducopter which has not solved this issue. I have sent a request to the manufacture to correct the defect as I have 2 of these radios identical to each other and the other has not got any issues. This maybe a dumb question but can I just trim this out for the time being (or just use the other radio), I cannot remember but seems like using trim may cause other issues. I may have dreamed that up. This now dawns on me that this is 100% the reason why I had such a hard time autotuning.
If you simply recalibrate the RC on the autopilot it should set the trim value for you. However if you have done this already it must mean your trim is changing over time. So I would expect everything to work for a while then see the same problem again.
yeah seems like these hall effect sensors have a bit of drift on at least this one! which happens so no biggie will see if I can get it replaced and will go to my back up radio. But now I suspect that when I did some fiddling in edgetx companion and reloaded my profiles I needed to recalibrate again. Thanks for the help in identifying the problem and I will read that thread and see if I can fly a mission like that user did.
1 Like
Hi @anon53993083,
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!!!
2 Likes
Thanks for testing! Setting AUTO_OPTIONS = 3 will allow the vehicle to arm in Auto mode.
2 Likes
Hi @anon53993083,
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.
Impressive - great work on the OpenDroneId
Thanks Guys
1 Like