Option 3 is actually the same as 1 (running the Python script)
I hope we don’t need to flash the system since we want to keep some existing work.
As long as you can install all the required packages it should be ok
I've started working on a new EKF feature to allow switching between the external nav (i.e. T265 or similar) and GPS for the position. It's very much still a work-in-progress but the code is here if anyone is interested: https://github.com/rmackay9/rmackay9-ardupilot/commits/ekf-pos-source1. At the moment the position source can be manually changed using an auxiliary switch but eventually I hope to make it automatic based on some heuristics of how reliable the two sources are.
I've discussed this with Tridge and PaulR already and have their agreement that the approach is OK. There are some open discussions including:
- what is the minimum feature set we need before it can be merged? i.e. is switching between external and GPS enough or do we want a bigger change?
- Tridge suggests we should move the sensor buffers into this new class.
- Paul wants the altitude (aka Z-axis) moved into the new class to allow more defined behaviour of switching between the sources
@patrickpoirier51, Txs for that, I had not considered this. I've now discussed with Tridge and we think they are complimentary and shouldn't conflict too badly. So the GSoC sensor affinity project allows the 1st and 2nd GPS (for eample) to be used by different EKF lanes while my new class would allow specifying whether to use GPS or External Nav for both lanes. Discussing this makes it clear that it should also be possible to have one EKF lane using GPS and the other using External Nav.. this is where the two projects meet perhaps.
@rmackay9 Yes I am sending yaw values as well as position. I also send linear velocity when providing LOCAL coordinate setpoints (I know this is somewhat out to the scope of my question but I was hoping to do the same in BODY coordinates when thie current issue is fixed)
Talking about EKF, there's new ROS package called fuse, succesor of robot_localization. Must have for those interested in special motion models like e.g. ackerman. https://github.com/locusrobotics/fuse
I´m testing this https://support.intelrealsense.com/hc/en-us/community/posts/360037261873-d435-and-t265-together-on-nvidia-jetson-tx2 I think the issue is solved for now - 30 minutes without reset
@RoboBil, yes, the "pose jump" message means that Thien's scripts noticed that the position was moving impossibly quickly. This points towards a camera issue and is probably not an ArduPilot or script issue.
I´m testing with rover, I was doing some things today but I will test tomorow and return to you
"...Assuming you received from Intel an engineering sample of T265(TM2) device, enable support for it in the SDK.."
TM2 stands for a very particular case?
I think TM1 is Intel's internal code name for T150, a tracking module using a monocular camera and IMU that was only available for "big customers" https://github.com/IntelRealSense/librealsense/issues/1269#issuecomment-374635795 and has been discontinued. The "remnant" of this module can still be found in the D4xx datasheet.
TM2 is then the code name for T265.
TM2 is then the code name for T265.
@thien94 I have create a script that can steaming T265's fisheye frame to RTSP by pyrealsense2,share the link in case that can help https://github.com/VimDrones/realsense-helper/blob/master/fisheye_stream_to_rtsp.py
@Huibean, that's very interesting. We are hoping to work with ANU (Australian National University) who is also working on an visual odometry system (open source of course) and Tridge suggested it would be good to be able to get it working in parallel with the T265's built-in algorithm so we can compare performance. I'll pass a link to ANU.
@thien94, @patrickpoirier51 (and anyone else who is interested), I realised that our APSync scripts are hardcoded to grab librealsense 2.33.1. https://github.com/ArduPilot/companion/blob/master/Common/Ubuntu/librealsense/install_librealsense.sh#L16
I think using a stable release instead of some random version (aka master) is probably a good idea but I'll have to remember from now on to update this version as Intel releases improvements.
I was also thinking that it might be good if the scripts were enhanced to show the firmware version being used. I guess for the T265 it's somehow updated automatically so the librealsense SDK version always matches the camera. This may be different for other cameras. Anyway, not urgent at all just a thought..
@ed-muthiah, yes, it's Rob Mahony. He did a presentation at our developer unconference this year. https://www.youtube.com/watch?v=nO_y6BRBBOg
@apinxiko maybe Randy's solution would help: https://github.com/IntelRealSense/librealsense/issues/5527#issuecomment-600422893
@paulzpz Would it work if you connect the RPI camera without the display?
You can run
realsense-viewer to see all messages from librealsense and inspect the problem. If it's something specific, it would be better to create an issue on their repo https://github.com/IntelRealSense/librealsense
Hi Randy, I think this version of librealsense is precompiled right ? after the weekend testing, I really don't have more the usb issue on jetson after compiling with the TM2 . how I'm using on a rover, I ran for at least 8 hours - with time to swap and charge batteries and no issue with usb - just when the battery goes bellow 10.8 volts. One thing I'm trying to understand is the camera after booting the jetson is not detected by the kernel, nothing on dmesg, and sometimes this is not an issue, starting the t265_to_mavlink works fine, sometimes I had to shutdown the jetson, remove the cable, boot and just after that plug the camera. This was happening more when I was using the cable provivde by intel, after swaping the cable to a Wstern digital cable I until now just had 1 time this issue.
I saw someone testing with rover, I cant do guided mode on rover, there are something I can read or study to use with rover? is my first try with rover
@juvinski, @RoboBil is also testing with Rover. I have not specifically tested Rover but it should work. You've setup the T265 and ArduPilot according to the wiki? https://ardupilot.org/rover/docs/common-vio-tracking-camera.html. Some key points, it's best to use Rover-4.1.0-dev and enable the EKF3 (explained on this wiki page). You'll need to set the EKF origin which can be done easily using the Mission Planner (also explained on the wiki page). It is easiest if you use an RPI4 with the standard APSync image to remove the chance of issues with the companion computer but if that's not possible, it's best to provide an onboard log (from the autopilot) so we can see if the companion computer is correctly sending the required messages (we will look a the VISP and VISV messages).