hello. After updating to 4.5.0, the vision positioning function using T265 does not work. If I downgrade to 4.4.4, it works fine. If you try to use T265 in 4.5.0, an error saying visodome: not healthy will be displayed on the HUD, and BAD will be displayed in the vision position status in the status window that appears when you press CTRL + F.
4.5.0 I will attach the parameters for testing.
20240403.param (21.4 KB)
Hi @pipk,
Thanks very much for the report. Could you try setting VISO_QUAL_MIN to -1 to see if that helps? Ideally I would like to see an onboard log as well so that I can (hopefully) check that the quality is defaulting to 0.
thank you.
I have a business trip scheduled starting Monday,
so I think my colleague will give me an answer after the test.
Have a nice weekend.
VISO_QUAL_MIN to -1 option was set
but same problem
Both log files of 4.5.0 and 4.4.4 are attached
4.4.4 works normally, 4.5.0 cannot activate vision position
Hi @jaeryang_park,
OK, thanks again for the testing and feedback.
I’ve added this to our 4.5.0 issues list and I will try and reproduce using my own T265.
Hi @jaeryang_park, @pipk,
I’ve tested with my own T265 and hit problems with both 4.4 and 4.5. The error I was seeing from the t265_to_mavlink.py script was
WARNING:dronekit:Link timeout, no heartbeat in last 5 seconds
ERROR:dronekit.mavlink:Exception in MAVLink input loop
Traceback (most recent call last):
File "/usr/local/lib/python3.6/dist-packages/dronekit/mavlink.py", line 211, in mavlink_thread_in
fn(self)
File "/usr/local/lib/python3.6/dist-packages/dronekit/__init__.py", line 1371, in listener
self._heartbeat_error()
ERROR:dronekit:No heartbeat in 30 seconds, aborting.
This looks to me like dronekit (which is used by the script) is timing out perhaps because parameter downloads were taking a long time and dronekit isn’t smart enough to handle this.
I was able to overcome the issue by upgrading the T265 to the latest version from thien.but if possible I would like to confirm that this is the issue you’re seeing as well.
Could I ask you to check the error messages from the script by doing this?
I hope that maybe @peterbarker and perhaps @LuckyBird might have some input on this.
If this is the proper fix then I will create a new APsync image for the T265.
hello. Thank you for your quick support. I will test it right away and give you feedback.
hi @rmackay9
We are using the latest version of T265 Python source (vision_to_mavros/scripts/t265_to_mavlink.py at master · thien94/vision_to_mavros · GitHub)
The view_log_t265.sh operation result log is attached here.
For reference, I did not use the apsync image, but built the environment manually in RPI4.
As shown below, it is connected to the Serial Port of RPI4 and Telemetry 2 of Ardupilot.
T265 ↔ USB 3.0 ↔ RPI4 ↔ UART ↔ Ardupilot
There doesn’t seem to be any problem with RPI.
However, what worked well in existing Copter versions prior to 4.4.x does not work in 4.5.x.
-- Journal begins at Sat 2023-04-15 08:17:27 BST. --
Jul 13 14:17:22 t265.sh[744]: INFO: Using default vision_speed_estimate_msg_hz 30.0
Jul 13 14:17:22 t265.sh[744]: INFO: Using camera position offset: Disabled
Jul 13 14:17:22 t265.sh[744]: INFO: Using compass: Disabled
Jul 13 14:17:22 t265.sh[744]: INFO: Using default scale factor 1.0
Jul 13 14:17:22 t265.sh[744]: INFO: Using default camera orientation 0
Jul 13 14:17:22 t265.sh[744]: INFO: Starting Vehicle communications
Jul 13 14:17:22 t265.sh[744]: INFO: Connecting to camera...
Jul 13 14:17:23 t265.sh[744]: INFO: Camera connected.
Jul 13 14:17:23 t265.sh[744]: INFO: Sending vision messages to FCU
Jul 13 14:17:24 t265.sh[744]: INFO: Tracking confidence: Medium
This is the ardupilot connection setting declared in the t265_to_mavlink.py file.
#######################################
# Parameters
#######################################
# Default configurations for connection to the FCU
connection_string_default = '/dev/ttyAMA0'
connection_baudrate_default = 921600
connection_timeout_sec_default = 5
Hi @romeowangza,
You should be able to connect to the autopilot with Mission Planner or QGC (or even MAVProxy) and use the MAVLink inspector to see if the RPI is sending VISION_POSITION_ESTIMATE messages or not. You could even check with 4.4.x vs 4.5.x to see the difference.
By the way, in the two parameter files provided above it looks more like the autopilot’s Serial1 port is being used because SERIAL1_BAUD = 921, SERIAL1_PROTOCOL = 2 (MAVLink2) and SERIAL1_OPTIONS = 1024 (do not forward packets) while SERIAL2_PROTOCOL = 11 (Lidar360). Are you sure that you’ve performed back-to-back tests with just the ArduPilot version updated?
Also if you choose to test with MAVLink inspector then you’ll need to restore SERIALx_OPTIONS = 0 so that messages from the RPI flow through to the ground station mavlink.
@rmackay9 thank you for your reply.
Yes, we have been using T265 by only updating the ardupilot version from the existing version 4.3 to 4.4.
It worked well without any problems up to version 4.4.x. (RPI does not change)
After updating the ardupilot firmware to 4.5.x, the VIO not healty message appears.
(Change to Serialx_Options = 0)
And even in the existing 4.4.x version, the VISION_POSITION_ESTIMATE message item does not appear in Mission Planner’s Mavlink Inspector. But VIO works fine.
I do not use a USB-TTL cable, but instead connect RPI’s serial number 1 and Pixhawk’s telemetry2 port directly.
Why don’t I get the VISION_POSITION_ESTIMATE message in my Mavlink Inspector?
But VIO works fine and everything is fine.
Hi @romeowangza,
So as mentioned above, if you choose to test with MAVLink inspector then you’ll need to restore SERIALx_OPTIONS = 0 so that messages from the RPI flow through to the ground station.
If i downgrade to ardupilot 4.4.4 now, i can see the screen operating normally. (although i cannot see the VISION_POSITION_ESTIMATE message)
Hi @romeowangza,
Ah, ok. So the only way I can imagine this happening is if the RPI script is sending the vision-position-estimate messages using either the AutoPilot’s sysid+componentid or the GCS’s sysid/componentid.
If the script is sending as the same system id and component id as the autopilot then this would also explain why it has stopped working with 4.5.0 because of this change:
If you like I could create a special version of 4.5.1 with just this change backed out.
Hi. @rmackay9,
yes. I can confirm that the VIO works well in some parameters, and in actual indoor flight tests, it works very well. (version 4.4.4)
If I update again to 4.5.1, VIO no longer works.
Since nothing has changed between RPI4 and the script, it seems to be a different problem.
How can I solve this?
Sorry for so many questions. Please help me.
Hi @romeowangza,
I’m pretty sure the issue is the conflicting sysid/component-id.
If you’re ok with it could you try this modified binary?
This binary is Copter-4.5.1 but with this change reverted and then built for the MatekH743-bdshot.
Hi. @rmackay9
I have now looked at the T265’s transmitting script again.
As rmackay9 said, the source component number was transmitted as 1 when transmitting.
When I change this to a different number, the VISION_POSITION_ESTIMATE parameter is visible correctly with component ID 93 in 4.4.4.
Hi @romeowangza,
Excellent, and the EKF seems to be consuming the visual odometry? E.g. the “Visodom not healthy” messages have gone away?
