Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    apinxiko
    @apinxiko
    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 .
    Randy Mackay
    @rmackay9
    @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.
    Randy Mackay
    @rmackay9
    @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.
    Randy Mackay
    @rmackay9
    @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
    Ed Muthiah
    @ed-muthiah
    @patrickpoirier51 Hey Patrick, are you having this grainy image issue with Pi v2 Camera on your NX?
    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
    image.png
    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"
    apm.png
    @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.