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.
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?
Reducing amount of log items to be logged seems solve the problem. Though I need to set very minimal logging option.
Hello, is there a way to retrieve this firmware from my cube black? Before updating to a newer firmware like the stable 4.1.0, is there a way to download this beta-5 version or do a backup from my autopilot?
Yes, MissionPlanner - full Parameter list, right hand side.
Isn’t that for the parameters? I am asking if there is a way to download the firmware currently inside the cube, to act as backup
Use the STM32CubeProgrammer be carefull to put in the correct amount of your memory AP, ex:1MB corresponds to 0x100000; 2MB= 0x200000. Read the complete content and save it! This way you will have everything including the caliration, etc. Later you can always download it, its very fast.
what we can use lidar with upward facing for proximity or avoidance ?
