search

ethz-asl / mav_control_rw

Control strategies for rotary wing Micro Aerial Vehicles using ROS
Apache License 2.0
352 stars 160 forks source link

[question] Asctec ROS package #11

Closed andre-nguyen closed 6 years ago

andre-nguyen commented 7 years ago

Hello!

Thanks for making this package available publicly! Quick questions:

Thanks!

fmina commented 7 years ago

Hi, This thrust mapping should be fine: throttle = thrust/36.0 + 0.1 for firefly where thrust is in [N] (as the controller outputs). Don't forget to limit the throttle between 0 and 1.

andre-nguyen commented 7 years ago

Thanks,

I was about to test but I frequently get the following warning which seems like a bad idea to test.

[ WARN] [1492047085.047300274]: No odometry message received in the last 1 seconds!

Seems intermittent, what's weird is that if I run rostopic hz on my odometry topic (in the firefly) I correctly get 100Hz.

Here's my current setup. Basically my vicon node runs on my laptop and I get odometry from MSF fusing /fcu/imu with /vicon/firefly_green/pose. rosgraph

I don't really see any reason why the watchdog would trigger. Ever seen this problem?

Edit: Additional info, I'm running my Vicon at 100Hz and my /fcu/imu topic also runs at 100Hz. Edit2: I have also set use_rc_teleop to false since I do not have another RC other than the one directly connected to the firefly.

fmina commented 7 years ago

Yes. It is a bug in the way the odom warning is printed. It happens because of this line https://github.com/ethz-asl/mav_control_rw/blob/master/mav_control_interface/src/state_machine.h#L157

Basically if you are in RC mode (manual flight) the odometry watchdog is checked but the odom msg is not updated. It is not harmful, so you can proceed with your tests. I will push a fix later today.

andre-nguyen commented 7 years ago

I think we are talking about two different things here use_rc_teleop is already false. So my problem is actually the opposite of the situation you are describing :confused:

fmina commented 7 years ago

I see. Then this issue should be already fixed. Can you make sure you pull latest master and recompile? Also, do you have anything publishing on the rc topic?

A side comment: You can use the same RC connected to the MAV for teleoperation and manual mode, you don't need 2 remotes. This requires a modification in asctec_mav_framework that we are planning to push to the open repo soon.

fmina commented 7 years ago

@andre-nguyen any update on this?

andre-nguyen commented 7 years ago

Unfortunately the deadline for my class came up and I decided to submit my work in simulation only :sweat_smile: . Everything flies perfect in gazebo but, in the end I only attempted two real flights and both didn't work and I had to take back control.

I don't think it was something to do with this package specifically but rather how to use asctec_mav_framework to fuse vicon measurements on the onboard HLP. However, in one of my flights I attempted to simply plug vicon odometry directly to this package and it still didn't work.

Admittedly, it's been almost two months so my memory is a bit fuzzy but yeah it basically came down to the fact that I didn't fully comprehend your full setup.

I would be interested in trying this again before finishing my masters but it probably won't be in the next few weeks.

Thanks for the help though!

fmina commented 7 years ago

Ok. Let us know if you need help later.

andre-nguyen commented 7 years ago

@fmina Just wanted to let you know that I'm currently giving this another try. I've updated all my repos to include the new commits you pushed to asctec_mav_framework. I'm still periodically getting the odom problem but I've confirmed the nodes are correctly connected and that MSF gets my vicon data.

For an initial test I did the following:

  1. Start ros_vrpn_client and send the transform data to MSF
  2. Initialize MSF and confirm the linear mpc receives the pose estimates
  3. Put the mode switch in position control (what would usually be GPS)
  4. Put the control interface switch to on (the 2 position switch on the right for HL processor comms)
  5. Slowly move the throttle stick up.

The firefly drifts and after a bit of fiddling it looks like the roll and pitch commands are in the wrong direction. i.e. if I pitch back firefly drifts forward (without stopping) and if I roll right the firefly rolls left.

I doubt this has anything to do with this package specifically. I've confirmed my vicon markers are positioned correctly (x forwards, y left, z up).

Hopefully I can investigate further as I'm pretty excited to see this fly!

andre-nguyen commented 7 years ago

Hhhhm, I wonder if this is it? https://github.com/ethz-asl/asctec_mav_framework/commit/d5aafaba557172b7d5ccd93b6f530f4d0e49184d#diff-9e8b3e3b1cb9b73a52caef06453c0fb1R256

Maybe your remote is configured differently?

fmina commented 7 years ago

Possibly the remote is not configured properly. You can print on screen the rc message and move the sticks to confirm that it matches this table https://github.com/ethz-asl/asctec_mav_framework/commit/d5aafaba557172b7d5ccd93b6f530f4d0e49184d#diff-9e8b3e3b1cb9b73a52caef06453c0fb1R239.

Have you verified that odom is getting into the MPC @ 100 Hz?