gt-rail / assistance_arbitration Goto Github PK

The suggestions are a supplement to the code running with the monitors and arbitrator. We should incorporate them into this current set of packages and classes.

Just some quick notes on:

• Motivation
  • When running a task through smach, there needs to be a separate watcher thread that monitors the execution and cancels if a preempt is requested. This is perhaps a better way of achieving that without the pains of multithreading
  • This method should allow for easy dynamic linking of actions
• Prerequisites
  • psutil
  • pydub
  • hlpr_speech
• The commands to run the executor
• What actions are and how a task plan, and its components, can be specified.

Need a belief node that keeps track of RobotState beyond just the breakers. I don't know what should go into this belief state yet though.

Background action with enable/disable toggles to look at a chosen person. If no chosen person provided, then at "a" closest person.

Currently assistance_msgs is bloated by its need to store message definitions dependent on external packages for the database and beliefs (though not so much anymore for the latter). Update the mechanism of message usage for both those in order to make this repository standalone

The method of handling the context dictionaries has gotten out-of-hand. We should consistently use the msg_utils functions and the constants in assistance_msgs when dealing with the context dictionary so that there is more control and a better API for handling the information in those crucial dictionaries

Now that fetch_grasp_suggestion is released at https://github.com/fetchrobotics/fetch_grasp_suggestion, point to that instead.

Some of the common topic, action, and service constants for this system should be put into the set of constants defined in assistance_msgs.constants

Perhaps try to ape the behaviour in the tilt_head.py in fetch_navigation.

Specifically, create capabilities to help with debugging the cause of the error:

• Most likely cause of error
• What else might've failed
• Explanation based on beliefs of what's going on right now
• Ask for safety checks from the human before performing any movement

We need a common way to handle background tasks and actions that can be enabled or disabled. Some considerations for these:

1. Specification
   • All tasks have an enabled boolean flag
   • ???
2. Mutex conditions for different background and foreground tasks running at the same time.
3. What should happen if a background task errors out?

Integrate the recovery strategies used for FetchIt as a baseline recovery strategy package into the arbitration system

The monitors crash if they cannot get a reference to isolation. Change this using pkgutil; otherwise everyone will need to checkout codebase, and we can't have that

Turning compliant mode on does not seem to turn gravity comp back on for the arm.

Need a CLI action runner so that we can debug individual actions if they fail. Also, easier to reset the robot that way

Just like loop and choice, op should allow for arbitrary code execution rather than rely on predefined functions

• Navigation code right now gets stuck on the carpet.
• The robot is a bit "finicky" when it comes to moving near or away from the table
• Rotating away from the table with the arm in stow still causes problems - update stow.

Use rospy.wait_for_message in the following actions:

• joystick_trigger
• find_closest_person
• torso_linear
• look_pan_tilt
• torso

Based on improvements to the dialogue management, the local recovery strategy needs to implement some autonomous behaviours. Potential ideas:

• Follow Me
• Look here
• Open Gripper
• Close Gripper
• Move gripper here

Related: Ask for safety checks from the human before moving

(Especially important because re-enabling the gripper breaker automatically opens the gripper back up)

In preparation for perhaps needing to use a different robot, move task_executor.actions to fetch_actions

Update the EmotionML markup on speech to SSML. As part of that process, we need to figure out how to emulate the different EmotionML affect classes in SSML.

default_actions should be reinstantiated for every import so that classes don't all potentially overwrite each other.

Constants used in the recovery servers such as RemoteRecoveryServer and PredefinedRecoveryServer should be input from the external packages that are imported through rosparams. This allows for greater flexibility in the naming of topics, services, params, etc.

Background action with an enable/disable toggle to look at the gripper

Sometimes we just need the pure python bindings, and it would make the default fetch_tasks package much more lightweight when we run it

All the resume hints are erroring out. Likely because of me trying to be clever. Remove the cleverness

I need unit tests and integration tests so that I don't accidentally break old functionality.

Make sure to include a travis build when the tests are complete

Is this because of asynchronous actions? Or is it perhaps the Temporary File usage?

Also, is there a way to increase the volume?

The ROS graph that is currently generated has too many connections and is in many ways very hard to parse. Need to make it more useful (should the need arise)

Need a tool to keep track of the different workspaces and quickly set them up. wstool might have been nice, except it can't deal with a structure like codebase.

Possible options: https://answers.ros.org/question/193385/managing-projects-using-catkin-and-wstool/

Also, as part of this, include a requirements.txt:

• psutil
• pydub
• requirements for fetch_grasp_suggestion, hlpr_speech, etc.

Create a time limit.

Create a system of non-blocking waits for services and actions so that not everything has to be initialized for the smallest of tests.

The database lookups in arm, move, look, etc. should instead happen when the task/action params are being parsed. That way, there will be a consistent referencing scheme for all database objects.

Create and clear the octomap and costmap with better look behaviour.

Costmap:

• If there is a collision with the robot, scan the collision area again to clear the costmap

Octomap:

• Ensure that the region all around the arm's workspace is free before planning

With the velodyne, all of this might be moot anyway

Update the kps.dic and kps.yaml in hlpr_speech so that we can perform speech recognition using the microphone as well

Create an idle behaviours task or action. Basically pull out the idle code from the dialogue manager and put it into an action or task that can be enabled or disabled.