Steven_Daniluk's profile - activity

Yep, you are correct. That's my bad, this is what happens when you write code snippets directly in a comment. I've edite

Boost does not seem necessary in this case. You can simply declare theta1f, theta2f, and theta3f as properties of your c

I've never come across ay "advanced" tutorials for amcl, gmapping, or hector_slam. However, I would strongly recommend reading Probabilistic Robotics. It covers the core components of amcl, and if your are not familiar with any of the subject matter then it should give you the prerequisite knowledge to understand the concepts behind gmapping, hector_slam, and many others. You could also look at the published papers for mapping, which is listed on the OpenSLAM site here and the hector_slam paper which is listed on that package's wiki here.

As for contributing and learning the codebases, amcl and mapping are quite old, so there doesn't seem to much for active development currently. hector_slam is newer, so they may still be some development going on for that. My recommendation would be to study the theory, review the code to understand it, and follow any current issues on each packages github repo and see if you could contribute that way.

So if I understand this correctly, the python node you have included is working properly, but the problem is in your separate C++ node? If that is the case, then it would help to post the code for the second node as well.

That information should be present in your TF tree, so you should not need to explicitly tell amcl what that transform is.

The LaserScan messages that amcl subscribes to should have a frame id in the header of each message. amcl will then transform the data in the scan message from the message frame id, to whatever frame is specified in the amcl parameter base_frame_id. The transform predicted by amcl (i.e. your pose in the global frame) will hence be relative to the base_frame_id.

So, make sure you are publishing transforms from your scanner frame id, to the base frame id, and that those transforms represent the appropriate offset of the physical scanner from the base frame (where the base frame origin should be the centre of rotation of your robot).

To build everything, first run catkin_make, this will build the rest of your package. The from your workspace run rosserial_arduino make_libraries build/my_package to build the messages, then catkin_make my_package_arduino_my_script_name to build your script. Change the names accordingly.

A workaround is to build the messages for rosserial_arduino and your arduino script, separately from the rest of your package. In the package's CMakeLists.txt remove "ALL" from rosserial_add_client_target(arduino my_script_name ALL), this will prevent CMake from automatically building the script.

So it's working now?

Does your error match this issue? Also, just in case, would you happen to be doing compact.launch instead of minimal.launch when the kobuki has already been launched? Because compact.launch would be trying to start another nodelet manager.

Generally, beyond topics and parameter requests, what other data would rosserial_python send to the client (e.g. rosserial_arduino)? I’d appreciate if someone could provide some insights, particularly related to the situation I describe.

I’ve experienced some odd behaviour that appears to be due to the client getting overloaded with data from sources other than the topics being subscribed to. This may be the wrong conclusion, in which case I’d appreciate being corrected. Everything I describe is with ROS Indigo.

The setup:

• Board: Arduino Nano
• Sketch Size: ~80% of dynamic memory
• Baud rate: 57600
• Node X on laptop publishes topic A with two uint8 values at 50Hz
• Node Y on arduino subscribes to topic A, checks for interrupts on pins, then publishes interrupt data on topic B with two uint8 values at 50Hz, and topic C with one uint32 value at 50Hz
• Node Z on laptop subscribes to topics B and C

All of the above works properly when running alone. However, if I do any of the following I will receive erratic data from the interrupts, along with serial port read failure warnings:

• Run Ruiz
• Run rqt_plot
• Write log outputs from a node on the laptop at a high frequency (e.g. 50Hz)

Adjusting the baud rate, both up and down did not resolve the issue. I also experimented with with limiting the number of publishers, subscribers, and buffer lengths for the nodehandle on the arduino. The default for the board is 25 publishers and subscribers, with buffer lengths of 280 bytes. I’ve reduced the subscribers to 2, and publishers to 3, and tried increasing/decreasing the buffer lengths independently to find the min/max workable values for the send and receive buffers. No combination resolves the problem completely.

Interestingly, if I lower the send buffer to 100 bytes, and increase the receive buffer to 512 bytes, the erratic behaviour is not present when only rqt_plot is running, but is present if rqt_plot and Rviz (or some combination of the above) are running.

Everything I’ve described I’ve been able to consistently recreate.

I’ve since switched to using rosserial_server instead of rosserial_python, and everything works properly without any warnings (although rosserial_server may not print the same packet warnings). Due to this, I don’t believe there is any faults with my arduino sketch or my use of interrupts. However, I’m still curious as to what would have caused this behaviour.

When using rosserial_python I believe the client is getting overloaded with data, possibly in the form of topic advertisements or outputs from rosconsole. Would this conclusion be correct? If so, would there be any ways to mitigate this problem?

The launch file for pleora_polarcam_driver is passing in an argument for the ip address. Do you also supply that argument when starting it with rosrun?

If that answers everything of you please mark this as answered by clicking the up arrow beside the answer. This way when someone else searches for a similar question, they will see this one marked as answered.

Yeah basically. For any nodes you want running on the robot, the package will need to be on that computer (and built), then you ssh in (from the desktop) and launch it. Alternatively, nodes that don't have to run on the robot computer can be run on the desktop.

