0
$\begingroup$

Rosanswers logo

Hi everybody,

Following previous questions (1, 2), I would like to ask you if this architecture looks smart and efficient. My goal is to perform autonomous indoor navigation for quadrotor based on AMCL localization. I have been facing some troubles to set up my tf tree and my different odometry and pose informations. The proposed solution is as follow:

The TF tree:

base_link -> base_stabilized: I use the IMU information returned by mavros in the hector_imu_attitude_to_tf node

base_stabilized -> base_footprint: I simply subscribe to the altitude topic of mavros and publish the z translation. I still have some reliability problems as the barometer is not really accurate. I might try to use the sonar height combined with the IMU information. To be continued

base_footprint -> odom: I use robot_localization. It is working in 2d mode. It combines the IMU and the optical flow. To use the mavros_msgs/OpticalFlowRad in robot_localization, I use make use of optflow_odometry. At the end of the day, robot_localization is also publishing my 2D odom.

odom -> map: I use another EKF, again robot_localization, to fuse my 2D odom with my SLAM position.

For the moment, everything looks good, except the base_stabilized -> base_footprint. This problem does not affect the system. Do you think my solution is a good one, compared to the use of a single mavros usage? Am I creating to much computing and processing requirements or maybe inducing errors?


Originally posted by quentin on ROS Answers with karma: 123 on 2016-03-08

Post score: 2


Original comments

Comment by Tom Moore on 2016-04-29:
Looks reasonable, though I'm curious how well the EKF in two_d_mode with amcl will work when the LIDAR (?) scans are going to vary with roll and pitch.

Comment by Icehawk101 on 2016-04-29:
I believe that hector_imu_attitute_to_tf is supposed to correct for the pitch and roll.

Comment by quentin on 2016-05-02:
Yes exactly Icehawk101.

For the moment the system looks quite stable. I am also trying to develop another tree, making use of amcl instead of the slam localization. Documented comparison are to be done!

Comment by Icehawk101 on 2016-05-03:
Are you using AMCL for 2D localization and then just adding the height to the transform?

Comment by quentin on 2016-05-09:
Yes exactly Icehawk101

Comment by Icehawk101 on 2016-05-10:
Have you tried this with AMCL yet?

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

Yes Icehawk 101!

I have tried. The results were not satisfying. It behaved as if AMCL and my odometry source (px4flow) were messing each other around... There was a temporary reaction where AMCL was completly lost and then a steady state where AMCL alone could localize itself (when not moving anymore).

I am trying to improve my pure px4flow-based localization but it currently not satisfying. I don't manage to get a really good flow-based position, though I should be. If you have already touched that we could help each other :)


Originally posted by quentin with karma: 123 on 2016-05-10

This answer was ACCEPTED on the original site

Post score: 0


Original comments

Comment by Icehawk101 on 2016-05-11:
My drone is not set up yet, I am currently working with a proof of concept prototype. When I tried using AMCL though it didn't work. If you read section 3.1.6 Transforms on http://wiki.ros.org/amcl though I don't think it will work.

Comment by Icehawk101 on 2016-05-11:
Have you considered trying the humanoid_localization package as well? http://wiki.ros.org/humanoid_localization. That is going to by my next test so I will let you know how it goes.

Comment by quentin on 2016-05-11:
Yes I am considering it. But currently, AMCL works well in the simulation (eventhough it is still 2D). But I would like to try my sensor in the real world and therefore solve my px4flow issue.

Comment by Icehawk101 on 2016-05-24:
How are things working for you?

Comment by quentin on 2016-05-24:
I add some issues with my px4flow hardware. It seems that it is now solved, I still need to experiment further.

humanoid_localization is roughly working in my simulation, but also still need to be improved.

Comment by quentin on 2016-05-24:
What about you? What exactly is your goal? Mine is to perform autonomous navigation in a partially known environment. I do it in a simulated environment and I also own the pixhawk and px4flow in order to try the algorithms in real life!

Comment by Icehawk101 on 2016-05-25:
3D mapping and localization in a gps denied environment. I got humanoid_localization working alright, but it seems laggy to me. I don't have an odometry source though, I am using the pub_odom parameter from hector_mapping so there is a lot of overhead.

Comment by quentin on 2016-05-25:
Oh so you managed to use hector_mapping as an odometry source for your AMCL (2D or 3D) localization nodes?

In your problems, do you know the map before hand or do you navigate in a unknown environment?

Comment by Icehawk101 on 2016-05-26:
I use it as the odometry source for my humanoid_localization node.

I used hector_mapping and octomapping to make a 3D octomap. Now, I am trying to get localization in that preknown map to work properly.

Comment by Icehawk101 on 2016-05-26:
The problem I am running into right now is that using hector_mapping for odom and humanoid_localization for localization is using too much overhead, which causes the system to lag. While I'm moving the prototype it stops for a second or two then warps to wherever it should be.

Comment by quentin on 2016-05-26:
Ok! Sounds good!! If you are doing it entirely in the simulation, you might be interested into creating the octomap directly from the 3D model of your Gazebo environment. Just let me know!

Comment by Icehawk101 on 2016-05-30:
I have the hardware here so I didn't bother with simulating it. I hooked everything into a handheld prototype and am testing it in my lab.

Comment by Icehawk101 on 2016-06-01:
How are you finding px4flow? I am considering getting one as it performs the odometry onboard, thus reducing overhead. I am worried that my lab won't have enough objects for the camera to pick up, though that shouldn't be an issue if I point it at the ceiling of the actual work environment.

Comment by quentin on 2016-06-01:
I am facing some issues with the px4flow... I guess my light conditions are not so good. Currently, I try to merge kinect-based visual odometry (awesome but computationally demanding) and px4flow.

Comment by Icehawk101 on 2016-09-12:
Have you made any headway in the last few months?

Comment by quentin on 2016-09-13:
PX4FLOW is a great tool but unfortunately it has some limitations. I now use RTABMAP to compute KInect-based visual odometry. The accuracy is very good!

Comment by Icehawk101 on 2016-09-13:
We ordered a PX4Flow to see if it would work with our project. Haven't gotten it yet but interested to see how it does. I'm thinking of using an EKF to fuse the odom from the flow with the odom from laser scan matching for increased accuracy. I never had much luck with rtabmap.

Comment by kumar12 on 2017-10-27:
Hey, I am trying to do something similar to yours but without the PX4Flow. Will it be possible for you to guide me on how to send the AMCL decisions to PX4 through MAVROS? I do not fully understand how PX4 can interpret the AMCL data generated in Gazebo simulation

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.