codenotes's profile - activity

Can robot_localization be used without fusing multiple sources, ie, as a simple filter for odometry alone? I do not need or want to fuse an IMU with odometry, rather I simply want to smooth out the existing odometry.

Although the use-case may seem odd, I have a motion-capture system that gives more-or-less a real-time transform for the robot. However the mocap reported transform jitters a bit, and rarely it will jump in and out of an outlier. I could address this with a moving-average filter (too slow) or another more traditional filter (some might argue Kalman may be overkill) but I'd prefer to use the robot_localization infrastructure. In the future I may have other sensors to fuse and it makes sense to architect this system around RL.

If one has a mocap system that is giving reasonable x,y positioning coordinates but one still wants/needs to fuse that with an IMU with robot_localization, it seems I would be forced to turn my X,Y coordinates from the mocap into NavSatFix messages, (ie, GPS coordinates) such that they can be fed to robot_localization. I could do this via UTM, but this seems really inefficient.

(While one might think the mocap itself would be enough to localize, some mocap systems still jitter somewhat and can have some big outlying readings, particularly when the robot gets close to the boundaries of the system. Fusing IMU data with would be an ideal good solution.)

I'd like to be able to feed robot_localization these mocap X,Y coordinates in liu of NavSatFix messages.

Is there a recommended approach for this?

Best, Gregory

Getting linking errors on everything in roscpp, serialization, console, etc. CMakelist looks correct (have read and tried all recommend postings. Can also compile other parts of the package that link with roscpp.). The failure occurs on with this library. Type of errors are like: undefined reference toros::console::initialize()'` for example.

This is the cmakelist.txt, and it references roscpp, and also catkin_LIBRARIES has the correct capitalization...everything seems as it should be. Apologies for the formatting, used "code block" but it doesn't stick.

cmake_minimum_required(VERSION 2.8.3)
project(imu_complementary_filter)

find_package(catkin REQUIRED COMPONENTS
  cmake_modules
  message_filters
  roscpp
  sensor_msgs
  std_msgs
  tf
  genmsg

)

find_package(Eigen REQUIRED COMPONENTS)

catkin_package(
  DEPENDS Eigen
  INCLUDE_DIRS include
  LIBRARIES complementary_filter
  CATKIN_DEPENDS message_filters roscpp sensor_msgs std_msgs tf 
)

include_directories(
  include
  ${catkin_INCLUDE_DIRS}
  ${Eigen_INCLUDE_DIRS}
)

add_library(complementary_filter
  src/complementary_filter.cpp
  src/complementary_filter_ros.cpp
  include/imu_complementary_filter/complementary_filter.h
  include/imu_complementary_filter/complementary_filter_ros.h
)

add_executable(complementary_filter_node
  src/complementary_filter_node.cpp)
target_link_libraries(complementary_filter_node complementary_filter ${catkin_LIBRARIES} ${Eigen_LIBRARIES})

install(TARGETS complementary_filter complementary_filter_node
  ARCHIVE DESTINATION ${CATKIN_PACKAGE_LIB_DESTINATION}
  LIBRARY DESTINATION ${CATKIN_PACKAGE_LIB_DESTINATION}
  RUNTIME DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION}
)


install(DIRECTORY include/${PROJECT_NAME}/
  DESTINATION ${CATKIN_PACKAGE_INCLUDE_DESTINATION}
  FILES_MATCHING PATTERN "*.h"
  PATTERN ".svn" EXCLUDE
)

Can't seem to make full use of ros::param::getCached....while I CAN retrieve a value that is set on rosmaster, I get this error continuously:

[DEBUG] [1479155346.850264931]: XML-RPC call [subscribeParam] returned an error (-1): [ERROR: parameter [caller_api] is not an XMLRPC URI]

[DEBUG] [1479155346.850767245]: Subscribe to parameter [/boob]: call to the master failed

This message comes from some python validator on the roscore side I think...and there my debugging ability will fail me.

Can I get some insight into what might be going on? My ROS_MASTER_URI is not remarkable and my general ROS nodes operate correctly.

windows has a package manager now (apparently) vcpkg or something. Maybe I just package for that. Well, one way or anoth

it's all good...your comment jives with my read of the source...but there's a lot going on, so just wanted to make sure.

