Flight : Takeoff issues about mrs_uav_system HOT 19 CLOSED

The odometry is shutting down because it expects data from a laser rangefinder (garmin lidar) for altitude estimation. Do you have this sensor on your drone, or no? If not, you can use the Z from RTK, but you have to be careful when flying over uneven terrain.

Regarding the RTK config, the rover should output NMEA messages over Serial. After you launch mrs_serilal rtk.launch, and read out the RTK messages. If you get L1_INT, your RTK is setup correctly and you have a RTK fix.

from mrs_uav_system.

Hi,
you need to add garmin_down to the SENSORS variable in ~/.bashrc as the log suggests (i.e., export SENSORS="garmin_down". Of course assuming you have a downward garmin rangefinder to measure the height of the UAV. If not, you can alternatively change the altitude estimator in your odometry custom config to barometer only (i.e., altitude_estimator: "BARO"), but I do not recommend this as the altitude measured by the PixHawk barometer is very unstable. Or, as Dan suggested, you can try using altitude corrections from RTK by setting altitude_estimator: "RTK". Nevertheless, this has been tested only in simulation so far and thus might be dangerous on real drone.

Regards,
Matej

from mrs_uav_system.

Hello guys,

First of all, thank you both for your (fast) answers. We have been able to observe the "L1_INT" as Dan mentioned.

However, it seems the uav_state of the drone cannot be computed. I also have the feeling the RTK value is not shared in the whole system : we had a baudrate error message although we set it up at the same rate in the EMLID settings and in rtk.launch. I put you a screenshot of the 4_Control.log file and the Rtk.launch file.
In this picture you can observe this strange error message "Setup Pixhawk SD card"... We updated the firmware through QGC
and the version of mrs_workspace is only 2 weeks old : what could be the issue here ?

Thank you in advance for your help,

Best regards,

Frank

from mrs_uav_system.

Hello, the launch files in mrs_serial were a bit messed up. I fixed them ( git pull ), and it should work properly.
The odometry node is complaining that it is not getting data from pixhawk. Did you follow this guide - https://ctu-mrs.github.io/docs/hardware/px4_configuration.html ?
Mainly the part with sdcard config and ROS setup.

Dan H.

from mrs_uav_system.

Hello @DanHert ,

Thank you very much for your answer,

Indeed, I had forgotten this step of the tutorial . Fixed now. We are moving slowly but surely towards our first flight, but we still have small issues, mainly for the odometry : If you look at the status tab you can see that the odometry isn't working but on the Control.log you can read INFO messages saying the opposite. The only thing we don't have is a XYZ position of the drone but for me, it seems like everything is running so what could be the issue here ? (see screenshot)

Secondly, I updated the mrs serial after your commit but the problem with the rtk is still there. I am trying to look for the bug also. The ERROR message is everytime showing a new and wrong value of baudrate. If you guys are able to fly that means I made a mistake somewhere in the EMLID configuration (but I doubt) or in the code (more possible)...

Thank you very much for your help,

Frank

from mrs_uav_system.

The random baudrate value is just caused by a missing parameter. Did you really pulled mrs_serial? Make sure you are on this commit - ctu-mrs/mrs_serial@531bf8c

Regarding the odometry, could you check the Odometry tab in tmux? It will report what is wrong.

Dan H.

from mrs_uav_system.

Hello,

I added some screens of what you requested. We're on the correct commit and from the odom tab it does not seem like there is data flowing, probably due to the baudrate error of the rtk.

Kind regards,

Zakaria

from mrs_uav_system.

Ahh, sorry, I meant the Control tab, not Odometry (my bad, Odometry used to be separate from control, but now they are both in the same tab.) There should be some red errors there telling you what is wrong.

Is there still a problem with the mrs_serial node with the new launch files?

from mrs_uav_system.

I just tried to fly a few minutes ago. The baudrate error for the mrs_serial/launch/rtk.launch file is still present. I also added a screen of the Control tab (there were no errors, only warnings).

Edit: Actually there was 2 errors on the entire log file, saying again that the Pixhawk SD card should be checked. Normally we did all the steps correctly and I even see a blue light on the FTDI board connecting the Pixhawk to the Nuc.

from mrs_uav_system.

Hmm, do you still have the regular GPS receiver on the drone? I see UTM: false, which would indicate that your drone does not have the regular GPS fix. The UAV actually needs the regular GPS as well, sicne it contains a magnetometer which is necesary for GPS flights (the one integrated inside pixhawk is not good enough). It also servers as a backup if RTK fails.

Regarding the mrs_serial, did you recompile it after pulling?

Dan H.

from mrs_uav_system.

If you mean the PixHawk GPS then we have it:

Yes I pulled and compiled the workspace containing mrs_serial, I had no errors when doing that.

from mrs_uav_system.

I tried to fly with the gps instead of the rtk for the state estimator and the barometer for the altitude estimator and got the following control tab:

from mrs_uav_system.

Odometry is reporting that it could not load all non-optional parameters, so it probably threw an error earlier in the log.
Can you send the entire log instead of screenshots?

Dan H.

from mrs_uav_system.

Hello,

Here are 2 zip folders containing all the log files for 2 tests we did: 1 with the GPS as state estimator and BARO as the altitude estimator (GPSTest.zip) and the other has the RTK as state and altitude estimator (RTKTest.zip).

As you can see on the status tab, we got the GPS fixed for the GPSTest (last image), but not with the RTKTest (first image).
We tried to send the data from the RTK with another supported baudrate but it gave the same baudrate error. I also noticed there is an error with the checksum so the sent data is probably not even correct..
This can maybe explain why our X,Y and Z value of the RTK are saturating.

GPSTest.zip
RTKTest.zip

from mrs_uav_system.

The odometry node dies because it cannot load the parameter:
Mär 24 16:54:20 �[31m[ERROR] [1616601260.712423847]: [Odometry]: Could not load non-optional parameter /nuc2/odometry/state_estimators/fused_measurements/BARO�[0m
This is happening, because you put BARO as an active state estimator:
Mär 24 16:54:20 �[0m[ INFO] [1616601260.699088536]: [Odometry]: parameter 'state_estimators/active: GPS, BARO�[0m
It is an altitude estimator, so it cannot be there. Your odometry config should look something like this:

# Lateral state estimator:
# OPTFLOW, GPS, OPTFLOWGPS, RTK, ICP, VIO, HECTOR
lateral_estimator: "GPS"

# Altitude state estimator:
# HEIGHT - rangefinder
altitude_estimator: "BARO"

# Heading state estimator:
# GYRO - gyro, COMPASS - gyro, compass, OPTFLOW - gyro, optflow, HECTOR - gyro, hector slam
heading_estimator: "PIXHAWK" 

# Active estimators are started at node launch and can be switched to during flight
state_estimators:
  active: ["GPS"]

heading_estimators:
  active: ["PIXHAWK"]

from mrs_uav_system.

Hello @DanHert and @petrlmat,

Thank you for your answers, thanks to them the previous problems (except the weird baudrate one) have been solved.

After putting the origin at 0.0 0.0 in mrs_uav_general/config/world/world_simulation.yaml ,we observed now some serious X,Y,Z positions drift (10m order and even more) with both GPS and RTK as positions estimators.
While we understand the X,Y position drift in GPS mode, we didn't expect that for the RTK case at all. The cm-precision is not visible, although in the EMLID tab , we have the RTK_FIX and the announced precision by the manufacturer. The value for X and Y oscillates between 2 values, and the Z keeps dropping with no limits.

I believe thus that there is a mistake in the communication between the Reach M2 and the NUC. We observed "wrong checksum' along with the baudrate problem. To solve the latter, we tried to impose the baudrate to a 9600 in the nmea_parser.cpp file but that didn't solve our issue.

I also had a question regarding the rtk_republisher.launch: What is its function? Is it necessary to launch this file when we fly with the RTK (same setup as you)?

I put the logs of the GPS flight and RTK flight in a zip file, with 2 screenshots of the Status tab.

Best regards,

Zakaria

RTK_flight_20210331.zip
GPS_20210331.zip

from mrs_uav_system.

Make sure, you have your UTM/LatLon origin set correctly for your location in your world file. world_simulation.yaml is for simulation, where the starting coordinates are different from your real coordinates. If the problem persists after fixing the origin coordinates, please record a rosbag. In this case the logs do not provide enough information for more in-depth debugging. It should suffice to remove the waitForOffboard; from the Rosbag tmux tab.

from mrs_uav_system.

Hello petrlmat,

Thank you for your answer,

I changed world_simulation.yaml since it is the one mentioned in the ~/.bashrc file. I put my Long/Lat values in the utm_origin_lat_long as you can see it the figure.

I saw that we can switch back and forth easily, but from your experience at MRS, which one do you advice me to use ?

In the meanwhile, I will try a flight and take a look at the rosbag

best,

from mrs_uav_system.

Hello @DanHert and @petrlmat

thank for your answers,

Now the RTK X and Y values appears but aren't good. Sometimes after a while they converge to some values that isn't reality.

The bigger problem is the RTK Z value. The Z variations seems to be precise but there is an offset that changes at each flight. Before reaching the offset, the Z value drops in a linear way (see figure). We also observed that the gpgga_msg_altitude in mrs_serial/nmea_parser.cpp gives a different value that in the mrs_uav_status. As petrlmat advised, we record in a rosbag and plot the result. It iseems that the odometry is fusing RTK measurement with something else but since we only use the RTK as lat and alt estimator, we really don't know what could be the problem. Maybe we put the wrong LatLong in the rtk_republisher.yaml and/or world file : should we put the rover or base LatLong value ?

Could you explain us how the data lying in the nmea messages is sent to the mrs_uav_odometry ? Such that we can look for the bug.

best regards,

Frank

from mrs_uav_system.