Traffic resolution: Pure DAIDALUS stops the drone.

[Fauconer]

Hi,

I've run into a new issue with the traffic module. Summoning an intruder can stop the drone dead in its tracks for no clear reason as shown in the attachment.

On this picture the intruder on the right did not trigger the traffic resolution but the one on the left did and stopped the drone even tough it wasn't on its trajectory.

Thank you for your help !

[SweeWarman]

I haven't been able to reproduce this issue based on the data you've given me. Also, the first traffic is loaded at a position of 200m with a bearing of 90 degree relative to the position of the ownship. This initial ownship position is what will be used for all subsequent traffic load commands. Consequently, the second traffic load command of 50,90,.... doesn't seem to have created the vehicle in the proper location. I would suggest try repeating it again to see if this problem persists or try loading up all the traffic vehicles before sending the start command.

[Fauconer]

Hi, The problem seems to persists after loading up the traffic vehicle before sending the start command. The problem shown at the end of the recording doesn't appear if the traffic vehicle is not summoned.

ICAROUS_TRAFFIC_ISSUE.zip

Thank you.

[SweeWarman]

@Fauconer In the video you have a flightplan within a keep-in geofence, but you've selected the starting position of the vehicle outside the keep-in geofence. The keep-in geofence is defined as the volume of airspace you want the vehicle to stay in at all times. Icarous is not designed to work with situations where you start outside a keep-in geofence. In newer releases, we are planning to prevent a takeoff from happening if you try to start outside a keep-in geofence. Could you please try the same scenario again by launching your SITL simulator at the 0th waypoint in your flight plan?

[Fauconer]

Hi, I tried the scenario you mentionned, the result seems to be similar:

ICAROUS_TRAFFIC_ISSUE2.zip

Thanks !

[SweeWarman]

@Fauconer In the last video, one of the problems here is that you've chosen a position for the traffic quite close to waypoint 4 and the traffic is stationary. The default well clear volume in this version has a radius of 30 ft and your traffic's position is around that distance from waypoint 4. Consequently, once the traffic resolution is complete, Icarous will try to get back to the original flight plan. In this case, it will try to get back to waypoint 4 and fail because that will result in further conflicts due to the traffic hovering near waypoint 4.

Could you please try a scenario where you have your stationary traffic located in the middle of a flight plan leg instead of having it anywhere near the waypoints? Also please try this first without any geofences. I'd like to know if this scenario works as expected.

Please note that if you have geofences and moving traffic vehicles, the current open source version of Icarous doesn't handle both constraints simultaneously. Of course, scenarios with moving traffic (without geofences) work fine. However, there will be a newer release in a couple of weeks that can handle all constraints simultaneously.

[SweeWarman]

The newer version of Icarous is available now. Please try out this new version. But please keep in mind, the scenario you've defined needs to be changed so that the vehicle can get to the waypoint after resolving a conflict.

Also, this version can handle all constraints (geofences and traffic) simultaneously. Please see documentation for more info.

[Fauconer]

Hi, it seems there is an error with the git submodule update as seen in the attachment. The following modules are not clonable : /icarous/apps/merger' /icarous/apps/raft' /icarous/apps/rotorsim/QuadCopterSim'

Thank you!

[SweeWarman]

The instructions for the new repository are different. Please see the README. I suggest you delete the old repository and start from scratch due to several new changes to the submodules. Also as described in the new instructions in the README, you shouldn’t be running the ‘git submodule update ... ‘ command directly. You should only use the UpdateModules.sh script.

[Fauconer]

Hi, I followed the new installation instructions but the make command only worked when the rotorsim app was removed from Icarous_defs/apps.cmake.

Then after the installation, it seems that I have a communication problem with the SITL with the following message:

Thanks !

[SweeWarman]

Yes, the rotorsim app is not publicly available anymore. I’ll remove it from apps.cmake.

Add arducopter to the end of the list of apps in apps.cmake and you’ll be able to talk to the SITL simulator. Make sure you compile after adding arducopter to apps.cmake.

https://nasa.github.io/icarous/applications

[Fauconer]

Hi,

Sorry for the delay, unfortunately after resuming the tests I ran into a new problem : Msg Limit Err Pipe Overflow

which I didn't have before and seems to prevent the takeoff as shown in the attached video.

ICAROUS_ISSUE_02_2020.zip

Thank you!

[SweeWarman]

@Fauconer The pipe overflow error can be ignored. I think the version you were using does not send the flightplan to the SITL causing the vehicle to not takeoff. Alternately, you could upload the flightplan to both Icarous and the SITL manually before sending the mission start command. However, this issue was resolved in a recent update released on Jan 30, 2020. Sorry for the inconvenience. Please update your repository and compile a new build (remove the old build folder). In this new version you only have to upload the flightplan to Icarous.

[Fauconer]

Hi again, I recompiled the lastest version of Icarous but it seems that the vehicle still doesn't takeoff when the flightplan is uploaded to icarous alone (the APM:PreArm: need 3D fix error is raised the first time I execute long MISSION_START), it does when the flight plan is uploaded to the SITL (via the commands : arm throttle, takeoff 100, long MISSION_START).

[SweeWarman]

The SITL won't take off till you get a 3D fix. Even if you tried those commands (arm,takeoff) in the SITL without a 3D fix, it won't takeoff. You have to wait till you see the following message on the SITL console before you can takeoff "APM: EKF2 IMU1 is using GPS".

Wait till you see the above message, then send the long MISSION_START command on the Icarous Mavproxy console.

[Fauconer]

Hi,

Unfortunately, it seems that the vehicle still doesn't takeoff when the long MISSION_START is entered after the flightplan is uploaded to icarous alone. No new errors seem to be raised however, as seen in the attached video.

