mavlink / mavros

MAVLink to ROS gateway with proxy for Ground Control Station
Other
879 stars 989 forks source link

/mavros/local_position/local taking data from two sources : #303

Closed Royalcheese closed 9 years ago

Royalcheese commented 9 years ago

It seems that fcu is publishing data in /mavros/local_position/local topic on mavros... Here my results :


---
header: 
  seq: 5635
  stamp: 
    secs: 0
    nsecs: 0
  frame_id: global
pose: 
  position: 
    x: 0.0
    y: 0.0
    z: 1.0
  orientation: 
    x: 0.0
    y: 0.0
    z: 0.0
    w: 1.0

---
header: 
  seq: 5636
  stamp: 
    secs: 0
    nsecs: 0
  frame_id: global
pose: 
  position: 
    x: 0.0
    y: 0.0
    z: 1.0
  orientation: 
    x: 0.0
    y: 0.0
    z: 0.0
    w: 1.0

---
header: 
  seq: 634
  stamp: 
    secs: 946690338
    nsecs: 752075264
  frame_id: local_origin
pose: 
  position: 
    x: -4.65935700049e-05
    y: 4.29840292782e-06
    z: 0.99997895956
  orientation: 
    x: 0.00168625889722
    y: -0.00584274381409
    z: 0.000856630700448
    w: 0.999981142352

---
header: 
  seq: 5637
  stamp: 
    secs: 0
    nsecs: 0
  frame_id: global
pose: 
  position: 
    x: 0.0
    y: 0.0
    z: 1.0
  orientation: 
    x: 0.0
    y: 0.0
    z: 0.0
    w: 1.0

I don't want local position to be corrupted by the data the drone is sending.. and I didn't manage for now to fix it.. Any help would be nice, I'm a bit confused.

TSC21 commented 9 years ago

local_position/local is supposed to be the local position estimated by the FCU. So I dont understand what you are reying to do here.

vooon commented 9 years ago

If i remember correctly they remap their estimator to local topic. What i can't understand why remap?

Royalcheese commented 9 years ago

Because as I understand, fcu use local topic data for its own estimator.. When I haven't the remap, I can send data in any topic I have, the drone won't use it example : I'm sending a sinusoid PoseStamped into vision_pose/pose without remap of Vision_pose <- local , and a fixed Setpoint in order to see the thrust output : screenshot from 2015-05-27 11 05 20

When I remap those topic for instance, I got that result : screenshot from 2015-05-26 16 15 54

So I expected that what I had to do was to erase data on local in order to put on my own, and remap local -> vision in order to simulate the local position estimated by the drone.

Now I think that was too simple ^^ You understand my problem now ?

Royalcheese commented 9 years ago

Just for precision, INAV is validated only if I remap vision_pose/pose topic, mocap not supported on INAV Could you help me ?

TSC21 commented 9 years ago

Just for precision, INAV is validated only if I remap vision_pose/pose topic, mocap not supported on INAV Could you help me ?

That's correct. If you remap your mocap topic to /vision_pose/pose, your mocap estimate will be sent through VISION_POSITION_ESTIMATE msg. One thing you can always do is add support in the firmware to receive that same message on INAV. The code will be mostly similar to what already is implemented to handle vision data.

TSC21 commented 9 years ago

Note: as I said local_position/local is the feedback from the estimators on the FCU - LOCAL_POSITION_NED to be more precise. So you shouldn't remap that message. If somehow this message is interfering with your messages, you can always blacklist the plugin on mavros or stop this msg stream on the FCU side.

Royalcheese commented 9 years ago

I'm sure you are right, but how explain the fact that when I'm writing in vision_pose, and remap local on vision_pose/pose I obtain this ? screenshot from 2015-05-27 13 49 20 and when I do not remap , I just obtain this : screenshot from 2015-05-27 11 05 20

Anyway, I try to do as you're saying right now :) And I will try to implement mocap in INAV. Thank you a lot for your support , @TSC21 , @vooon !!

vooon commented 9 years ago

Anyway passing output (~local_position/local) of estimator to their input (~vision_pose/pose) is a bad idea.

TSC21 commented 9 years ago

Anyway passing output (~local_position/local) of estimator to their input (~vision_pose/pose) is a bad idea.

Yep. You are feedforward the output into the input, which returns to a floating estimation.

Royalcheese commented 9 years ago

Hmm I see the problem with what I'm doing... I tried to remap mocap on Vision_pose, but it seems that Fcu doesn't receive the message as it just don't react.. I wonder if it is a firmware issue. Thank a lot for help ! have a nice day

wangsen1312 commented 9 years ago

@Royalcheese geometry_msgs/PoseStamped type and geometry_msgs/TransformStamped have a little difference. If you use want to use code, I can offer you one.

Royalcheese commented 9 years ago

Ok , would be nice if a can have a look :) you can send it on c.perrousset@yahoo.fr ? Thank you a lot

Royalcheese commented 9 years ago

Ok , it was just a matter of ROS::TIME placement ... thank you :)