Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Joint and motor state in Imotor #55

Closed
torydebra opened this issue Jun 23, 2020 · 3 comments
Closed

Joint and motor state in Imotor #55

torydebra opened this issue Jun 23, 2020 · 3 comments
Assignees

Comments

@torydebra
Copy link
Member

We need to differentiate the joint and motor states, but I am not sure on how to contort @liesrock HAL structure.

So,

  • we have IMotor interface, where getjointposition, velocity, effort must be added

  • In EEHal

    class EEHal : public IMotor {
    public:
    typedef std::shared_ptr<EEHal> Ptr;
    typedef std::shared_ptr<const EEHal> ConstPtr;
    EEHal( ROSEE::EEInterface::Ptr ee_interface );
    virtual ~EEHal();
    virtual bool sense() = 0;
    virtual bool move() = 0;
    protected:
    virtual bool setJointPosition( std::string joint_name, double joint_position);
    virtual bool setJointVelocity( std::string joint_name, double joint_velocity);
    virtual bool setJointEffort( std::string joint_name, double joint_effort);
    virtual bool getJointPosition( std::string joint_name, double& joint_position);
    virtual bool getJointVelocity( std::string joint_name, double& joint_velocity);
    virtual bool getJointEffort( std::string joint_name, double& joint_effort);
    ROSEE::EEInterface::Ptr _ee_inteface;
    private:
    std::map<std::string, double> _joint_postion;
    std::map<std::string, double> _joint_velocity;
    std::map<std::string, double> _joint_effort;
    };

    We need to add _motor_position, vel, eff attributes?
    The setJointPosition must be deleted, so derived class must implement them (as it is now with setMotors***); same for get?
    Or we keep them and reimplement if neccesary (but in this case, we must put them public...)

@torydebra
Copy link
Member Author

I take the chance of this issue for another doubt I have:

I am implementing a get motorcurrent. We need another fill_publish_*** ? we need one for each type of sensors? Should not be better to publish to ros topic these information from hal structures? So, if the concrete hal has the sensor, it will publish something. Now instead universal rosee executor must do fill publish for each sensor and check if this sensor is present...
I am a bit confused maybe :D

@torydebra
Copy link
Member Author

For example, fill publish joint states sends commands to joint. But when real hand is used, the command are given with setPosReference, so what is the purpose of this function in this case?

@torydebra
Copy link
Member Author

Closing here, we will solve this problem with hal2 #57

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants