open-dynamic-robot-initiative / robot_interfaces Goto Github PK

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?

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.

I am trying to build robot interfaces and i am unable to full fill this dependency, can someone please help me with this.

Thank you

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.

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

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

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

When I try to build this with robot_interface pkg using catkin build . I get the following error.

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.