If you’ve got a log I’m happy to take a look to see if there is anything re the Loiter flight that looks unusual.
1 Like
I going to send one but doing the usual checks and calibrations…
Regrading ground effect i did a quick video:
in the video you can see the legs touching. I think the legs should clear the bricks and never hit is best. It is very hot and I have the cold forced air on inside of the shop not sure if that’s messing the distance.
Video of Loiter loss of altitude and a little shaky. in the video you can see some loss of position and oldy jerky. We have wind and it’s the billowing type meaning the wind is down low. drop in altitude is right before i take it down. No major loss of control.
I was going through my radio receiver settings (openLRSng) and I see a setting for “minimum ppm sync time (us)” and its default is 3000. Is that ok?
edit got a reply from the openlrsng developer, “It denotes the time in us for detecting the channel 1 in PPM signal, 3000 is a good choice”
you should send logs
Can the vertical BendyRouler be used with two unidirectional rangefinders poiniting forward and down? Or do you need a 360° lidar for that?
It would be interesting to use a 360° Lidar, but rotated 90° on it´s side to basically measure the terrain directly in the flight path. This may also be suitable for fixed wing surface tracking.
Hi @Hoehenarbeit. You just need one forward facing rangefinder for it to work. 360 lidar, although helpful at times, is not compulsory
Your second comment on rotating it 90 degrees has been talked about before, but it is not currently possible to do
Hi @Mallikarjun_SE,
So it looks like the main loop got stuck during the motor test. It was after doing this test that the message started appearing?
I have a board with the same issue with 4.1-beta5. When we test a motor the error raises and it disconnects from mission planner.
1 Like
Is this ok? Seems like they should track about the same
Is it because I don’t have IMU_FAST logging option? I was looking into vibration after watching Yuri’s latest youtube video. Thinking I should probably not look at the IMU accx… etc values because maybe its not all being captured by the logging and I should instead look at the vibex… Old habits hard to overcome (used to look at acc values before the vibe was added maybe 5-6 yrs ago).
Often I make mistakes so maybe this is some user error?
This is a Pixhawk1-1m running beta5
log https://mega.nz/file/8KwGzYSY#q5-A_tAxxQZUyFOJIywWIROIkbhFtOyq3tG-CxnSASY
I forgot to mention its an old log as I haven’t flown recently. So any parameter updates (like randy asked me to turn off the onboard mag) will show up in my next flights. Waiting for beta6 as it restores my lcd 
I will post an update to this when I next fly
I wonder if this could be an electrical issue. The multirotors are kept in my basement where the humidity this summer has been pegged at 99% on my digital meter for a few months and now with a little dryer weather its down to 85%. I had a transmitter short out, which worked after I removed some solder debris and washed any potential flux off with iso alcohol. My television screen was full of artifacts while it was at its most humid. Since its dried a bit its returned to normal. I wonder if extreme humidity and rust/shorting is causing my strange graph? Something to consider
@rmackay9 every time on a very first arm after a power-on or reboot I see following momentary climb rate increase:
It always does the same, on first Arm. I’m not sure if this is a problem, but it looks strange.
Surprisingly I found that this somehow related to logging. When logging is disabled or LOG_DISARMED=1 - this doesn’t repro.
So I assume with default config (logging enabled + LOG_DISARMED=0) in the moment of arming the log initialization could introduce some lag to the EKF system.
EDIT: this happens on iFlight BeastF7 (internal mem chip)
The initial log setup on arming is pretty expensive - we throw a ton of data into the logs and the flash chips are not very fast. In addition I don’t think I was able to give the flash chip on the Beast F7 its own DMA channel, so its competing with the IMU most likely as well. Net-net - the CPU and DMA load could easily cause the EKF to get out of whack IMO.
Thanks, that’s makes sense.
Now I’m almost sure this could be a real problem: if I take-off the copter right after first arming (when the climb rate still jumping up and down) then I may have some unexpected behaviors, like I’ve described in Copter-4.1.0-beta4 release for beta testing
Also in such cases I often see the climb rate on my OSD has a constant offset of -0.3…-0.6 m/s. That’s is preventing copter from safe landing detection as well.
Though I’ve tried to not to takeoff at first arming, but to make several arm-disarm cycles. But there are also some issue that I’ve described in https://github.com/ArduPilot/ardupilot/issues/18104
Hope somebody could help me to dig to the bottom of this, because there is no safe way to fly this setup at moment.
I tell a lie. dataflash has dedicated DMA channels on that board - so there is no contention. So this is probably more subtle and related to CPU load. That said log writes should not require CPU because they use DMA. So I remain convinced that its down to the flurry of logging activity on arming, but what this is actually provoking I am not sure.
What do you have LOG_FILE_DSRMROT set to? Try the opposite.
We’ve had some patches go into the beta series after beta4 which are designed to fix this problem.
Please try beta6 - what could possibly go wrong?