I believe you need to first setup the action server with:

roslaunch kobuki_auto_docking minimal.launch

Then you can activate auto docking with:

roslaunch kobuki_auto_docking activate.launch

There is more info on the auto docking tutorial, but it sounds like you just missed step one.

You're on the right track. Basically you need three things: ROS on the netbook, ROS on the macbook, and those two computers talking to each other.

You can follow the ROS Tutorials which will guide you through installing in understanding ROS.

For your macbook, you will need a virtual machine. ROS is not yet fully supported for OSX, and attempting to install it can be quite difficult. I personally use Parallels on my macbook, but other options would be VMWare, or VirtualBox. However, I don't believe VMWare supports virtual graphics acceleration, which is quite important for any visualization work. Once you have Ubuntu installed on your virtual machine, you follow the same install instructions from the ROS Tutorials link above.

For the netbook, you are correct, you can install a "bare bones" version of ROS. This simply means that you get all of the ROS functionality, minus anything GUI related, since robots don't often have screens to utilize the GUI applications. On these Install Instructions you would simply use the command for ROS Base, instead of Desktop Full. You can of course install the full version if you like in same way you would have done for the macbook.

To get the two computers talking to each other you'll need to setup your network. The Turtlebot tutorials have a nice page about this here, which I would suggest following.

After that you should be good to go!

Can you add the launch file for the driver to your question? If the node can work properly, yet it simply fails when started from a launch file, it could be due to namespace changes or topic remappings that occur within the launch file.

Ah, I missed that from your log output, sorry. I also missed that it states the subscriber buffer size as 512 bytes. Would you be calling spin() on the arduino close to how frequently the messages are being published? Just to avoid messages piling up.

My first thought is that you are trying to send too much data over serial. You mention that the messages that you are receiving contain a pose and two floats. That means they are (7*64 + 32 + 32) bits per message. This gives ~512 bits per message, and you are subscribing to two topics containing these messages.

If you are using the default baud rate of 9600, you will likely have issues. If both of your topics were publishing at 20Hz, that would result in 20,480 bits/s (202512). Plus there should be a bit of overhead for communication on top of that.

Also, I believe rosserial_arduino's buffer is about 80 bytes (I read that somewhere, but I cannot recall where). Two of your messages consume 128 bytes, which would be problematic if my memory of an 80 byte buffer is correct.

So, your options then would be:

• Increase the baud rate, and hope the buffer is not the limiting factor
• Find a way to reduce your message size (do you need all 6 degrees of freedom in the pose?)
• Throttle the frequency which your messages are published (can whatever your messages are being used for respond at that rate?)

You can increase the baud rate with the arduino by adding to your arduino script:

nh.getHardware()->setBaud(57600);

Along with the parameter for the rosserial_arduino node:

<param name="baud" value="57600"/>

No worries. Just always try to look at the documentation for whatever you are doing. Most information you need is usually there.

No, that means 1 radians/sec. As per the definition of max_vel_theta on the base_local_planner link I provided: "The maximum rotational velocity allowed for the base in radians/sec".

It is possible. But without knowing anything about your robot I can't say for sure, I just though I would mention it since you emphasized the behaviour on carpet. A robot with small wheels, weak motors, and on plush carpet, could have difficulty moving.

Yes, the file base_local_planner_params.yaml will control the turning speed (as well as the longitudinal speed). Specifically, the parameters: max_vel_theta, min_vel_theta, and min_in_place_vel_theta. These are standard parameters for the base_local_planner package. You will find their definitions here.

The second file you reference contains parameters for the costmap, which you can read more about here.

However, the maximum velocity setting may not be you problem. When turning on carpet you could be power limited, or also be experiencing excessive slip, which will not only lengthen the turning time, but also add time just for the localization to realize the robot has not turned sufficiently far.

Boost does not seem necessary in this case. You can simply declare theta1f, theta2f, and theta3f as properties of your class listener. Since you create a Listener object in main, you would then have access to its properties. Basically, whenever you have a callback function for messages, you will need to use a class to utilize the data from that callback somewhere else. Like this:

class Listener 
{
  public:
    double theta1f;
    double theta2f;
    double theta3f;

    void callback(const std_msgs::Float32MultiArray::ConstPtr& msg);
};

void Listener::callback(const std_msgs::Float32MultiArray::ConstPtr& msg) 
{
    theta1f = msg->data[0];
    theta2f = msg->data[1];
    theta3f = msg->data[2];
}

int main(int argc, char **argv) 
{
    ros::init(argc, argv, "node_joint");
    ros::NodeHandle nh;
    ros::Rate loop_rate(30); 
    Listener listener;
    ros::Subscriber sub = nh.subscribe<std_msgs::float32multiarray>("topic_subscribed", 1, &Listener::callback, &listener);
    while (ros::ok()) 
    {
        ros::spinOnce();
        ROS_INFO("This is theta1f: %.2f", listener.theta1f);
        ROS_INFO("This is theta2f: %.2f", listener.theta2f);
        ROS_INFO("This is theta2f: %.2f", listener.theta2f);
        loop_rate.sleep();
    }

    return 0;
}

