Name: tum_ardrone
Owner: Aerial Robotics Kharagpur
Description: Repository for the tum_ardrone ROS package, implementing autonomous flight with PTAM-based visual navigation for the Parrot AR.Drone.
Forked from: tum-vision/tum_ardrone
Created: 2017-03-26 05:50:39.0
Updated: 2017-03-26 05:50:41.0
Pushed: 2016-03-21 11:10:39.0
Homepage: http://wiki.ros.org/tum_ardrone
Size: 16731
Language: C++
GitHub Committers
| User | Most Recent Commit | # Commits |
|---|
Other Committers
| User | Most Recent Commit | # Commits |
|---|
This package contains the implementation corresponding to the following publications:
You can find a video on youtube. This Package builds on the well known monocular SLAM framework PTAM presented by Klein & Murray in their paper at ISMAR07. Please study the original PTAM website and the corresponding paper for more information on this part of the software. Also, be aware of the license that comes with it.
The code works for both the AR.Drone 1.0 and 2.0, the default-parameters however are optimized for the AR.Drone 2.0 by now.
atkin_ws/src
clone https://github.com/tum-vision/tum_ardrone.git -b hydro-devel
.
ep install tum_ardrone
in_make
aunch tum_ardrone ardrone_driver.launch
aunch tum_ardrone tum_ardrone.launch
On the GUI, under Drone Communication Status, you should see:
Estimates the drone's position based on sent navdata, sent control commands and PTAM.
IMPORTANT: requires messages to be sent on both /ardrone/navdata (>100Hz) and /ardrone/image_raw (>10Hz), i.e. a connected drone with running ardrone_autonomy node, or a .bag replay of at least those two channels. ardrone_autonomy should be started with:
un ardrone_autonomy ardrone_driver _navdata_demo:=0 _loop_rate:=500
None
~publishFreq: frequency, at which the drone's estimated position is calculated & published. Default: 30Hz
~calibFile: camera calibration file. If not set, the defaults are used (camcalib/ardroneX_default.txt).
UseControlGains: whether to use control gains for EKF prediction.
UsePTAM: whether to use PTAM pose estimates as EKF update
UseNavdata: whether to use Navdata information for EKF update
UsePTAM and UseNavdata are set to false, the EKF is never updated and acts as a pure simulator, prediciting the pose based on the control commands received (on /cmd_vel). Nice for experimenting.
PTAMMapLock: lock PTAM map (no more KF)
PTAMSyncLock: lock PTAM map sync (fix scale and pose offsets etc.)
PTAMMaxKF: maximum amount of KF PTAM takes.
PTAMMinKFDist: min. distance between two KF (in meters)
PTAMMinKFWiggleDist: min. distance between two KF (relative to mean scene depth).
PTAMMinKFTimeDiff: min time between two KF.
PTAM takes a new KF if (PTAMMinKFTimeDiff AND (PTAMMinKFDist OR PTAMMinKFWiggleDist)), and tracking is good etc.
RescaleFixOrigin: If the scale of the Map is reestimated, only one point in the mapping PTAM <-> World remains fixed. If RescaleFixOrigin == false, this is the current pos. of the drone (to avoid sudden, large “jumps”). this however makes the map “drift”. If RescaleFixOrigin == true, by default this is the initialization point where the second KF has been taken (drone pos. may jump suddenly, but map remains fixed.). The fixpoint may be set by the command “lockScaleFP”.
c1 … c8: prediction model parameters of the EKF. see “Camera-Based Navigation of a Low-Cost Quadrocopter”
TODO
TODO
To properly estimate PTAM's scale, it is best to fly up and down a little bit (e.g. 1m up and 1m down) immediately after initialization. There are two windows, one shows the video and PTAM's map points, the other one the map. To issue key commands, focus the respective window and hit a key. This generates a command on /tum_ardrone/com, which in turn is parsed and does something.
| Key | /tum_adrone/com message | Action | |——-|————————-|———| | r | “p reset” | resets PTAM | | u | “p toggleUI” | changes view | | space | “p space” | takes first / second Keyframe for PTAM's initialization | | k | “p keyframe” | forces PTAM to take a keyframe | | l | “toggleLog” | starts / stops extensive logging of all kinds of values to a file | | m | “p toggleLockMap” | locks map, equivalent to parameter PTAMMapLock | | n | “p toggleLockSync” | locks sync, equivalent to parameter PTAMSyncLock |
Clicking on the video window will generate waypoints, which are sent to drone_autopilot (if running):
| Key | /tum_adrone/com message | Action | |——-|————————-|———| | r | “f reset” | resets EKF and PTAM | | u | “m toggleUI” | changes view | | v | “m resetView” | resets viewpoint of viewer | | l | “toggleLog” | starts / stops extensive logging of all kinds of values to a file | | v | “m clearTrail” | clears green drone-trail |
PID controller for the drone. Also includes basic way-point-following and automatic initialization. Requires drone_stateestimation to be running. The target is set via the /tum_ardrone/com topic.
None
TODO
TODO
The behavior of the autopilot is set by sending commands on /tum_ardrone/com of the form “c COMMAND”. A Queue of commands is kept, and as soon as one command is finished (for example a way point reached), the next command is popped. The queue can be cleared by sending “c clearCommands”. Commands can be sent using the drone_gui node. Some example scripts can be found in /flightPlans/*.txt. Possible commands are:
autoInit [int moveTimeMS] [int waitTimeMS] [int riseTimeMs] [float initSpeed]
takes control, starts drone, initializes PTAM. That is:
- starts the drone & and waits riseTimeMs, the drone will rise to approx.
a height of 1m.
- initializes PTAM by taking the first KF, flying up (sending initSpeed as control command) for moveTimeMS,
waiting waitTimeMS and then taking the second KF.
This is done until success (flying up and down respectively).
- good default values are "autoInit 500 800 4000 0.5"
autoTakeover [int moveTimeMS] [int waitTimeMS] [int riseTimeMs] [float initSpeed]
takes control, initializes PTAM. The same as autoInit ...,
but to be used when the drone is already flying (skipps the first step).
takeoff
- takes control, starts drone.
- does not reset map or initialize PTAM
setReference [doube x] [double y] [double z] [double yaw]
sets reference point (used in goto X X X X).
setMaxControl [double cap = 1.0]
maximal control sent is capped at [cap], causing the drone to fly slower.
setInitialReachDist [double dist = 0.2]
drone has to come this close to a way point initially
setStayWithinDist [double dist = 0.5]
drone has to stay this close to a way point for a certain amount of time.
setStayTime [double seconds = 2.0]
time the drone has to stay within [stayWithinDist] for target to be reached.
clearCommands
clears all targets, such that the next command is executed immediately.
goto [doube x] [double y] [double z] [double yaw]
flies to position (x,y,z yaw), relative to current reference point.
blocks until target is reached according to set parameters
moveBy [doube x] [double y] [double z] [double yaw]
moves by (x,y,z,yaw), relative to the current target position
blocks until target is reached according to set parameters
moveByRel [doube x] [double y] [double z] [double yaw]
moves by (x,y,z,yaw), relative to the current estimated position
of the drone
blocks until target is reached according to set parameters
land
initializes landing (use auto-land of drone)
lockScaleFP
sets the one point that does not change when the scale is re-estimated
to the current drone position. The scaleFP can only be set when PTAM is
good, i.e. this is delayed until PTAM is initialized and good.
Need to set useWorldFixpoint in dynammic_reconfigure.
This node offers a simple QT GUI to control the drone_autopilot node, the drone_stateestimation node and fly the drone manually via keyboard or joystick.
None
None
None
On the top-right, the current publish-frequency of important topics is displayed:
The current control source has to be set (i.e. joystick or KB). The autopilot is only allowed to send control commands, if this is set to autopilot.
Joystick control requires a connected joystick and running “rosrun joy joy_node”. We use a PS3 sixaxis controller. to make the controller work, a small linux-hack is required (set controller rights).
left joystick is horizontal pos. control; right joystick is height and yaw control.
L1 to take off, release L1 to land.
R1 to toggle emergency state. => by moving any of the two joysticks, the Control Source is immediately sent to Joystick. can be used for safety (autopilot does wired stuff -> immediately take over, disabling the autopilot and enabeling manual control).
KB control requires the GUI window to have focus, but NOT the upper-left text field. => make the GUI the active window and press ESC to immediately enable KB control and set focus such that KB control works properly. can be used for safety (autopilot does wired stuff -> press ESC and immediately take over, disabling the autopilot and enabeling manual control).
q,a: fly up & down.
i,j,k,l: fly horizontally.
u,o: rotate yaw.
F1: toggle emergency
s: takeoff
d: land
Buttons Land, Takeoff, ToggleCam, Emergency (toggles emergency state).
calibrate with ethzasl_ptam. to work with colored images, in src/CameraCalibrator.cc change:
CameraCalibrator::imageCallback(const sensor_msgs::ImageConstPtr & img)
ridge::CvImagePtr cv_ptr = cv_bridge::toCvCopy(img, sensor_msgs::image_encodings::MONO8);
CurrentImage.size().x != img->width || mCurrentImage.size().y != img->height)
mCurrentImage.resize(CVD::ImageRef(img->width, img->height));
py(mCurrentImage.data(),cv_ptr->image.data,img->width * img->height);
Image = true;
can be estimated easily by
approximate in “simulation” based on c1 to c8:
The major part of this software package - that is everything except PTAM - is licensed under the GNU General Public License Version 3 (GPLv3), see http://www.gnu.org/licenses/gpl.html. PTAM (comprised of all files in /src/stateestimation/PTAM) has it's own licence, see http://www.robots.ox.ac.uk/~gk/PTAM/download.html. This licence in particular prohibits commercial use of the software.