A problem in transfering neagtive values to Arduino via std_msgs/Float64 [closed]
Hi all! I've got a problem in Indigo during transferring negative values to Arduino using "geometry_msgs/Twist". A project with the simple functionality - a PS3 joystick is sending data via "joy" topic to my node (based on turtlebot_teleop) using "sensor_msgs/Joy". In case of LB1 pressed, my node is sending data from the left joystick to an Arduino controller using "geometry_msgs/Twist". For example, in case joystick is moved to maximum left - it's angular.z=1.5 in case joystick is moved to maximum right - it's angular.z=-1.5. After receiving message, arduino is moving servo - in case of positive angular.z clockwise, in case of negative angular.z anti clockwise. Arduino code: baseServoAngle += SERVO_STEP*inputMsg.angular.z; When I do "rostopic echo" for the topic with Twist messages both negative and positive values in the vectors are correct. But, when I'm reading it in Arduino and sending it back via "arduino" topic with std_msgs/Float64 to check, I see same correct numbers for the positive values and something like -1.23423546574e-308 for the negative values (instead of -1.5). Farther testing demonstrated that the problem is with the std_msgs/Float64 (because of this is the type for x,y,z in vectors in twist message). After that, I've tested std_msgs/Byte and std_msgs/Float32 and it worked correct both for positive and negative numbers. But because of Twist messages using is more convinient for me, I'd like to fix the problem. I will be grateful for any help.
Node code:
#include <ros/ros.h>
#include <geometry_msgs/Twist.h>
#include <sensor_msgs/Joy.h>
#include <std_msgs/Float64.h>
#include <std_msgs/Byte.h>
#include "boost/thread/mutex.hpp"
#include "boost/thread/thread.hpp"
#include "ros/console.h"
class EmilsHandTeleop
{
public:
EmilsHandTeleop();
private:
void joyCallback(const sensor_msgs::Joy::ConstPtr& joy);
void publish();
ros::NodeHandle ph_, nh_;
int linear_, angular_, deadman_axis_;
double l_scale_, a_scale_;
ros::Publisher vel_pub_, servo_pub_;
ros::Subscriber joy_sub_;
geometry_msgs::Twist last_published_;
std_msgs::Byte servoMsg;
boost::mutex publish_mutex_;
bool deadman_pressed_;
bool zero_twist_published_;
ros::Timer timer_;
};
EmilsHandTeleop::EmilsHandTeleop():
ph_("~"),
linear_(1),
angular_(0),
deadman_axis_(4),
l_scale_(0.3),
a_scale_(0.9)
{
ph_.param("axis_linear", linear_, linear_);
ph_.param("axis_angular", angular_, angular_);
ph_.param("axis_deadman", deadman_axis_, deadman_axis_);
ph_.param("scale_angular", a_scale_, a_scale_);
ph_.param("scale_linear", l_scale_, l_scale_);
deadman_pressed_ = false;
zero_twist_published_ = false;
vel_pub_ = ph_.advertise<geometry_msgs::Twist>("cmd_vel", 1, true);
servo_pub_ = ph_.advertise<std_msgs::Byte>("servo_test", 1, true);
joy_sub_ = nh_.subscribe<sensor_msgs::Joy>("joy", 10, &EmilsHandTeleop::joyCallback, this);
timer_ = nh_.createTimer(ros::Duration(0.1), boost::bind(&EmilsHandTeleop::publish, this));
}
void EmilsHandTeleop::joyCallback(const sensor_msgs::Joy::ConstPtr& joy)
{
geometry_msgs::Twist vel;
vel.angular.z = a_scale_*joy->axes[angular_];
servoMsg.data = a_scale_*joy->axes[angular_];
vel.linear.x = l_scale_*joy->axes[linear_];
last_published_ = vel;
deadman_pressed_ = joy->buttons[deadman_axis_];
}
void EmilsHandTeleop::publish()
{
boost::mutex::scoped_lock lock(publish_mutex_);
if (deadman_pressed_)
{
vel_pub_.publish(last_published_);
servo_pub_.publish(servoMsg);
zero_twist_published_=false;
}
else if(!deadman_pressed_ && !zero_twist_published_)
{
vel_pub_.publish(*new geometry_msgs::Twist());
zero_twist_published_=true;
}
}
int main(int argc, char** argv)
{
ros::init(argc, argv, "emils_hand_teleop");
EmilsHandTeleop ...
Can you still demonstrate the problem with a MWE? If so, please report it to the
rosserial
issue tracker. All the teleop and servo code is unnecessary if the issue is withFloat64
.Yes, you are right. It became obvious, that the problem is with the "deserialize" method in "Float64" class, defined in sketchbook/libraries/ros_lib/std_msgs/ Because of I was too lazy to investigate what is wrong with it and, I've changed it to the same method from Float32.h and it's working.
Right. It think it would be a good idea if you reported this on the issue tracker. If what you say is true, this sounds like a bug.