Right now, there is a "motors" method which arms/disarms the motors, but does not turn them on or off. There should be another method that actually turns the motors on and off so that when taking off, the robot doesn't have issues with the startup rates of different motors.

It would be handy to be change integral gains on the fly in so3_control, but I'm not sure which approach would be most preferred. The way I see it, there are three options:

1. Include the integral gains in PositionCommand
2. Create a separate subscriber specifically for integral gains
3. Have a separate subscriber for position gains, one for attitude gains, and remove gains from PositionCommand entirely.

Thoughts?

When mav_manager computes the time between odom packets, it currently uses the timestamp from the header of the incoming message. This leads to issues when odom is being published by an offboard computer (ex vicon) and clocks aren't synchronized well.

It's probably better to use the ros::Time::now() in the odom callback instead of copying the header timestamp.

With the change in 4222aef, we report the measured motor RPM not the desired, but the scaling factor for the two are different. As per http://wiki.asctec.de/display/AR/List+of+all+predefined+variables,+commands+and+parameters the factor is just 64 but need to verify this value with a tachometer.

Address the following before restructuring

• #12 - Addressed in #113

• #108 - Addressed in #113

• #92

• #118
  * [ ] #88 Cherry pick important updates
  - #50

• major restructuring:

• controllers
  • so3_control
  • pid_control
• doc
• quadrotor_msgs
• quadrotor_simulator
• trackers
  • trackers_msgs
  • std_trackers
  • trackers_manager
• interfaces
  • xyz_interface
  • ...
  • astec_interface
  • astec_firmware
  • quad_encode/decode_msg
  • quad_serial_comm

• #128 + use modern cmake style for setting compiler flags
• Update namespace names to follow code style
• Change kr_trackers_manager to kr_tracker_manager

Finally a public release
- Delete all stale branches. Make people fork and maintain their own branches

• Proper documentation

Wercker doesn't seem to be working well these days, and since this is now open-source, better to just use github actions.

Currently all the properties of the robot (like inertia, mass, arm_length etc.) are hard-coded in the src/dynamics/Quadrotor.cpp file (with params for the hummingbird). This needs to be changed if you want to simulate any other robot. It would be very convenient if we can just have these in a config file instead of hard-coding them.

This functionality is there in the dynamics model but is not exposed in the simulator right now.

bump CMake version to at least 3.10 and use target-based CMake functions.
pretty please? 🔮

The computed duration of the trajectory needs a lower bound that is larger than zero

I struggle to see the reason? Was it because of nodelet?

Common trackers such as line_tracker_yaw, velocity_tracker, etc. should be in a single node. They should also be renamed to trackers instead of controllers.

For example, I want to know whether the motor is on or not, is that possible?

Sometimes long distance goals results in crashes

Right now we just run the packages from the devel space so it is not an issue, but it would be good to have proper install targets for the packages.

Currently the trajectory tracker does not touch the yaw, it maintains the initial yaw. The yaw should be allowed to change along the trajectory by specifying the yaw at the waypoints. This would require taking the time to yaw into account when computing the segment times.

Implementing the option to have yaw be tangential to the trajectory at every point is a bit hard in a simple tracker like this, so that is a task for another time 🙂

The new package.xml format is cleaner and easier to read.
See: http://docs.ros.org/indigo/api/catkin/html/howto/format2/index.html

The "estop" service when used on the pixhawk should continue to send packets at least every 0.5s in order to prevent the pixhawk from entering manual mode.

for example some systems still use ubuntu 14.04?

In mav_manager, the initialization of ROS stuff should occur in an init method, not in the constructor. See the discussion in #65

After running the launch file and enabling motors, I called /quadrotor/hover service and it attempted to go to {nan, nan, nan, 0.00} and crashed. Not sure what the problem is, but Justin says this should not be happening (even though I am supposed to call takeoff prior to hover).

Hi,
I want to pass the SO3 command to the FCU via mavros, I checked the AttitudeTarget message, but that message only supports normlised thrust in z-axis, but SO3Command has forces in x, y and z axis. how can I convert SO3Command to Attitude target message @kartikmohta

thanks

New options are available through std_srvs and should be used instead of creating new srvs in mav_manager:

• Trigger
• SetBool

Like kquad_interface or astec_firmware. Nobody on earth evah will evah use these packages evah. Both companies are acquired anyways.

Services in sample.cpp in mav_manager/src should be listed as /quadrotor/mav_manager/command_name. For example, if I want to specify a target position for the quadrotor, instead of calling the service /quadrotor/goTo, I should call the service /quadrotor/mav_manager/goTo.

Manager: The Motors can be turned off while in-flight. There has to be checks to make sure this is done only when landed. Other safety checks need to be considered

I think the code from that branch was merged into the mav_manager branch so this branch can be deleted.

https://github.com/KumarRobotics/quadrotor_control/blob/b2fb0cb0634bd43761c0b6f7e764ef957fd74319/interfaces/kr_qualcomm_interface/config/trackers.yaml

Typos?

There should be a flag to set whether or not the system depends on IMU feedback. If so, the feedback should be monitored so a safety catch can be triggered if feedback is dropped.

In testing with waypoints, I seem to have found an edge case that causes quadrotors to crash (in sim and reality). The problem is related to the computation of A_inv_M in traj_gen.cpp that produces nan values.

The issue seems to originate when a set of waypoints with motion purely in the z-direction is run when the robot is already exactly coincident with waypoint_1. Other waypoints I have tried seems to run fine regardless of robot starting position. Additionally, a slight perturbation of the robot location via a goto command allows this set of waypoints to run.

This zip file contains a bag file containing an example of this along with a text file describing the waypoints enclosed and the conditions which result in failure.
waypoints_bug.zip

This is probably not a very urgent issue, but I wanted to provide documentation in case it comes up again for someone else!

Actionlib instead of ros services would offer some advantages like:

• Feedback during the trajectory following process.
• Notifications when the robot achieves the goal.

More info:
http://wiki.ros.org/actionlib

Having a separate package for the messages allows us to use messages (such as read from bag files or just echo them) without needing to compile the stuff in the packages.

Hi @tdinesh

Thanks for the great work!

I saw different thrust models in the mavros interface here

I would like to ask if there is any document/paper that explains the math behind this implementation. Also, which one works better in your experience , the implementation in the master branch or the one I linked above in the fla_mavros_interface branch?

Thank you.

Need to make the ros parameters.

Hi.

I would like to know if there is a systematic method of tuning the so3_control gains, especially for actual drones.

How to choose an initial set of values, and how to tune them?

Thank you.

There needs to be some documentation on using this package if it isn't straighforward. It used to involve running a script, but now I get errors (even after installing multi_mav_manager). There is no gui and no RVIZ anymore.

I noticed there are some issues with how Eigen is used in some parts of this repo.
For example

https://github.com/KumarRobotics/quadrotor_control/blob/master/mav_manager/include/mav_manager/manager.h

https://github.com/KumarRobotics/quadrotor_control/blob/fd9812b1d563de07c3248cb6c5ebe0934c51deab/mav_manager/include/mav_manager/manager.h#L76

Passing Eigen objects by value is discouraged.
https://eigen.tuxfamily.org/dox/group__TopicPassingByValue.html

This will not have a problem if the user doesn't compile with -march=native, but I suggest we follow eigen's guidelines on this.

I'm opening up this issue to propose a "MAV Manager" of sorts. My current thoughts are that it will be a class that makes interfacing with quadrotor_control simpler. For example, the following commands might initiate a takeoff to 1m above the current position and have the robot go to {1,1,3}, and then hover in place.

MAVManager robot("QuadrotorAlpha");
robot.takeoff(1);
robot.goTo(1,1,3);
robot.hover();

This concept is still very early in development, so I'd appreciate feedback.

This is to address the comments on cec4b82.

quadrotor_simulator_*.cpp contain duplicated code which can be put into a common library or a base class.

https://github.com/KumarRobotics/quadrotor_control/blob/b2fb0cb0634bd43761c0b6f7e764ef957fd74319/trackers/kr_trackers/CMakeLists.txt#L18

This is breaking my build, changed to ${PROJECT_NAME} fixed it.