Localization issues with Encoder
Hi,
I am quite new to using ROS, I have been able to successfully do localization with Laserscanmatcher using the Lidar and the map (hector_slam) and it gives me accurate localization.. ( see atatched: https://drive.google.com/file/d/18U5xGwemahcgFnLQBDLdFGCmoaDlkZGR/view?usp=sharing )
However, I am now trying to use ROSARDUINOBRIDGE for autonomous navigation which publishes cmdvelocity and odometry data from the encoders, this distorts localization and scatters the pose arrays and shakes it ( see attached: https://drive.google.com/file/d/1O4y53knDqLnsc-lDZgVXy2mtHSo0MYQ/view?usp=sharing)
How can i resolve this, it is killing me>> Someone please help
See my various launch files below:
Hector SLAM - launch file
<?xml version="1.0"?>
<launch>
<arg name="tf_map_scanmatch_transform_frame_name" default="scanmatcher_frame"/>
<arg name="base_frame" default="base_link"/>
<arg name="odom_frame" default="base_link"/>
<arg name="pub_map_odom_transform" default="true"/>
<arg name="scan_subscriber_queue_size" default="5"/>
<arg name="scan_topic" default="scan"/>
<arg name="map_size" default="2048"/>
<node pkg="hector_mapping" type="hector_mapping" name="hector_mapping" output="screen">
<!-- Frame names -->
<param name="map_frame" value="map" />
<param name="base_frame" value="$(arg base_frame)" />
<param name="odom_frame" value="$(arg odom_frame)" />
<!-- Tf use -->
<param name="use_tf_scan_transformation" value="true"/>
<param name="use_tf_pose_start_estimate" value="false"/>
<param name="pub_map_odom_transform" value="$(arg pub_map_odom_transform)"/>
<!-- Map size / start point -->
<param name="map_resolution" value="0.050"/>
<param name="map_size" value="$(arg map_size)"/>
<param name="map_start_x" value="0.5"/>
<param name="map_start_y" value="0.5" />
<param name="map_multi_res_levels" value="2" />
<!-- Map update parameters -->
<param name="update_factor_free" value="0.4"/>
<param name="update_factor_occupied" value="0.9" />
<param name="map_update_distance_thresh" value="0.4"/>
<param name="map_update_angle_thresh" value="0.06" />
<param name="laser_z_min_value" value = "-1.0" />
<param name="laser_z_max_value" value = "1.0" />
<!-- Advertising config -->
<param name="advertise_map_service" value="true"/>
<param name="scan_subscriber_queue_size" value="$(arg scan_subscriber_queue_size)"/>
<param name="scan_topic" value="$(arg scan_topic)"/>
<!-- Debug parameters -->
<!--
<param name="output_timing" value="false"/>
<param name="pub_drawings" value="true"/>
<param name="pub_debug_output" value="true"/>
-->
<param name="tf_map_scanmatch_transform_frame_name" value="$(arg tf_map_scanmatch_transform_frame_name)" />
</node>
<node pkg="tf" type="static_transform_publisher" name="base_to_laser_broadcaster" args="0 0 0 0 0 0 base_link laser 100" />
</launch>
LaserScanmatcher Launch file:
<
<launch>
<arg name="IS_TWISTSTAMPED" default="true" />
<arg name="publish_covariance" default="false"/>
<node pkg="laser_scan_matcher" type="laser_scan_matcher_node"
name="laser_scan_matcher_node" output="screen">
<group if="$(arg publish_covariance)">
<param name="laser_scan_matcher_node/do_compute_covariance" value="1"/>
<param name="laser_scan_matcher_node/publish_pose_with_covariance" value="true"/>
<param name="laser_scan_matcher_node/publish_pose_with_covariance_stamped" value="true"/>
</group>
<param name="fixed_frame" value="odom"/>
<param name="max_iterations" value="10"/>
<param name="use_odom" value="true"/>
</node>
</launch>
/>
AMCL Launch file:
<launch>
<node pkg="amcl" type="amcl" name="amcl" output="screen">
<!-- Publish scans from best pose at a max of 10 Hz -->
<param name="odom_model_type" value="diff"/>
<param name="odom_alpha5" value="0.1"/>
<param name="transform_tolerance" value="0.2" />
<param name="gui_publish_rate" value="10.0"/>
<param name="laser_max_beams" value="30"/>
<param name="min_particles" value="500"/>
<param name="max_particles" value="5000"/>
<param name="kld_err" value="0.05"/>
<param name="kld_z" value="0.99"/>
<param name="odom_alpha1" value="0.2"/>
<param name="odom_alpha2" value="0.2"/>
<!-- translation std dev, m -->
<param name="odom_alpha3" value="0.8"/>
<param name="odom_alpha4" value="0.2"/>
<param name="laser_z_hit" value="0.5"/>
<param name="laser_z_short" value="0.05"/>
<param name="laser_z_max" value="0.05"/>
<param name="laser_z_rand" value="0.5"/>
<param name="laser_sigma_hit" value="0.2"/>
<param name="laser_lambda_short" value="0.1"/>
<param name="laser_lambda_short" value="0.1"/>
<param name="laser_model_type" value="likelihood_field"/>
<!-- <param name="laser_model_type" value="beam"/> -->
<param name="laser_likelihood_max_dist" value="2.0"/>
<param name="update_min_d" value="0.2"/>
<param name="update_min_a" value="0.5"/>
<param name="odom_frame_id" value="odom"/>
<param name="resample_interval" value="1"/>
<param name="transform_tolerance" value="0.1"/>
<param name="recovery_alpha_slow" value="0.0"/>
<param name="recovery_alpha_fast" value="0.0"/>
</node>
</launch>
Asked by femitof on 2020-03-27 13:52:40 UTC
Comments
@Namal Senarathne @Delb Please assist if you can.. Thanks
Asked by femitof on 2020-03-27 14:04:58 UTC
@Tom Moore Can you please help with this? The ROS_Arduino_bridge publishes a TF from Odom to baselink, and the Laser_Scan_Matcher also publishes another Odom to Baselink TF?..
any ideas how i can combine this
This disrupts the Localization and makes it jump and shake
I am be stuck here.. Please help
Asked by femitof on 2020-03-28 02:04:19 UTC
You've already identified the problem it sounds like. You have two nodes publishing the same TF and ODOM. If You have encoder why would you use Laser scan matcher? Or if laser scan matcher works well, why would you use encoder? Pick one.
Asked by billy on 2020-03-28 13:43:38 UTC
@billy..i tried localization using encoders but it was stuck in one position and not moving.. ANy ideas how to get that working (encoders and AMCL), as i believe this would solve the problem and i wont run mad anymore
pleaseee
Asked by femitof on 2020-03-28 14:21:18 UTC
Not moving on the floor or not moving in RVIZ? The node that does ODOM needs to publish both a TF and a ODOM topic, and then only one node should be doing that. So if you're trying to use the encoder, make sure the encoder node is publishing TF and ODOM topic and and tele-op the robot around and make sure the data is consistent with actual movement. And make sure Laser Scan Matcher isn't running.
Asked by billy on 2020-03-28 14:39:55 UTC
Not moving in RVIZ...just stationary even when the robot is moving in reality...
Yeah, the ODOM publishes both a TF (odom to base link) and odom topic resolution... but it Still doesnt move in RVIZ
Asked by femitof on 2020-03-28 14:56:40 UTC
@billy Hi... See screenshots of my RQT_graph and RViz - how it stays stationary in RVIZ.(RVIZ.
RQT_graph
Please help check..Thanks
Asked by femitof on 2020-03-29 02:48:51 UTC
Your graph looks correct. If you watch the ODOM topic while moving the robot around, does the pose and twist make sense? If you watch the TF while moving, does it also make senses?
Asked by billy on 2020-03-29 03:46:06 UTC
I am not sure if it makes sense.. but this is what i currently have odom and TF topics.. Please review .
Thanks very much @billy
Asked by femitof on 2020-03-31 00:32:41 UTC
OK, so by make sense, I mean drive the robot forward 1 meter. The position pose X coordinate in the ODOM message should indicate 1. While it is moving forward, the twist linear X should read some positive number. then have the robot rotate counter clockwise. While rotating the twist angular Z should read some positive number. After rotating 180 degrees, the pose angular Z will be some number, I don't know what it will be, but some number other than 0 : ) .
If your ODOM and TF aren't getting updated properly then nothing referencing them will work correctly. So start there and make sure they are getting updated correctly.
Asked by billy on 2020-03-31 01:02:56 UTC
Oh wow Thank you very much.. One last question before I get to work...what parameters do I check to make sure Both Odom and tf are updated correctly? Or what parameters affects the twist and position pose rather?
God bless you very much sir @billy
Asked by femitof on 2020-03-31 01:38:52 UTC
Use the suggestions from my previous comment, and then play with it a bit. It will become obvious after a few minutes.
Asked by billy on 2020-03-31 21:05:27 UTC
Hi Billy, Been playing with it and trying different approaches....hence my late response..
My pose X and Y shows in 0.0001 and 1.13870884238e-06 as shown in screenshow_odom
Please can you take a look at my odometry files especially base_controlelr.py file....
My_files
@billy Thank you much
Asked by femitof on 2020-04-03 03:05:34 UTC
So now you know you don't have a ROS problem. Your ODOM isn't working. That could be hardware starting at the encoders, all the way up to your ODOM node. I can't help with that as I don't know anything about the hardware, but at least you've gotten it narrowed down.
what does the HW look like?
Asked by billy on 2020-04-03 12:56:27 UTC
The HW is a Programmable AMT113Q-V Encoder, and it is set to about 1600 ticks/revolution. + the HW works perfectly on the Arduino. from various tests carried out..
it gives an output of 1 1 (left and right encoder) after one wheel revolution, hence the confusion.
@billy
Asked by femitof on 2020-04-03 13:18:29 UTC
@billy Hi Billy, Do you think 1600 ticks/revolution could be the cause of the wrong odometry? My encoder can publish as high as 16000ticks/revolution btw..
I am looking for all possible solution to this problem
Asked by femitof on 2020-04-04 21:59:55 UTC
I see no reason to think the number of 'ticks' per revolution is relevant. 1600 seems like a reasonable number for a wheel.
You seem to believe that whatever the Arduino is doing is working. If it is, then follow the signal to where ever it goes next.
I don't have any idea how your system is setup. Link to the py file doesn't work. I don't know if the Arduino is counting ticks or just sending them on to ROS for counting. I don't know how ROS and Arduino are communicating.
I'm willing to help, but you're going to have to put some effort into explaining the robot or there isn't anything I can do.
Asked by billy on 2020-04-05 01:46:47 UTC
Hi @billy Thank you.
i am trying to build an autonomous wheelchair that can move from one location to another on its own.
I have the following sensors: Lidar, AMT113Q-V Encoder, Ultrasonic Sensors and Arduino Uno and Mega boards
Mapping: I created a very good map using Hector Slam without the use of odometry.
Localization: Localization works perfectly with the amcl node using Laser_scan_matcher but it doesnt work when i use amcl with the odometry information (which is exactly what i need*) - I am stuck here*
Autonomous Navigation: I am using a package called "ros_arduino_bridge", and this package publishes odometry and twist messages, but when i try the odometry it publishes with amcl, it doesnt localize as it is stuck at one position on the map.
**Please see attached my ros_arduino_bridge files and codes in the link below: [https://drive.google.com/drive/folders/1NuOSIIALE50JD6sitdgw_hazdUcAl_8i?usp=sharing]
Asked by femitof on 2020-04-05 14:10:11 UTC
@billy the important files here are:'
Arduino codes: - ROSarduinobridge.ino encoder_driver.ino encoder.h
base_controller.py this publishes the odometry and twist messages
Arduino.py and my_arduino_params.yaml
amcl_launch files
Map generated
Also, any clue on how to go about Autonomous Navigation without using ROS_Arduino_bridge?
Thanks
Asked by femitof on 2020-04-05 14:12:40 UTC
Is it 1600 counts/rev of the motor or rev of the wheel?
Is there gearing between the motor and the wheel? The code assumes it is 1600counts/rev of the wheel. If the encoder is on the motor and not the wheel, you need to account for the gearing ratio in the YAML file.
The code also has a filter for throwing out data that it deems unacceptable. If you're getting hit by that it might explain what is happening. Check the error logs to see if this is an issue. From the base_controller file
and
show the lines to look for.
Asked by billy on 2020-04-05 14:39:07 UTC
@billy Thanks for your response.
Its 1600 counts/rev of the wheel, so no gearing... Also, i have checked, no error messages seen - everything seems okay..
Asked by femitof on 2020-04-05 16:19:58 UTC
OK. How do you know that the encoders are being counted by arduino? Do you have some alternate method of checking with arduino to get the encoder count, besides the data you get from ROS?
Asked by billy on 2020-04-05 22:38:41 UTC
@billy
The arduino code only receives commands and makes serial outputs, and the python code part takes these outputs and writes on topics.
yeah sure, i Move the robot through 2 full wheel revolution and the arduino serial prints 2 2 (left encoder and right encoder)...i have gone as high as 10 full revolutions and i get 10 encoder counts, so it is pretty correct
Asked by femitof on 2020-04-05 22:52:53 UTC
Is it possible that the Arduino is sending ROS "1" instead of "1600" for each rev of the wheel?
Asked by billy on 2020-04-06 01:58:12 UTC
YESSSSSSSSSS, that was the issue.. I noticed it and fixed it, I then saw your comment also, and i was like YESSSS (exactly what i thought)
@billy Thank you so much, you are God Sent.. You have really helped me with this.. Thanks again..
Localization works well twist and odometry messages are great. I am about testing autonomous navigation now, i will let you know if/if not i run into issues or anything.
Thanks so much again, Billy
Asked by femitof on 2020-04-06 13:29:05 UTC
Glad you got it.
Asked by billy on 2020-04-06 21:34:34 UTC
https://answers.ros.org/question/349366/autonomous-navigation-robot-drives-into-wallsobstacle-map-doesnt-generate/
@billy can you please assist with this? Been trying to tag you on the thread, but i cant seem to do it
Asked by femitof on 2020-04-11 15:37:39 UTC
@billy please i am still waiting on your input thanks
Asked by femitof on 2020-04-13 23:53:55 UTC