I am testing T265 with apsync and 4.1-dev.
It's difficult to get the Tracking Confidence High message from a 45-degree camera, so there is a problem with flight stability.
Recently, we proceeded to Flat (DownForeward) to secure more stable flight performance.
I have a few questions.
-When I first tested it, I connected it to the GPIO 5V pin and the serial port. There was a problem. I have recently connected the power with a C-type usb cable.
Can I get better power stability with the recommended Pi Connectlite?
-Is there any difference between connecting a USB-serial cable and GPIO serial pin header?
-If you look at the log in Non-ROS, the date comes in 1980, but changing BRD_RTC_TYPES had no effect. Is there any way?
-On thien's blog I saw the story of using optical flow as a backup indoors. I wonder if using it as a dual will work better indoors.
These are the log files that have been tested recently. I use yaw data as a camera heading, and a downward lidar. I am using enable_auto_set_home=True in thien's script.
My drone tracks steadily and suddenly the Pose Jump data comes in and loses posture.
Maybe I'm doing the wrong parameter setting.
Thank you for always.
@rmackay9 Thank you very much.
I was supplying the 5v BEC from the main battery via the usb C type. Let's test with PyConnect lite and front camera. Let's also consider the Raspberry Pi time.
(I'm worried that the propeller will not see enough patterns when the camera is mounted in front of the lens)
Thanks to @thien94 and everyone.
VISP.PZ data is rising after IMU.Accz data is dropped as shown in the analyzed log. The drone also climbed and found the velocity and position data displayed in red on the mission planner EK.
In my previous row, I checked the same phenomenon as the log when'EKF variance' and pos horiz / pos vert variance error occurred.
I updated my shared drive.
I uploaded 2 log and tlog and video at that time.
Sorry it's not a YouTube video.
Guided and RTL tests were also conducted in this test. Where the pattern is clear, although the reset_counter increases, the ekf data stabilizes. In the RTL test, an error occurred as soon as the RTL command was input, and the drone was vertically raised. (RTL_ALTITUDE is currently set at altitude. The loiter speed, ascent and descent speed were also adjusted.)
I will test again by applying a vibration tape or vibration reduction mount, but do you have any tips to improve the IMU accel.z acceleration range limiting performance by modifying the EKF parameters?
Thank you very much.
but do you have any tips to improve the IMU accel.z acceleration range limiting performance by modifying the EKF parameters?
If you are referring to the T265: it's a combination of hardware / software limitation from the T265's internal IMU /
librealsense configuration. As far as I know, the acceleration range is not configurable. On that part AP is not related.
If you are referring to the FCU's internal IMU, you can check out this wiki: https://ardupilot.org/dev/docs/extended-kalman-filter.html
@rmackay9 Thanks for the response, I had originally set the EK2_GPS_TYPE to 3 (no GPS), but that didnt seem to stop the warning....then when I did disable to GPS checks it seemed the SITL didnt know how to yaw anymore, but if I enabled back GPS it would yaw. (I would send a setpoint with a yaw delta relative to body to test)
Have you (or anyone) been able to run the sitl without GPS enabled lately? I am on version ArduCopter V4.1.0-dev (77e52362)
Maybe this is a 4.x+ issue? I am going to open an issue in the repo I guess...
Oddly, I just tried again with turning off the GPS and GPS checks again, and it seems to work now...I can yaw just fine now.
I had initially setup a test case where I enabled MAV gps and was converting local position ned to a gps point, and was injecting it back in to the AP using the HIL_GPS message...and that also worked...but now the proper way works...odd