ArduPilot/VisionProjects

patrickpoirier51

@patrickpoirier51

@ed-muthiah actually I havent tried it yet, I focus on getting the D435 working with the GSoC project

Ian McElhenny

@mcelhennyi

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

Joel Fankam

@joekrom

@patrickpoirier51 . hi i have a question : does feeding the drone using the GPS_INPUT message (that means sending lat, long and yaw angle ) enough to perform autonomous indoor fly ?

Bo Shang

@cnpcshangbo

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?

Randy Mackay

@rmackay9

@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

Randy Mackay

@rmackay9

@joekrom, I think you'll need to set the GPS_TYPE parameter as well to 14. If you're using a vicon system, remember that it's important that the compass direction agree with the North-South direction of the vicon.

Joel Fankam

@joekrom

@rmackay9 is it possible to achieve indoor autonomous flight using GPS_INPUT and by sending the yaw angle ?

@rmackay9 i am using pozyx

Randy Mackay

@rmackay9

Yes, it probably is possible, I think you'll need to set the EKx_MAG_CAL parameter (weird name I know) to make it consume this yaw. and the compasses will need to be disabled (compas_use = 0, compass_use2=0, compass_use3=0)

If you're using Pozyx we have another method though. https://ardupilot.org/copter/docs/common-pozyx.html. be sure to use EKF3 though

Joel Fankam

@joekrom

ok thanks i will try it and let you know . thanks a a lot

To use this method i need to adapt your script in python since i am using ardupilot. Is that a possibility i can use ?

Randy Mackay

@rmackay9

Using the above method, you can align the beacon system's coordinates with the compass (i.e. leave the compass enabled) using the BCN_ORIENT_YAW parameter. Pozyx can't provide the vehicle's yaw, it can only provide the position, so the compasses need to be enabled.

Joel Fankam

@joekrom

I am using rapsberry pi instead of arduiono

Randy Mackay

@rmackay9

@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

Joel Fankam

@joekrom

Do i have another alternative ?

Randy Mackay

@rmackay9

@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.

Joel Fankam

@joekrom

yes

that is right but when i try with the GPS_INPUT by simulating a random position i can see the drone in the map

Randy Mackay

@rmackay9

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

Joel Fankam

@joekrom

I read a lot of them but with the att_pos_mocap i faced a big gap between the published data and the receiving data on the mavlink inspector notably regarding the x and the y axis

Randy Mackay

@rmackay9

@joekrom, a "big gap" in time I guess? How much lag are you seeing? and is it possible that it is caused by the telemetry system? or maybe whatever is sending the message?

@mcelhennyi, ah, we apparently have an optical flow setup page here: https://ardupilot.org/copter/docs/common-optical-flow-sensor-setup.html

Joel Fankam

@joekrom

@rmackay9 For example if i send fake att_pos_mocap to using dronekit. i send the pose as well as the quaternion retrived from the pozyx tag. The first message about the Glitch correspond to what i published. the the z data remain constant but x and y are growing constantly

Randy Mackay

@rmackay9

@joekrom, I didn't think that Pozyx could provide attitude..

Joel Fankam

@joekrom

it is possible there are register providing eulerAngles and Quaternion

Randy Mackay

@rmackay9

@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

Joel Fankam

@joekrom

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);

once i get the data from pozyx i use this easy script with dronekit to send the data , i just adapt it in python

Randy Mackay

@rmackay9

Ok, looks good. Sorry to keep repeating myself but I am very suspicious of Pozyx's attitude. Unless it has a compass it can't possible know it's attitude because the DWM1000 chips can't provide this.

Joel Fankam

@joekrom

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

Jee88

@Jee88

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.

Randy Mackay

@rmackay9

@joekrom, thanks for the link. So it appears that the Pozyx has gained a compass and an IMU so this is how it could get the orientation.

Randy Mackay

@rmackay9

@Jee88, txs for the testing and feedback. I think that facing the camera downwards is probably not a good idea. From the feedback we've received it seems that forward facing is best (and the wiki has been updated to recommend the camera is facing forward). I don't really understand how you're powering the RPI4 (?) and camera but if you're relying on the autopilot to provide power through it's serial port then this is definitely not good. A separate BEC or the PiConnectLite receiving power from the main battery will definitely be more stable and reliable.

Re the "Pos jump detecdted" messages, these all appear right at the end of the log and there are no messages of any type including VISP messages after this. Maybe @thien94's scripts have an issue when the camera is disconnected which causes it to constantly output , "Pose jump detected" ... I'm not really sure but it seems like this happens once the flight is over in any case. Maybe the camera lens is very close to the ground so it doesn't know where it is anymore. I find it odd that the scripts are outputting this message but not sending VISP messages but I'll wait for @thien94's reply on this.

Re the date, does the RPI4 you're using have a real time clock? Maybe something like this? https://chicagodist.com/products/rasclock-rtc-for-raspberry-pi.

Randy Mackay

@rmackay9

I don't have one of these and I've never tested if our APSync image will send the time to the autopilot.. I can look into this though.

Jee88

@Jee88

@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)

Thank you.

Thien Nguyen

@thien94

At least in my tests, when the camera is disconnected the script should stop working right after. If the pose jump message is constantly pushed out that means the position data is diverging (moving rapidly away), which can happen during/after takeoff and landing that exceeds the T265's IMU acceleration range limit (see here IntelRealSense/librealsense#3991).

Thien Nguyen

@thien94

That might have been the case for @Jee88 , in one of your logs, I see the z position quickly went to the ground after a spike in the accel's data is observed:

May I suggest:

increasing the camera's distance to the ground (if you need to have it facing downward)
add damping if possible. just test take off and landing to verify whether the vibration is an issue or not.
make sure the camera's FOV is not blocked (or as little as possible) by any part of the quadcopter.
test at somewhere with abundant visual features on the ground if you can.

Jee88

@Jee88

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.
https://drive.google.com/drive/folders/1HwtgpBd3ZHehethRmmJaOSWYMNERsviW?usp=sharing
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.

Where communities thrive

People

Repo info

Activity