search

osrf / subt

This repostory contains software for the virtual track of the DARPA SubT Challenge. Within this repository you will find Gazebo simulation assets, ROS interfaces, support scripts and plugins, and documentation needed to compete in the SubT Virtual Challenge.
Other
309 stars 98 forks source link

Potential Issue with X3/X4 Control (via cmd_vel) #97

Closed osrf-migration closed 5 years ago

osrf-migration commented 5 years ago

Original report (archived issue) by Arthur Schang (Bitbucket: Arthur Schang).

The cmd_vel interface on the X3/X4 vehicles does not work intuitively as one would expect:
Example on X3 Config 1:
Command 1.0 m/s Z velocity (all others zero) -> the rotors slowly spin at a constant rate
Command 15.0 m/s Z velocity (all others zero) -> the rotors spin up and the vehicle slowly lifts off

There are two issues present with the current setup using the UKF feedback to the roll_pitch_yawrate_thrust_controller_node from rotors_gazebo:

  1. Incorrect gains or missing feedback for the X3/X4 vehicles' roll_pitch_yawrate_thrust_controller_node
    -The odometry put out by the UKF seems to be all zero which should cause the controller to continue to increase thrust by ramping up each rotor until 1.0 m/s is measured by the odometry. This does not happen and there is a constant rotor speed so there may be missing feedback or insufficient gains for some terms.
  2. Measuring velocity from only the IMU is going to be suboptimal. Competitors will need to feed their own odometry estimate on some documented topic to the UKF to get good results. A way to test whether or not a good odometry estimate from a competitor would work might be using truth from Ignition to ensure that the control is sufficient with perfect odometry.

This is related to issue #94

osrf-migration commented 5 years ago

Original comment by Alfredo Bencomo (Bitbucket: bencomo).

osrf-migration commented 5 years ago

Original comment by Steve Peters (Bitbucket: Steven Peters).

osrf-migration commented 5 years ago

Original comment by Addisu Z. Taddese (Bitbucket: azeey, GitHub: azeey).

Incorrect gains or missing feedback for the X3/X4 vehicles' roll_pitch_yawrate_thrust_controller_node

You might be right. I'll look into it.

Competitors will need to feed their own odometry estimate on some documented topic to the UKF to get good results

Controllers for X3/X4 are currently launched in world launch files (eg. virtual_stix.ign). Moving them into team.ign might allow teams to customize them as they need. I'll look into this as well. This might tie into your first point.

A way to test whether or not a good odometry estimate from a competitor would work might be using truth from Ignition to ensure that the control is sufficient with perfect odometry.

There's a variable, $enableGroundTruth, in the world launch files (virtual_stix.ign, tunnel_practice_circuit.ign, etc). It's set to false by default and during the competition, but for testing you can set it to true and it will publish ground truth poses on /<robot name>/pose and TF.

osrf-migration commented 5 years ago

Original comment by Derek Knowles (Bitbucket: dknowles-ssci).

cmd_vel now seems to be a force input, not a velocity command with the X4 hovering when around 33.0 is published to cmd_vel.linear.z

osrf-migration commented 5 years ago

Original comment by Alfredo Bencomo (Bitbucket: bencomo).

We've improved the inertia settings for the UAVs (i.e. X3).

If you are using a docker container installation, then download the new Docker image from here:

https://cloud.docker.com/repository/registry-1.docker.io/nkoenig/subt-virtual-testbed

If you are using a catkin workspace installation, then run the commands below to update it:

sudo apt update && sudo apt upgrade
sudo reboot

cd ~/subt_ws/src/tunnel_circuit
hg pull && hg update tunnel_circuit

source /opt/ros/melodic/setup.bash

rm -rfv ~/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/*

cd ~/subt_ws/
catkin_make install
. ~/subt_ws/install/setup.bash
ign launch -v 4 competition.ign robotName1:=X3 robotConfig1:=X3_SENSOR_CONFIG_1

# Open another terminal and run these commands:
. /opt/ros/melodic/setup.bash
. ~/subt_ws/install/setup.bash

roslaunch subt_example teleop.launch

BEFORE:

AFTER:

osrf-migration commented 5 years ago

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

This fix has been merged. Does this resolve your issue?

osrf-migration commented 5 years ago

Original comment by Arthur Schang (Bitbucket: Arthur Schang).

I just pulled it down and took a look at it. The change in inertia looks great however this does not fix the noted issue.

‌

If the desired interface teams are to use is to send motor commands, there is no change required but if the desired interface is the velocity topic “cmd_vel” accepting velocity commands, this does not fix the issue at least as it relates to Z. I can still send a command of 1.0 m/s in Z and the rotors will not speed up to achieve a 1.0 m/s Z take-off. The motors merely spin up to some equivalent proportional amount which does not result in a successful take-off or positive Z velocity.

‌

Maybe the appropriate fix is to bias the translation of the command from velocity mode to motor PWM mappings by the required motor PWM for hover.

osrf-migration commented 5 years ago

Original comment by Derek Knowles (Bitbucket: dknowles-ssci).

The cmd_vel topic name does seem to be confusing as it is not actually a command velocity. Instead it seems to be a command force as the X3 lifts off with a cmd_vel.linear.z of about 15 and the more massive X4 with a cmd_vel.linear.z of about 34. We implemented a velocity to force controller in order to get the UAVs flying.

If it was intended to switch to a force command for the UAVs, changing the name to something like cmd_force would seem more intuitive.

osrf-migration commented 5 years ago

Original comment by Neil Johnson (Bitbucket: realdealneil1980).

Our team has now adapted to the new way that cmd_vel works. We would rather that it didn’t change again at this point. With two weeks left, we don’t want to have to modify our controller yet again.

osrf-migration commented 5 years ago

Original comment by Alfredo Bencomo (Bitbucket: bencomo).

We cannot change this topic names right now, but we will consider this change after the tunnel circuit.

osrf-migration commented 5 years ago

Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

I added a note about this to the API page: https://osrf-migration.github.io/subt-gh-pages/#!/osrf/subt/wiki/api

Please update that page if the topic is changed.

osrf-migration commented 5 years ago

Original comment by Alfredo Bencomo (Bitbucket: bencomo).