Hi @LuckyBird, Thank you for the contribution. I have just tried to implement you solution on my Quadcopter that is running a Pixhawk3 Cube (Black) and a raspberry pi 4. Everything seams to run fine and I am able to track whilst in Attitude hold but when I switch to Loiter the my quadcopter hovers for about 2 seconds before the EKF sufferer variance and i loses tack completely. I have checked check my settings against the recommended setting but i’m unsure what is causing it. Any ideas would be appreciated.
Hi @lipp8888, it’s best to analyse the log to figure out what went wrong. Specifically, see if the VISO data is correct, and compare with other enabled sensors (baro/range finder for z, compass for yaw) that can cause the variance.
Alternatively, you can do handheld tests (just move the vehicle around when disarmed, in loiter mode) and use LOG_DISARMED param to save the log to avoid accidents.
Hi @LuckyBird, thank quick reply. Just let you know, I’ve had no problems moving around doing a hand held test, tracking seem to be solid. I’ve also had no issue with tracking when flying in ALT HOLD mode only when i switch to Loiter. I’ve reviewed the logs an it seems I get a horizontal variance error moments before losing track. I assuming this may be caused by compass errors. I’ll have another look at the setting and have a play this weekend. I’ll get back to you with anything i find.
Hi.
Assembled configuration:
Pixhawk
Raspberry Pi4
Realsense T265
Arducopter 4.0
Installed scripts as written in the article. Ground tests were conducted. Everything on earth is working correctly. At the first test flight in the hall, the drone smoothly went forward and up. Switching flight modes did not affect the control.
Logs in the application. Please help me understand the reason why the drone was not controlled.! 2020-05-27 20-13-05.tlog (614.2 KB) 275 01.01.1980 2-00-00.bin.zip (742.6 KB)
I don’t see the copter icon on the map nor the vision data (VISO) in the tlog, so it’s probable that you didn’t set EKF home origin (Ctrl-F -> Seth Home Here -> Set EKF origin).
The tracking confidence changed briefly from medium (default value at start) to high to FAILED, which is very bad. Had you enabled the fusion (point above), the control would become haywire and crash even. The environment you are flying in might be very challenging for the T265, so next flight you might need to be a bit cautious.
Regarding point 2, some typical things that will affect the performance of the tracking camera:
illumination: too bright/dim -> bad,
visual features: the camera can see abundant corners, edges, various patterns etc-> good tracking, while completely white/bland/repetitive patterns -> bad,
occlusion: nothing should block or always stay in the field of view of the camera, you should check the camera images to see if any parts of the vehicle is in the view.
vibration is also a major factor, so add some damping for the camera if you can.
Thank you, your advice really helped.
But there is still an unsolved problem. I have a drone for indoor flights with a shockproof design.
Now, during the flight, everything works well, until the moment of impact against the wall. The log shows that after the hit, px and py change their values to unrealistic. The drone is trying to fly up. How can this be fixed?
PZ shows negative values, so it should be?
Thanks for the answer.
PZ is negative due to how the coordinate frame is defined (NED-north east down, so positive z is pointing down). After the crash, the tracking data from the T265 was not reliable anymore (the position rapidly increased despite the actual movement, and the tracking confidence became FAIL), hence if the controller used that wrong data the behavior would be erratic.
This is one area of improvement that will come in future developments on the ArduPilot side (disregards bad data from the camera, uses the right kind of data when needed etc.). At the moment though, just keep in mind that the camera has limitations and always be ready to retake control during flight.
hi, I was able to get out and do some more testing on the weekend. Still had the same problems I’ve been having with the quad copter loosing track. It seems I may be an issue with my flight controller as is switches IMU just before I get the error. I’ve attached a video of the flight and the log files I have collected. Any advice would be welcome.
Hello
As @LuckyBird wrote in the method, once the HOME position set, did you “walked” the vehicle in Loiter mode (like a square or figure 8) to check system before arming?
Then you can takeoff in loiter and do simple manoeuvre before going more challenging.
I think the T265 is getting lost by lack of visual references in the near surroundings as it is green grass. Don’t trust the confidence level for this as it will send HIGH even if it has skipped tracking many meters. Thanks for testing
HI, I have tried to disable my compass in the past with the same results. I also get large EKF errors and a compass fail warning (very annoying). I found if I enable one compass I get the most stable EKF.
It might be a while before i can do any more testing but I’ll make sure I get some logs for flying with the compass disabled. I’ll also try enabling LOG_REPLAY and see if I can get some more details about the failure.
Out of interest can you tell me what setting you are using for EK2_IMU_MASK,? mine is currently set to 3 so it is using both IMUs. I was thinking of trying to use just one IMU.
I have complete the ROS part, and I want to autonomous flights , like this .
But I found this tutorial is use ROS, if I want to use this (in this page) , how should I do?
hello,im using raspy 3B+ and Px4 2.1 with fimware 4.0 ver
when im running t265_to_mavlink.py i get error message wrong elfclass:ELFCLASS64
im downloading the same pyrealsense2.so and librealsense same as the tutorial and place it in the usr/local/lib and librealsense/build but still getting error wrong elfclass
please tell me whats wrong.
thanks and wish to hear the answer soon
I have not encountered this error before, but a quick search seems to indicate that this might be an architecture error (examples 1, 2). I suggest posting the error on the RPi forum to get better help for this issue. Otherwise, reinstalling OS might be of help.
