0
$\begingroup$

Rosanswers logo

Hi,

I've been debugging my code recently and I've encountered this strange value assignments in my code (e.g. double value was set to 48342750631830156809646198744631837214400839096756594218130390397264833847717452548524106800103300384016854007123474855776033541556472495167585138333188621137621421726366230289867389262961030442796182455676615285992044974047232 ) for not exactly obvious reasons.

I then figured out that it could be thread related problem, where what I'm doing is writing and reading this variable at the same time which causes this strange assignments, but I'm not exactly sure.

I'will show you simplified idea of my problem. Lets say I have this main method:

int main(int argc, char** argv){
    ros::init(argc, argv, "attitude_controller");
    ros::NodeHandle nh;

    attitude_controller_ = new AttitudeController(nh);

    ros::Rate rate(20.0);
    ros::Time previous_time = ros::Time::now();
    while(ros::ok()){
        ros::Duration time_difference = ros::Time::now() - previous_time;
        previous_time = ros::Time::now();

        attitude_controller_->control(time_difference);  

        ros::spinOnce();
        rate.sleep();
    }

    return 0;
}

And I have AttitudeController class which has FlyingStrategy class in it that looks similar to this:

class FlyingStrategy {
public:
    FlyingStrategy(const ros::NodeHandle& nh);

    virtual ~FlyingStrategy();

    virtual void init();

    void control(const ros::Duration& time_difference);

    void callbackCarrotPose(const geometry_msgs::PoseConstPtr& carrot_pose);

private:
    virtual void pidControlLoop(const ros::Duration& time_difference, const tf::StampedTransform& transform_world_base);

protected:
    ros::NodeHandle nh_;

    ros::Subscriber sub_carrot_pose_;
    tf::Vector3 carrot_;
};

The main functions are here callbackCarrotPose and control. callbackCarrotPose is just assignment like this:

void FlyingStrategy::callbackCarrotPose(const geometry_msgs::PoseConstPtr& carrot_pose) {
    carrot_.setX(carrot_pose->position.x);
    carrot_.setY(carrot_pose->position.y);
    carrot_.setZ(carrot_pose->position.z);
}

The problem in my opinion occurs when I'm trying to set carrot_ variable in callbackCarrotPose function and using this variable in control function at the same time. Because when I printed all the values coming to callbackCarrotPose function, all values were fine. But after printing them in control function sometimes the values were as show before.

How should I fix this issue then? Should I use some kind of thread lock in callback function and in my control function? And if so, how could I do it? I've not been using threads yet, so bear with me :).

Thank you for any advice.


Originally posted by l4ncelot on ROS Answers with karma: 826 on 2016-12-20

Post score: 0


Original comments

Comment by gvdhoorn on 2016-12-20:
Are you creating any threads in FlyingStrategy yourself? Because your main uses single-threaded eventqueue processing, so your callback cannot be called when attitude_controller_->control(time_difference) is executing.

Comment by l4ncelot on 2016-12-20:
No, I'm not creating any threads by myself. But I have some classes that inherit from FlyingStrategy and there I use polymorphism. So I constantly change type of FlyingStrategy. Could it be the case perhaps? I can describe it more accurately if you want to.

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

So after a while me and my friend figured this out. It wasn't thread related problem at all. I had in my class tf::Vector3object which I initialized only after callbackCarrotPose was called. And because tf::Vector3 has an empty constructor and it's member variable is some array, it never had any values before callbackCarrotPose was called, therefore those strange values occurred.


Originally posted by l4ncelot with karma: 826 on 2016-12-21

This answer was ACCEPTED on the original site

Post score: 0

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.