cnanda84's profile - activity

Hi, Just that the callback signature needs to be of the type sensor_msgs::TemperatureConsPtr, instead of just sensor_msgs::Temperature. Saw that in some of the questions posted adjacent to this thread.

I assume that I will have to write a script to monitor that . So closing the topic.

Hi All,

I am using ros indigo on Ubuntu 14.04 on an intel i7 platform. I am trying to subscribe to a sensor that is publishing two messages , temperature and humidity. On my subscriber I am using approximate time sync feature to get both messages. I am having trouble linking the code. I guess a fresh pair of eyes could help.

publisher is publishing messages of type : sensor_msgs::Temperature and sensor_msgs::RelativeHumidity.

On subscriber I have the following :

define TEMP_SENSOR_MSG_TYPE sensor_msgs::Temperature define RELATIVE_HUM_MSG_TYPE sensor_msgs::RelativeHumidity typedef message_filters::sync_policies::ApproximateTime<temp_sensor_msg_type,relative_hum_msg_type> AppxSyncSensor;

 message_filters::Synchronizer<AppxSyncSensor> *syncApproximateSensor;

 message_filters::Subscriber<TEMP_SENSOR_MSG_TYPE> *tempSubscriber;
 message_filters::Subscriber<RELATIVE_HUM_MSG_TYPE> *humSubscriber;

image_transport::TransportHints hints(useCompressed ? "compressed" : "raw"); hintsM_ = hints;

    tempSubscriber = new message_filters::Subscriber<TEMP_SENSOR_MSG_TYPE>(nh, tempTopicName, queueSize);
    humSubscriber = new message_filters::Subscriber<RELATIVE_HUM_MSG_TYPE>(nh, humTopicName, queueSize);



    syncApproximateSensor = new message_filters::Synchronizer<AppxSyncSensor>(AppxSyncSensor(queueSize), *tempSubscriber, *humSubscriber);
    syncApproximateSensor->registerCallback(boost::bind(&Receiver::sensorDataCallback,this,_1,_2));

Error: attached log file.C:\fakepath\error_logs_temp_sensor.bmp

-Cheers cn

Anyone has a comment? Did I explain the question well enough ?

Hi, I am using ROS indigo. I am creating a custom config file for my project that helps me to control the size of the log files,and define it if should be rolling . Is there a way to limit / control the size of default ros log that goes into .ros/log ? Or define the number of files it can generate after which it starts overwriting the first file ?

So it is more of a system maintenance question, will the logs files roll over once it crosses a certain limit or will it continue creating new logs files ?

Do I have to write a script to take care of that ?

-Best c-nanda

Sorry my bad , the problem was with device firmware.

Hi,

I ported some code for a camera in C++ for ROS and subscribing to another node to capture images from it. This camera node has a start method that issues a callback function that delivers the frames. The first captured frame from the camera is very critical as I plan to do this across multiple cameras so the first frame would be ideally at the same time ( assuming the camera nodes are time synced ). 1.First question , is it possible to expect that the ROS system can respond to the callback in this way ? 2. I am observing that within the camera node , the camera driver drops the first few frames complaining that USBIO Bulk transfer failed. After printing this out for the first few frames, it works fine. I am guessing that ROS is not able to service my callback on time. The camera driver by itself doesn’t show this problem, when it is working outside the ROS environment. 3. I am calling ros::SpinOnce() , within my code just before I call the start method on the camera.

I am relatively new to ROS and was trying to dig around but couldn’t find or understand anything conclusive. If some one could share some code explanation with some code example for this case it would be great!

-Best CN

Another unrelated question, so if my code hangs in between( some software bug ). Will the re-spawn feature help me restart the node ? Also, can I expect it to restart the node in case of a segmentation fault ?

A simple related question, can this feature be used for a nodelet as well ? Or is it only meant for a node ? I didn't explicitly mention it but we are using a nodelet when observing this problem.

When using a respawn ="true" in the launch file, does ros automatically terminate the associated process or does that have to be handled by the user somehow. We are using kinect2_bridge nodelet and see that under some circumstances, when it crashes, fails to recover as the associated process is still hanging around or complains that a old node with the same name already exists. Manually looking for a process with ps -lae | grep nodelet and then killing it solves the problem.
Will increasing the delay help ? -cn

When using a respawn ="true" in the launch file, does ros automatically terminate the associated process or does that have to be handled by the user somehow. We are using kinect2_bridge nodelet and see that under some circumstances, when it crashes, fails to recover as the associated process is still hanging around or complains that a old node with the same name already exists. Manually looking for a process with ps -lae | grep nodelet and then killing it solves the problem.
Will increasing the delay help ? -cn