suforeman's profile - activity

I am implementing a drive controller which will implement a topic subscriber for the geometry_msgs::Twist message.

Is there a standard / normal range used for the X, Y, & Z values of the linear and angular members of the Twist message?

e.g. "0.0 to 1.0" or "-1.0 to 1.0" ?

I plan to support scaling but would like the default behavior to follow normal conventions and reduce the effort for users of my node.

Compare my void echo_groups (const groups::Groups::ConstPtr& msg) callback vs your void organizer_callback( const std::vector< std::vector<float> >& circles)

It looks as though you are still not using message definitions.

What are your message definitions for Circles.msg and Circle.msg? If they are the same as my answer example, then dp is a vector of floats. It's not clear what you are attempting with circles[gp][dp] = gp->circle(dp). Also, you code does not agree with the declaration.

You still appear to be trying to defining your topic subscriber without using your message definition. Compare your callback with the one in my answer's example. Try to get your subscriber working first. You can test your subscriber from the command line using rostopic.

You can make one node of your launch run as root - using launch-prefix - while keeping the rest running as user. Here is an example launch file:

<launch>
<node pkg="i2cpwm_board" name="i2cpwm_board_node" type="i2cpwm_board" output="screen" launch-prefix="sudo -E ">
</node>
</launch>

In this example, we need root access for the I2C device on a Raspberry Pi.

Assuming this is a duplicate, I posted an answer to the other question.

On Linux, a flexible solution is logrotate

It allows logs to be archived based on age and/or size; archives logs may be compressed; versions may be capped: etc

When using log rotate on a running system which is not coded to handle its log files being closed/moved by an external process, use the copytruncate option as it will preserve the open file handle(s) being used by other programs.

Yes. I am using it with Ubuntu 16.04 on Raspberry Pi for the LoCoRo project.

You might want to split this into two questions since they are independent of one another.

You can use robot_upstart to generate a "service" that will run a launch file. Within the launch file you may include your node(s), parameters, bag, etc.

The first step is to get a launch file which does everything you want. Do that before attempting to use robot_upstart and it will dramatically reduce debugging any issues you may have.

added CMakeLists.txt to answer

@sharan100 - I update my short answer with example code. It's not the prettiest but it does work.

I've had my best success by decomposing the message definition.

Working example:

Messages:

Group.msg:
    float32[] data
Groups.msg:
    Group[] group

CMakeLists.txt

cmake_minimum_required(VERSION 2.8.3)
project(groups)

find_package(catkin REQUIRED COMPONENTS roscpp std_msgs message_generation)

add_message_files(DIRECTORY msg FILES Group.msg Groups.msg)

generate_messages(DEPENDENCIES std_msgs)

catkin_package(CATKIN_DEPENDS roscpp std_msgs message_runtime)

include_directories(include  ${catkin_INCLUDE_DIRS})
link_directories(${catkin_LIBRARY_DIRS})


add_executable(groups src/groups.cpp)
target_link_libraries(groups ${catkin_LIBRARIES})
add_dependencies(groups groups_generate_messages_cpp)

install(TARGETS groups
    RUNTIME DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} 
        LIBRARY DESTINATION ${CATKIN_PACKAGE_LIB_DESTINATION} 
        ARCHIVE DESTINATION ${CATKIN_PACKAGE_LIB_DESTINATION} 
)
install(DIRECTORY include/${PROJECT_NAME}/ DESTINATION ${CATKIN_PACKAGE_INCLUDE_DESTINATION} FILES_MATCHING PATTERN "*.h" )
install(DIRECTORY launch/ DESTINATION ${CATKIN_PACKAGE_SHARE_DESTINATION}/launch )

Code:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#include <ros/ros.h>
#include <ros/console.h>                                                                                                                                                                           

// messages
#include "groups/Group.h"
#include "groups/Groups.h"

void echo_groups (const groups::Groups::ConstPtr& msg)
{
    for(std::vector<groups::Group>::const_iterator gp = msg->group.begin(); gp != msg->group.end(); ++gp) {
        for (std::vector<float>::const_iterator dp = gp->data.begin(); dp != gp->data.end(); ++dp)
            std::cout << *dp << ' ';
        std::cout << '\n';
    }
}

int main (int argc, char **argv)
{
    ros::init (argc, argv, "groups");
    ros::NodeHandle n;
    ros::Subscriber groups_sub = n.subscribe ("echo_groups", 8, echo_groups);
    ros::spin();

  return 0;
}

Test:

rostopic pub -1 /echo_groups groups/Groups "[data:[1.1, 1.2, 1.3], data:[2.1, 2.2, 2.3]]"

Output:

1.1 1.2 1.3 
2.1 2.2 2.3

I'm using Ubuntu Xenial (no GUI) with ROS Kinetic with good success. There are some caveats. The steps I've used are here: http://stemroller.com/page.php?page=s...

What hardware (system board / CPU) are you using? This can be relatively easy if you have an Arduino (or even s Raspberry Pi) in the mix.

As a companion comment,when running ROS + Ubuntu on a Raspberry Pi the SD card is not different than a USB memory stick. As long as the solid state memory storage is fast, it works well. Running with RAM based temp storage makes a significant improvement.

It looks like you have three sides to the triangle - hardware, operating system, and level of effort. If you prioritize using the Raspberry Pi above using Raspbian Jessie, then you could go with Ubuntu 16.04 and Kinetic. Or Debian Jessie and different hardware. Or ROS source and more effort.

The "service" is a procedure call and is synchronous. The caller waits from the response. The "topic" is asynchronous. The publisher of a message on a topic has no guarantee when the subscriber will process the message.

For clarification, the term "host" refers to the OS running on the hardware and "guest" refers to the OS running in the virtual machine.

I was indicating "being a virtual machine" is not an indictment. I run a 64bit guest on a 64bit host and performance and functionality is good. To be honest, I've never had an issue and didn't realize there was any bad history with ROS on a VM. The OP said 32bit host which is a limiting factor.

The VM is not likely the issue. I do nearly all of my ROS development and testing on a 2GB 1 CPU core VM. The difference being I run a 64 bit guest on a 64 bit host. It sounds like a few things may be happening with one of them being minimal hardware specs.

I did a couple internet searches and have two anecdotal posts. One person reported the astra + RPi resulted in slow(?) frame rates. Another person reported they increased the RAM allocated to the to 384(?).

It will depend on the DC motors. Are they brushed or brushless motors? What voltage is required? What amperage is required?

One option is to use an I2C PWM hat or shield and an electronic speed control (ESC) for each motor. This also allows up to 16 motors (more by combining shields).

The PWM + ESC allows for a wide range of voltages and amperages, depending on the ESC. Some common ESCs are 4.8-11V and 9-16v. There are some for even higher. ESCs are also rated by current units available for very high current such as 120A or more.

Here is documentation for an I2C PWM package for ROS: http://bradanlane.gitlab.io/ros-i2cpw...