Also, in general it is discouraged to use global variables unless absolutely necessary.

EDIT: This issue appears to be cause by a problem with rosserial not being able to find custom messages that are defined in the same package as the firmware. There is an issue on the rosserial github repo about this. The error below was an artifact of this problem. Since this seems to be a specific issue with rosserial, and they are aware of it, I'm going to close this question.

I have a script running on an arduino that uses custom messages, and it has worked successfully while being compiled and uploaded with the Arduino IDE. However, now I am attempting to use the CMake build system, and when running catkin_make I get an error that some includes in the pre-generated message header cannot be found:

Building CXX object CMakeFiles/nano328_arduino.dir/my_script_name.cpp.obj
In file included from /path_to_my_script/my_script_name.cpp:33:0:
/path_to_my_workspace/devel/include/my_package/MyMessage.h:9:18: fatal error: string: No such file or directory
 #include <string>

My arduino script first includes Arduino.h, then ros.h, then my message. The top of the generated message header is as follows:

#include <string>
#include <vector>
#include <map>

#include <ros/types.h>
#include <ros/serialization.h>
#include <ros/builtin_message_traits.h>
#include <ros/message_operations.h>

#include <std_msgs/Header.h>

It appears that the arduino target isn't being linked against the C++ standard libraries and can't find string, vector, or map. This is only for the arduino script, all my other executables using these messages build successfully.

A few interesting things:

• Initially this was building successfully, but after cleaning my workspace by deleting the devel and build folders I get this error
• If I build this from within the CLion IDE there are no errors and the arduino script is built successfully

Any ideas what I could be missing here? It is very strange that the catkin build fails while the CLion build succeeds.

Based on every example I have found I believe both of my CMakeLists are correct, but I will post them anyways. Here is the relevant sections of my CMakeLists.txt in my package directory:

cmake_minimum_required(VERSION 2.8.3)
project(ghost)

## Find catkin macros and libraries
find_package(catkin REQUIRED COMPONENTS
  cv_bridge
  image_transport
  message_generation
  nodelet
  roscpp
  rosserial_arduino
  rosserial_client
  sensor_msgs
  std_msgs
  tf
)

## Declare custom messages
add_message_files(
  FILES
  MyMessage.msg
)

generate_messages(
  DEPENDENCIES
  std_msgs
)

# Declare the catkin package
catkin_package()

## Specify additional locations of header files
include_directories(
  ${catkin_INCLUDE_DIRS}
)

# Library generation for Arduino
rosserial_generate_ros_lib(
  PACKAGE rosserial_arduino
  SCRIPT make_libraries.py
)

# Arduino target setup
rosserial_configure_client(
  DIRECTORY arduino
  TOOLCHAIN_FILE ${ROSSERIAL_ARDUINO_TOOLCHAIN}
)
rosserial_add_client_target(arduino my_script_name ALL)
rosserial_add_client_target(arduino my_script_name-upload)

And here is the CMakeLists.txt in the arduino folder:

cmake_minimum_required(VERSION 2.8.3)

include_directories(${ROS_LIB_DIR})

generate_arduino_firmware(controller_interface
  SRCS controller_interface.cpp ${ROS_LIB_DIR}/time.cpp
  HDRS PinChangeInt.h
  BOARD nano328
  PORT /dev/ttyUSB0
)

It appears that your code "minip" is publishing the topic visualization_marker, as indicated by the line:

vis_pub = n.advertise<visualization_msgs::Marker>( "visualization_marker", 1    );

but there is nothing in the "minip_gui" code that subscribes to that topic. As for the gui_goal topic, "minip_gui" is the publisher "minip" is the subscriber, which is the opposite of what is stated in your question.

Also, you should not create multiple nodehandles when it is not necessary to do so. You seem to have declared one nodehandle in main, and another in _save_current_pos, both of which are named n. There are valid reasons for having multiple nodehandles, as mentioned here, but in your case I don't see what it is necessary.

I would also suggest getting in the habit of following the ROS C++ Style Guide. Particularly for the use of global variables in your code, but also for formatting and style in general.

What are the contents of the messages you are publishing/subscribing too, and their frequencies? Also, do you have the baud rate set to something other than the default? It is possible to overload the arduino connection with messages.

A Gentle Introduction to ROS is another source that is helpful, it provides a concise explanation of the core functionality of ROS. But, personally I think "Programming Robots with ROS" is actually a bit more gentle than "A Gentle Introduction to ROS".

Also, if all you need is the cv::Mat image you can copy it in one line:

cv::Mat image = cv_bridge::toCvCopy(msg, sensor_msgs::image_encodings::BGR8)->image;

When I put the contents of your try block in the cv_bridge tutorial script and subscribe to a topic from a bag file I don't get any errors. Could it be an encoding issue, or a bad bag file?