Ask Your Question

salvadorvalisena's profile - activity

2017-07-27 10:24:18 -0500 received badge  Famous Question (source)
2017-07-20 02:40:56 -0500 received badge  Famous Question (source)
2016-02-03 08:57:29 -0500 received badge  Notable Question (source)
2015-10-14 09:04:48 -0500 received badge  Notable Question (source)
2015-10-09 07:30:11 -0500 received badge  Popular Question (source)
2015-10-09 07:30:11 -0500 received badge  Famous Question (source)
2015-10-09 07:30:11 -0500 received badge  Notable Question (source)
2015-10-06 02:19:05 -0500 received badge  Famous Question (source)
2015-06-03 02:59:42 -0500 received badge  Notable Question (source)
2015-05-13 09:22:35 -0500 received badge  Enthusiast
2015-05-13 05:41:47 -0500 received badge  Popular Question (source)
2015-05-11 08:23:16 -0500 asked a question meter_scoring: move_ base navigation

Hi all,

I'm using move_base for 2D navigation and it's working.the only thing is that i keep getting the a warn about having meter_scoring not set. the warn is the following:

Trajectory Rollout planner initialized with param meter_scoring not set. Set it to true to make your settings robust against changes of costmap resolution

And in my base_local_planner_params i set it to true. I'm having good and bad results from time to time, could this be the problem? what can i do to stop having this warn??

Thank you for your time,

Salvador

2015-05-09 02:56:06 -0500 received badge  Popular Question (source)
2015-05-08 07:19:25 -0500 commented question Navigation stack goal off global costmap

@Humpelstilzchen thank you for taking time to look at my question. It's resolved, I was publishing into the odom_combined frame and it has to be into the base_footprint frame.

2015-05-08 03:26:40 -0500 commented question Navigation stack goal off global costmap

I'm new at this so i don't know if a did it. i set all the parameters for the .yaml with http://wiki.ros.org/move_base#Parameters http://wiki.ros.org/costmap_2d#costma... http://wiki.ros.org/base_local_planne...

2015-05-08 03:20:32 -0500 commented answer Robot_pose_ekf bad frecuency

Yes i know that, the thing i need to know is ow to make my robot_pose_ekf to go faster

2015-05-07 11:05:48 -0500 asked a question Navigation stack goal off global costmap

Hi all

I'm using the navigation stack in my robot and every time i send a goal using rviz (2D Nav Goal) it throws me the following:

[ WARN] [1431013577.749213787]: The goal sent to the navfn planner is off the global costmap. Planning will always fail to this goal.

[ WARN] [1431013578.746803719]: The goal sent to the navfn planner is off the global costmap. Planning will always fail to this goal.

[ WARN] [1431013579.747597482]: The goal sent to the navfn planner is off the global costmap. Planning will always fail to this goal.

[ WARN] [1431013580.747194408]: The goal sent to the navfn planner is off the global costmap. Planning will always fail to this goal.

[ WARN] [1431013581.747623215]: The goal sent to the navfn planner is off the global costmap. Planning will always fail to this goal.

[ WARN] [1431013582.747012998]: The goal sent to the navfn planner is off the global costmap. Planning will always fail to this goal.

[ERROR] [1431013583.745273259]: Aborting because a valid plan could not be found. Even after executing all recovery behaviors

my global costmap is the following:

global_costmap:
  global_frame: /rosphere/odom_combined  
  robot_base_frame: /rosphere/base_footprint
  transform_tolerance: 5.0
  update_frequency: 0.5
  publish_frequency: 0.0
  static_map: false
  rolling_window: true
  width: 100.0
  height: 100.0
  resolution: 0.2

and the same for the local costmap, only changing the width, height and resolution (20,20, 0.05 respectively)

The goal I'm sending is just one meter from the base on x-axis so the action should be just to move straight forward. On Rviz the grid is set to 20 plane cell count and 1meter per cell.

I've changed the resolution, width and height of both costmaps and it's always the same. Any ideas? if you need more info just ask.

Salvador

2015-05-07 09:16:39 -0500 commented answer Robot_pose_ekf bad frecuency

Yes right now it's inside a room so it is just sending me zero coordinates but when i use it outside (receiving real data from satellites) it have the same rate.

2015-05-07 08:43:08 -0500 commented answer Robot_pose_ekf bad frecuency

I'm using an EM406 gps receiver with an integrated antena. It's conected to an ardupilot mega 2.5. The porpouse of it is to use gps navigation using ros navigation stack but i need to make my filter a bit faster for a better connection of both stacks. It's installed in the top of my robot. Salvador

2015-05-07 08:08:16 -0500 asked a question Robot_pose_ekf bad frecuency

Hi all,

I'm using the robot_pose_ekf whit odometry, imu and gps. It's pretty good by now, the only thing is that it's going too slow. When i make a "rostopic hz" to the odom_combined topic i get this:

salvador@salvador-VIT:~$ rostopic hz rosphere/odom_combined
subscribed to [/rosphere/odom_combined]
average rate: 0.933
        min: 1.072s max: 1.072s std dev: 0.00000s window: 2
average rate: 0.938
        min: 1.062s max: 1.072s std dev: 0.00497s window: 3

My .launch file is the following:

<?xml version="1.0"?>

