Thank you @rmackay9 @thien94 @stephendade . If I use any of the listed methods for non-gps navigation, So will I have to make changes to my script in dronekit-python. Currently I arm the in guided mode, take off to a specified altitutude, then use velocity commands to travel north,south,east and west through, send_ned_velocity function. Or does the code remain the same?
Thanks a lot @thien94 @rmackay9 . The mounted height above the ground is approx. 13cm. Even though I realign camera’s yaw to compass’s before arming, EKF status indicator (GREEN) tends to get higher nearly to 0.5 and at the same time “not healthy” pre-arm check is then triggered. I am also skeptical about its UAVCAN based compass, which is having some issues reported in #12165 .
@rebenstein, yes the T265 integration is mostly complete but the camera only provides position (not distances) so it's only useful for non-GPS navigation. the wiki is here: https://ardupilot.org/copter/docs/common-vio-tracking-camera.html . Some key points: it's best to use an RPI4 and install the linked "APSync" image which should "just work". Instead of using ArduPilot-4.0.x, please try 4.1.x-dev (aka "latest") and enable the EKF3 (details on the wiki). This "latest" version hasn't gone through beta testing so it is more dangerous than using the stable version but it should work better with the T265.
@rebenstein, Thien has published a blog here for using another Intel RealSense camera for object avoidance: https://discuss.ardupilot.org/t/gsoc-2020-integration-of-ardupilot-and-realsense-d4xx-depth-camera-for-simple-obstacle-avoidance/58474. This is still a work-in-progress but it's looking good so far!
@gauravshukla914, I don't think you will need to make changes to the dronkit-python script you've written. The various non-GPS navigation methods help the EKF get a position estimate without a GPS but the control part of ArduPilot all remains the same.
@apinxiko, on the EKF Status screen, it's the "Compass" bar that keeps climbing above 0.5? That does make it sound like the heading is drifting around until it doesn't agree with the compass anymore. When the vehicle is on the ground and disarmed this should all be related to the gyros and the compass. Maybe try triggering a gyro calibration? I think this can be done by going to the MP's Data screen's Actions tab and selecting "PREFLIGHT_CALIBRATION" and pressing the "Do Action" button. Beyond this I think I'll need to see a log.
Hi @rmackay9 do you have some suggestions on this EKF set home issue? https://discuss.ardupilot.org/t/integration-of-ardupilot-and-vio-tracking-camera-part-2-complete-installation-and-indoor-non-gps-flights/43405/31
@cnpcshangbo, the "No SRTM datda for this area" is a Mission Planner issue I think. It's unrelated to the core ArduPilot flight code. It may help to zoom in more before selecting "set EKF origin". Also make sure that you can see the altitude on the PLAN screen as you move the cursor around. I'd also recommend setting the EKF origin to where the vehicle actually is. So don't, for example, try to set the EKF origin in the sea
Hey guys, any known issues with the SITL and guided mode? I am trying to arm in guided mode, with flow sensor and rangefinder enabled. I have disabled GPS on the ekf2 and as an input in general (set to none) but since I have no gps, the gps message i am seeing has 65535 as the hdop and gdop. So its too high, which is causing a APM: PreArm: High GPS HDOP error and it wont let me arm... is the SITL not good enough for flow+range finder only guided mode?
The goal is of course to use a SLAM based vision approach but trying to get the sitl setup for the flow base case now.
I also tried the same configs with EK3 and still get the hdop error
Hi @rmackay9 and @thien94 , thanks for your suggestions on the Mission Planner set EKF home issue. I have tried to use the python script to set origin. However, EKF 2 still refuses set origin. Is there something wrong with the data I sent?
@mcelhennyi, I think you'll just need to set the arming checks to remove the GPS check. I forget what the actual bit is for the GPS but because it's sitl you could just set ARMING_CHECK = 0 and it should work. You'll also need to set EKx_GPS_TYPE = 3. This should be more clear on the wiki so I've added a to-do to add it. ArduPilot/ardupilot_wiki#2909
@rmackay9 i am using pozyx
If you're using Pozyx we have another method though. https://ardupilot.org/copter/docs/common-pozyx.html. be sure to use EKF3 though
To use this method i need to adapt your script in python since i am using ardupilot. Is that a possibility i can use ?
@joekrom, ok, that shouldn't matter really. I actually have some concerns that our pozyx support has been broken. I don't know for sure though. ArduPilot/ardupilot#14353
@cnpcshangbo, normally the reason the flight code sends the "EKFx refusing set origin" message is because EKx_GPS_TYPE hasn't been set to 3 or a GPS is still connected and the origin has already been set. The vehicle isn't appearing on the map right? I think it would be best to first try to set the origin with MP. The MP is known to work.
that is right but when i try with the GPS_INPUT by simulating a random position i can see the drone in the map
You've probably already seen the list of support methods to do Non-GPS: https://ardupilot.org/copter/docs/common-non-gps-navigation-landing-page.html
If something can send in a GPS_INPUT or VISION_POSITION_ESTIMATE (and optionally VISION_SPEED_ESTIMATE) at 5hz or more then it should work
@mcelhennyi, ah, we apparently have an optical flow setup page here: https://ardupilot.org/copter/docs/common-optical-flow-sensor-setup.html
@joekrom, I haven't used the Pozyx in a couple of years but previously it could not provide a stable attitude (it's really just heading that the EKF needs). Very recently I've used the NoopLoop which also uses the same DWM1000 chip that Pozyx uses and it also can't provide attitude.
In any case, I think if the mavlink inspector is showing that the x and y values are always increasing then this is an issue with the Pozyx system or the scripts perhaps that are converting the pozyx data into mavlink messages
if (rbData.Tracked == true) {
long cur_ms = stopwatch.ElapsedMilliseconds;
MAVLink.mavlink_att_pos_mocap_t att_pos = new MAVLink.mavlink_att_pos_mocap_t();
att_pos.time_usec = (ulong)(cur_ms * 1000);
att_pos.x = rbData.x; //north
att_pos.y = rbData.z; //east
att_pos.z = -rbData.y; //down
att_pos.q = new float[4] { rbData.qw, rbData.qx, rbData.qz, -rbData.qy };
byte[] pkt = mavlinkParse.GenerateMAVLinkPacket20(MAVLink.MAVLINK_MSG_ID.ATT_POS_MOCAP, att_pos);
mavSock.SendTo(pkt, drone_ep);
long cur_ms = stopwatch.ElapsedMilliseconds;
MAVLink.mavlink_att_pos_mocap_t att_pos = new MAVLink.mavlink_att_pos_mocap_t();
att_pos.time_usec = (ulong)(cur_ms * 1000);
att_pos.x = rbData.x; //north
att_pos.y = rbData.z; //east
att_pos.z = -rbData.y; //down
att_pos.q = new float[4] { rbData.qw, rbData.qx, rbData.qz, -rbData.qy };
byte[] pkt = mavlinkParse.GenerateMAVLinkPacket20(MAVLink.MAVLINK_MSG_ID.ATT_POS_MOCAP, att_pos);
mavSock.SendTo(pkt, drone_ep);
once i get the data from pozyx i use this easy script with dronekit to send the data , i just adapt it in python
On the pozyx website there is a tutorial for 3D orientation "https://docs.pozyx.io/creator/latest/python/tutorial-3-orientation-3d-python"
@rmackay9 that is an image showing the disproportion of my local data
Hello.
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.
https://drive.google.com/drive/folders/1HwtgpBd3ZHehethRmmJaOSWYMNERsviW?usp=sharing
Thank you for always.