I do plan to share, absolutely. Not sure of the best way...I could document my steps for others to reproduce via a ROS

BTW, thank you for the answer here...that puts my fears at rest. It is pretty cool to be doing roscore and the console

In preparing/configuring networking for a ROS environment, I have noticed that ROS subscribers (and rosout) opens UDP ports.

(from TCPView)

KineticListener.exe **4908  UDP ASHTRAY-1** 52513   *   *                                           
KineticListener.exe 4908    TCP ashtray-1   51328   desktop-mp2jcia 3143    ESTABLISHED

Given I am using TCPROS, I am wondering why this is so and what this 52513 port is for. UDP is not optimal, because I can't route UDP through the NAT, so if these UDP ports are important for something I may not be able to work around it. (rosout.exe also opens UDP, but it is a subscriber, so I think all subscribers do it).

I would just like to know: What is this UDP port for? I would like to ignore it, because I can't (for many reasons) route UDP through the firewall.

NOTE: if you notice the .exe extension and such, yes...this is a ROS installation (kinetic) on windows. I have ported the ROS client libraries and the python infrastructure (roscore, etc.) and they work very well with very little modification.

Actually, NOT cygwin, pure windows. I became frustrated with the cygwin layer and just sat down for a couple days and

What is the UDP port subscribers open up? In preparing/configuring networking for a ROS environment, I have noticed that

I am trying to understand the responsibility I have with regards to publishing the odom TF frame. Specifically, we have a mobile robotic system that is intended to (and does) operate via ROS and are finalizing complete robotic control stack.

There is a lot written (and have read/reread) about the map --> odom --> base_link relationship. I understand that the odom frame is 1) where the robot starts in a map and 2) can "drift." But what I would like to understand is what, specifically, needs to be/should be done programatically to move the odom frame as my robot progresses. It seems to be my responsibility to translate what is going on into this "drift", and thus, I should publish a map->odom->base_link transform tree and should be "drifting" the odom frame? But how should this be done? Move it where and by how much relative to the uncertainty? Or am I not understanding: I often read that it is the localization nodes that publish the map->odom relationship.

(it also seems strange to me that, if I understand correctly, I am to drift the odom transform which is where the robot starts as opposed to base_link, where it is presently)

I understand that wheel odometry error and uncertainty accumulates as the robot moves and I too understand how calculate and keep track of that uncertainty. Again, seeking clarification on what one is supposed to do with that knowledge with regards to moving the odom frame? Where do I move it and by how much?

(Most of what is written on the subject [and there is a fair amount] is helpful if you are writing a client or trying to get a platform performing SLAM in gazebo, but it isn't clear how it is supposed to work if you are authoring the actual controlling components and stack. Have read rep 105, and all postings I can find on ROS answers, but would greatly appreciate some clarification.)

While I am not familiar with the arduino variant of ROS, It sounds like you are thinking of a ROS subscriber as a queue that you manually pull from. It may be that internally..but it exposes a callback mechanism that you are to use. Internally there is, I think, a circular buffer you could possibly access, but this is not commonly done.

I may not fully understand what you mean by "newest" message. If you mean, the message that your client application receives in its callback as a result of calling spinOnce, well then you are already getting the "newest"...your client (at least on normal ROS) has, if I remember correctly, a circular buffer that enqueues messages it receives FIFO style; if you don't process those messages at the front thenI believe they are pushed into oblivion once new messages come in from the rear in order to maintain the fixed size of the queue. That said, I don't believe we have threads on arduino, so I would guess you have to be calling that spinOnce() call at a greater frequency than the messages are coming in...otherwise I think you could have stale or old messages in your queue because I don't believe ROS on Arduino could update that queue otherwise.

In short, I think if you are processing messages on the client (calling spinonce) at a faster rate then they are coming in, and with a small queue, you should always get the "newest". You might also create a local buffer that queues all messages and then you can do whatever you like with them...pull from the tail, front, etc.

I would add that doing some subsequent research, these errors happen and I fail when using:

ros::param::getCached()

however:

somenodehandle.getParamCached() DOES seem to work.

so I think maybe the docs should specify that ros::param::getCached() is probably not to be used. If you want updated parameters, one needs to go through a valid nodehandle.