<launch>
<arg name="use_cam" default="0"/>
<node pkg="rosphere" name="rosphere_AP_Comm" type="Ardupilot_control1c.py" ns="rosphere" output="screen" required="true"/>
<group ns="rosphere" if="$(arg use_cam)" >
    <include file="$(find raspicam)/launch/raspicam.launch"/>
</group>
<group ns="rosphere">
    <param name="tf_prefix" value="rosphere" />
    <node pkg="pose_ekf_rosphere" type="pose_ekf_rosphere" name="ekf_pose" output="screen">
        <param name="output_frame" value="odom_combined"/>
        <param name="freq" value="20.0"/>
        <param name="sensor_timeout" value="2.5"/>
        <param name="odom_used" value="true"/>
        <param name="imu_used" value="true"/>
        <param name="gps_used" value="true"/>
        <param name="odom_topic" value="odom_vel"/>
        <param name="imu_topic" value="imu"/>
        <param name="gps_topic" value="gps"/>
    </node>
</group>
<node pkg="tf" type="static_transform_publisher" name="base_to_imu_tf" args="0 0 0 0 0 0 /rosphere/base_footprint /rosphere/Imu 10"/>
<node pkg="rosphere" name="pose_to_odom" type="pose_to_odom.py" ns="rosphere" output="screen"/>
</launch>

the "rostopic hz" for odometry, imu and gps is:

salvador@salvador-VIT:~$ rostopic hz rosphere/odom_vel
subscribed to [/rosphere/odom_vel]
average rate: 19.753
        min: 0.020s max: 0.078s std dev: 0.01508s window: 14
average rate: 19.885
        min: 0.020s max: 0.078s std dev: 0.01462s window: 34
average rate: 19.744
        min: 0.020s max: 0.079s std dev: 0.01495s window: 39
salvador@salvador-VIT:~$ rostopic hz rosphere/imu
subscribed to [/rosphere/imu]
average rate: 21.394
        min: 0.020s max: 0.087s std dev: 0.01867s window: 14
average rate: 19.404
        min: 0.020s max: 0.095s std dev: 0.01794s window: 30
salvador@salvador-VIT:~$ rostopic hz rosphere/gps
subscribed to [/rosphere/gps]
average rate: 1.040
        min: 0.962s max: 0.962s std dev: 0.00000s window: 2

In the code odomestimation_test.cpp i setup for the filter loop to only check for odometry and imu constantly and check for gps only when new gps data has arrived by commenting a simple line :

//if (gps_active_)   filter_stamp_ = min(filter_stamp_, gps_stamp_);

This give me an error print but it should make my filter faster than the gps (the gps sensors are to slow compared to odometry or imu sensors).

If i don't comment this line, it prints a lot of time an info telling that the filter will not update with no change of time (it's obvious because the filter is trying to update at 20hz but the data is being processed at gps rate 1hz).

With all of this changes my filter should be processing the information at odometry or imu rate but it still update at ... (more)

2015-05-06 15:45:37 -0500 received badge  Popular Question (source)
2015-05-05 07:35:19 -0500 asked a question Move_base with non-rotational robot

Hello,

I'm using move_base with a non-holonomic, non-rotational robot. Everything is working as it should but i have a big problem and it's that my robot can't make in-place rotations. It's a robot sphere as you can see in the following links:

https://www.youtube.com/watch?v=1DlGn...

https://www.youtube.com/watch?v=XrpZt...

I set the following base local planner parameters:

## Base local planner parameters. 
TrajectoryPlannerROS:
  acc_lim_x: 1.0
  acc_lim_y: 0.0
  acc_lim_theta: 0.1
  max_vel_x: 2.2
  min_vel_x: 0.55
  max_vel_theta: 0.2
  min_vel_theta: -0.2
  min_in_place_vel_theta: 0.0
  escape_vel: -0.55
  holonomic_robot: false
  yaw_goal_tolerance: 0.1
  xy_goal_tolerance: 5.0
  sim_granularity: 0.1
  angular_sim_granularity: 0.04
  vx_samples: 5
  vtheta_samples: 8
  meter_scoring: true
  pdist_scale: 0.6
  gdist_scale: 0.8
  occdist_scale: 0.01
  dwa: false
  global_frame_id: odom_combined
  oscillation_reset_dist: 0.0

Is there a way to set off the in-place rotations? The other thing is that every time the program send an in-place rotation into the /cmd_vel topic, it puts a value of 1.0 or -1.0 on the angular z as shown below

---
linear: 
  x: 0.0
  y: 0.0
  z: 0.0
angular: 
  x: 0.0
  y: 0.0
  z: -1.0
---

Why is it doing this if i have set the max_vel_theta to 0.2 and the min_vel_theta to -0.2?

Also, when passing short distancies to move form base_footprint it send commands to cmd_vel like the following:

---
linear: 
  x: 0.414027588531
  y: 0.0
  z: 0.0
angular: 
  x: 0.0
  y: 0.0
  z: 0.894736842105
---

being this unrelated to the values set in the base_local_planner_params.yaml where min_vel_x is 0.55 and max_vel_theta is 0.2.

I've tried changing the min_in_place_vel_theta from 0.0 to 0.5 to see if it takes it as the in-place rotational value but it keep showing me the same thing. Tried setting from true to false the dwa for small values of vel_theta and got the same thing.

If anyone have an answer to all of the questions or even a single one it'd be really good!. If you need some more information just ask. Thanks for your time.

Salvador