ICAROUS_ISSUE-2020-02-07_13.11.33.zip

Thank you

[SweeWarman]

Please find attached a video illustrating what this sequence should look like: sitl.zip

From the video you sent me, it seems like the full list of waypoints is not being uploaded. If you look at your mavproxy console, it only is uploading waypoint 0 repeatedly. This could be an issue related to your mavproxy version. The mavproxy version that I've been using has the following hash commit id:7eba02c5. And this corresponds to mavproxy version 1.8.8. I suggest you remove your mavproxy and reinstall this specific version: pip3 install mavproxy==1.8.8

[Fauconer]

Hi, Sorry for the delay due to unfortunate circumstances, It seems that by using the pip3 install mavproxy version, the SetupMavProxy.sh bash file can't be used. How did manage to install the customModules with this version ? The SetupMavProxy.sh bash file worked with the github version of mavproxy but not with the pip3 install one.

Thank you again.

[marselomeri]

Hi, when you run the Script SetupMavProxy.sh you also should give the directory where the files of Mavproxy has been installed (usually it works with the github version because it is cloned at /home/username).

About your issue "3D fix" , it happened to me sometimes. I believe there's a miss communication between Autopilot and Icarous, and the calibration process for arducopter is not fully done. One way it works for me, is running the set-up without Icarous (so only connect mavproxy<-->arducopter) and make it work. After that I run the same experiment again (including Icarous ) and the error does not appear. (Not very sure why, but as I said I believe it is connected with the calibration of sensors)

[SweeWarman]

@Fauconer For you convenience, we have updated Icarous to work with the latest version of MAVProxy. This was tested on 1.8.18. You should be able to use the SetupMavProxy.sh script with the GitHub version as usual. Alternately, you can also consider using WebGCS.

@marselomeri I've explained why this happens in this comment here. The simulator will not takeoff until it acquires a 3D fix. You'll have to wait till you see the appropriate messages before sending the start command from Icarous.

[josuehfa]

Hi,

I'm trying to run ICAROUS as you did but with mavproxy from the SetupMavProxy.sh script (master GitHub version) and I had a new issue.

When I uploaded the flightplan, 7 waypoints was shown inside the map console and the mavproxy terminal, I don't know why, but a msg with 0 waypoints was received inside the ICAROUS terminal instead of 7 waypoints. Because of that, when I try to start the mission nothing happens. I tried to check if the mavprovy load msg was correct using other GCS (QGroundControl) and there the flightplan was shown correctly.

1) 7 waypoins in MAVProxy and 0 in ICAROUS

2) MapConsole and QGroundControl

I'm executing the following commands:

1) [SITL Terminal] python3 sim_vehicle.py -v ArduCopter -l 37.102177,-76.387207,5.000000,0 *Everything looks OK.

2) [ICAROUS Terminal] icstart ALIAS = icexe && ./core-cpu1 -C 1 -I 0 "EVS Port1 0/1/ARDUCOPTER 3: Connection to autopilot established" - OK *Everything looks OK.

3) [MAVProxy Terminal] icgs ALIAS = icsim && /home/josuehfa/catkin_ws/icarous/Scripts/runGS.sh *In the first moment I had a problem with PolyCARP but I solved adding PolyCARP in the pythonpath (export PYTHONPATH="/home/josuehfa/catkin_ws/PolyCARP/Python")

After the "APM: EKF2 IMU1 is using GPS" msg:

4) [MAVProxy Terminal] wp load /home/josuehfa/catkin_ws/icarous/Examples/Case1/flightplan.txt 5) [MAVProxy Terminal] long MISSION_START

Thank you for your help !

Please find attached a video illustrating what this sequence should look like: sitl.zip

From the video you sent me, it seems like the full list of waypoints is not being uploaded. If you look at your mavproxy console, it only is uploading waypoint 0 repeatedly. This could be an issue related to your mavproxy version. The mavproxy version that I've been using has the following hash commit id:7eba02c5. And this corresponds to mavproxy version 1.8.8. I suggest you remove your mavproxy and reinstall this specific version: pip3 install mavproxy==1.8.8

[SweeWarman]

@josuehfa I am guessing this could be related to the MAVProxy version you are using. It seems to be working fine with mavproxy version 1.8.20 commit 6dd4a04. It seems to be failing with the latest commit in MAVProxy.

I would also recommend trying out WebGS. This was specifically designed to be used with Icarous.

[josuehfa]

@josuehfa I am guessing this could be related to the MAVProxy version you are using. It seems to be working fine with mavproxy version 1.8.20 commit 6dd4a04. It seems to be failing with the latest commit in MAVProxy.

I would also recommend trying out WebGS. This was specifically designed to be used with Icarous.

Thanks @SweeWarman, using that version of MAVProxy everything works well!

Btw, I want to know if you have some tips about how can I send geofence and waypoints messages (programmatically) to icarous, I tried to use some releases of MAVSDK but I got the same error as before (with the wrong release of MAVProxy).

Furthermore, I got an issue using WebGS, for some reason I could not load a geofence from a file and add more than one traffic there (I'll open an issue there).

Thank you for your time :)

[SweeWarman]

@josuehfa Please take a look at the following script. This is one way of using the pymavlink APIs to send/receive data to/from Icarous. This script imitates a ground station and essentially sends data to the ground station interface application in Icarous. The ground station port settings can be configured here gsInterface0.

If you are looking to send waypoints/geofences from an application running onboard instead of a ground station running offboard, you can implement your own cFS interface application application that will send/receive between your onboard application and Icarous. The internal message definitions for waypoints and geofences are here.