Giter Club home page Giter Club logo

robot_interfaces's People

Contributors

ilinojkovic avatar luator avatar maximiliennaveau avatar shrutij01 avatar theinfamouswayne avatar vincentberenz avatar waleedgondal avatar wumanu avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

robot_interfaces's Issues

RobotBackend should be cleaned up

the loop of the RobotBackend could potentially be simplified a bit, experience shows that the logic now is a little error prone.

for instance, i think there is a slight problem in this part:

            if (std::isfinite(
                    robot_driver_.get_max_inter_action_duration_s()) &&
                robot_data_->desired_action->newest_timeindex() < t)
            {
                uint32_t action_repetitions =
                    robot_data_->status->newest_element().action_repetitions;

                if (action_repetitions < max_action_repetitions_)
                {
                    robot_data_->desired_action->append(
                        robot_data_->desired_action->newest_element());
                    status.action_repetitions = action_repetitions + 1;
                }
            }

There is a (small) chance that we check the if-clause and realize that action t has not been appended yet, so we enter the loop, but before we append the repeated action, the user in fact appends another action.

while this problem is most likely practically irrelevant, it hints at some logical issues. not sure what's the best solution, maybe the timeseries should have a lock function?

robot back end thread never join

There seems to be no stop function. When the destructor is called, the thread never join and hang forever.

The following is written in the terminal:
"Action did not start on time, shutting down. Any further actions will be ignored'

Tracking a little bit what is happening, looks like destructor_was_called_ is set to true, but the thread remain stuck somewhere in the loop

for (long int t = 0; !destructor_was_called_; t++)

The places it gets stuck varies on the state it was in when the destructor is called. It seems functions there are waiting for something from the front end ? But typically the front end also stops activity on exit

SensorBackend should use non-real-time thread

To my understanding, the cameras will anyway not work in real time, so there is probably no use of running the SensorBackend in a real-time thread. On the other hand, it is probably beneficial to keep the number of real-time threads low, so it would be better to use a standard non-real-time thread here.

thread_->create_realtime_thread(&SensorBackend::loop, this);

backend does not accept infinite time wait anymore

when running :

    // max time allowed for the robot to apply an action.
    double max_action_duration_s = std::numeric_limits<double>::infinity();

    // max time allowed for 2 successive actions
    double max_inter_action_duration_s = std::numeric_limits<double>::infinity();

    std::shared_ptr<Driver> driver_ptr = std::make_shared<Driver>(0, 1000);
    std::shared_ptr<Data> data_ptr = std::make_shared<Data>();

    Backend backend(driver_ptr,
		    data_ptr,
		    max_action_duration_s,
		    max_inter_action_duration_s);
    backend.initialize();
    
    Frontend frontend(data_ptr);
    
    Action action;

    action.values[0] = 0;
    action.values[1] = 0;
    frontend.append_desired_action(action);

    usleep(2e6);

this happens:

Error: Next action was not provided in time
Robot is shut down.

which should not happen because

   // max time allowed for the robot to apply an action.
    double max_action_duration_s = std::numeric_limits<double>::infinity();

    // max time allowed for 2 successive actions
    double max_inter_action_duration_s = std::numeric_limits<double>::infinity();

Note that this was working fine until recently.

You may reproduce the issue by running this demo:

demo on maintainer/infinite_wait_broken branch

first action before reading first observation ?

while (!destructor_was_called_ &&

I find it counter intuitive that the system waits for a first action before starting, as possibly the first action may depend on the robot state/observation.

My program was hanging forever and it took me a while to find that this was because I start my loop with:

robot_interfaces::TimeIndex time_index = ri_frontend_.get_current_timeindex();

which hanged forever as no first action had been sent yet.

RobotBackend: Shut down if new action is not available and number of repetitions is exceeded

In case the user does not append new actions fast enough and action repetition is disabled (or the allowed number of repetitions is already exceeded), the backend will currently just go on and wait for the next action to come.
If no actions are appended anymore, the timing monitor will eventually be triggered and shut down.

However when the user is just adding actions a bit too late (but still within the time margin allowed by the timing monitor), this would result in the backend loop being delayed without any immediate fault that would be noticeable by the user. The delays, however, would result in the observations provided to the user at a non-deterministic rate and the assumption that one timestep corresponds to a constant duration would not hold.

To prevent this, the backend should not just ignore the case of missing new action but directly handle this and shut down (if a tolerance is needed by the user, this can be achieved by allowing repetitions).

Note that some "none-realtime" parameter needs to be added for the case of simulation, where waiting is okay. In this case, it should stick to the current behaviour.

Error when compiling the package

When compiling this package on my Ubuntu 18.04 machine using ROS dashing I am getting the error:

--- stderr: robot_interfaces                                                                                                                  
CMake Error at CMakeLists.txt:69 (ament_export_targets):
  Unknown CMake command "ament_export_targets".

Any idea?

\cc @MaximilienNaveau

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.