unl-nimbus-lab / freyja Goto Github PK

To better protect against unwanted or breaking commits to the master branch, it would be valuable to integrate branch protection rules. The following rules could be applied to the master branch:

• Require a pull request before merging
• Require approvals (1 approval)

To ensure that @ajshank can best contribute toward this repository, these rules could not be enforced for administrators.

Hi,

I went through the steps for calibrating thrust_scaler, documented here. The mass of the drone and battery was 1.2kg, and thus I set total_mass=1.2. Starting with thrust_scaler=200 I iteratively updated it until it reached the correct set-point of z=1, with a final value of thrust_scaler=102.

I then added weight to the drone. I added exactly 500g to the drone, and thus changed the total_mass=1.7kg. However I noticed that running the same test, the drone only reaches z=0.5.

My instinct tells me to rerun the iterative process of finding a new thrust_scaler. However reading more into the documentation it mentions this:

This does not include adding payloads (you should adjust total_mass parameter for that.

So I now a bit lost as the best move forward. More generally I notice that there are several params in the launch file:

  <node name="lqg_controller" pkg="lqg_control" type="lqg_control_node" output="screen" if="$(eval not use_velctrl_only)">
	<param name="controller_rate"     type="int"    value="45"  />
  	<param name="total_mass"          type="double" value="$(arg total_mass)"/>
  	<param name="use_stricter_gains"  type="bool"   value="false" />
  	<param name="estimator_rate"      type="int"    value="50" />
  	<param name="bias_compensation"   type="string" value="$(arg bias_compensation)" />
  	<param name="mass_estimation"     type="bool"   value="true" />
  	<param name="mass_correction"     type="bool"   value="false" />
  	<param name="enable_flatness_ff"  type="bool"   value="$(arg enable_flatness_ff)" />
  </node>

For example mass_correction, bias_compensation, total_mass. Is there documentation anywhere as to what each do? Also any suggestions about my current issue with changing the weight?

I created PR #22 to upgrade the ros2-devel branch for ros2 humble.

Affects: ros2-devel branch.
Node: waypoint_manager

Brief:
Code uses NaNs and calls std::isnan(), which is erroneous with -ffast-math.

Detail:
The launch parameter init_NEDy defaults to a vector of NaNs (quiet_NaN in std) if left unspecified by the user. This is later checked in std::isnan() to see if user has specified a full and correct list of 4 elements. However, this check will always return false due to -ffast-math (used in CMakeLists.txt) which further enables -fno-signaling-nans and -ffinite-math-only.

Temporary Fix:
Always provide this launch param. To specify an "invalid param", launch with a list of one element.
@ajshank Verified - this works.

Suggested fix:
Don't use -ffast-math? Use some other compliant operation?

Hi I was curious what current_state held. I know its a 13 cell array.

I have figured out the following:

• current_state[0] = x position
• current_state[1] = y position
• current_state[2] = z position

I assume the following

• current_state[3] = x velocity
• current_state[4] = y velocity
• current_state[5] = z velocity

I am not sure of the rest. I know that some controllers track acceleration? I am also not sure where yaw would be.

Thanks in advance :)

Smooth, energy-optimal trajectories can be generated between two "waypoints" using motion primitives. The end-user waypoint publishing might be a point of conflict, but consider how this might be used at large.

Possible behaviors

1. User calls a service with one "new" destination point and target allocated time: [pn, pe, pd, dt]
2. User provides a bunch of waypoints ordered with time, and the system automatically cycles through them: [idx, pn, pe, pd, dt].

Behaviour needs to be fully defined if (1) is abused by making multiple service calls rapidly.

@ajshank Hi Ajay,
The Freyja Autopilot instructions say (as per attached screenshot):

• "sr2: change all publish rates to zeros, except for EXTRA3 (battery info, system state) which can be set to 1Hz. "
  However, when I did this, mavros stopped transmitting GPS, IMU, and odometry data, which caused the current_state topic and state manager node to not work. Is the sr2 publish rates recommendation still valid for later versions of arducopter (4.1+), or is it correct to set publish rates to non-zero?

Thanks,
John

Hi @ajshank,

I've been unable to build (with ./waf) the computer_ctrl version of Ardupilot (maintained here) for SITL. It also doesn't seem to build for other boards. It may be that it's inconsistent with the most recent version of Ardupilot? I tried dropping the computer_ctrl files into the most recent version of Ardupilot but there are also inconsistencies.

Have you been able to build this version of Ardupilot with computer-ctrl? If not, is Freyja supported for 'Guided' mode in Ardupilot or 'Offboard' in PX4?

Hope you are well!

Hi,

I was looking through some of Freyjas code and noticed that the rpyt_command was hard coded to always have a ctrl_mode of 0b00001111. More specifically in lqr_control_bias.cpp line 253-259:

  freyja_msgs::CtrlCommand ctrl_cmd;
  ctrl_cmd.roll = roll;
  ctrl_cmd.pitch = pitch;
  ctrl_cmd.yaw = yaw;
  ctrl_cmd.thrust = T;
  ctrl_cmd.ctrl_mode = 0b00001111;
  atti_cmd_pub_.publish( ctrl_cmd );

I was wondering if this was intentional. If not would you like me to push submit a change where the control mode is updated based on the messages from /mavros/state topic?

The default "ENU" assumption for mocap can be too restrictive, and relies on mocap interface to publish its +x axis to the "right" of +y axis. This is common ROS standard, but other custom styles may exist.

A parameter can be passed to support custom mappings, either as rotations, or axis mappings.