---
# System prepended metadata

title: Untitled

---

* [name=Brandon] 0:55:40
  Surface? put down?
  > We focus on manipulating the arm, but not focusing on putting down action.

* [name=George] 0:57:10
  1. Do you enable collision avoidance for current demo?
  2. How much slow down?
  > 1. Enable in desk case; not in book shelf case
  > 2. Computation time depends on how many waypoints are closer to the obstacles. Currently about few seconds slower.
* [name=David] 0:59:56
  Substitute current planner?
  > We only provide an alternative . Our planner focus on shape-specific trajectories. If the shape is not important, OMPL can do well, too. Our planner is also used for better learning.
  
  Collision avoidance with object in the gripper.
  > We'll do it in the near future

* [name=Tomas] 1:03:44
  How do these trajectories calculated? Pre-taught?
  > We only use 2 ME: pull back and L-shaped
  
  What if turning the box 45 degree? The arm configuration may be very different.
  > We can define the tilted model. How to choose the proper model is another issue.
  
  Why small door?
  > We do move robot base so far. We need to use 11 DOF (base + torso + arm) for opening a real big door.
  
  Obstacle avoidance just considering gripper in the beginning, and solve collision IK for arm links.
  > Yes, we solve these two issues separately so far. We are working on the RMP framework which can combine the both collision avoidance request together.
* [name=Dung Vuong] 1:10:44
  What happens if the orientation of the door change when opening a door?
  > We can provide a normal vector of the door.
  
  Cannot heard the second question... Maybe related to generating a trajectory with a tilted door with AME?
  > Need to check, but we think we can do that.

* [name=Mariusz] 1:14:12
  1. Is your planner a generic planner?

  > Not guarantee to find a solution

  2. Need to compare the time for planning. OMPL does not use optimization. STOMP, CHOMP can do much better.
  > Our IK is fast
  
  3. Limitation on joints makes the decoupling fail to find a solution.
  > ...

  5. OMPL use FK when planning because IK is slower.
  > ...
  
  7. An optimal scene for collision avoidance. (only on obstacle) If there are several obstacles, there are many force disturbing the planning.
  > We can escape local minimum because we have a pre-computed table.
  
  6. How to make sure always finding a collision free trajectory?
  > We using a pushing force, so not guarantee find a vaid solution. Need to test more.
 
  7. How to pick or compose the shapes of trajectory.
  > We manually choose and combine the shapes so far, but we can produce a feasible trajectory very fast (in few days)
  
  8. How many joint configurations do you need to learn a motion primitive?
  > We only save the trajectory model not the joint configurations. If the goal pose is well defined, we can perform the task successfully regardless of the target object orientation.

* [name=???] 1:32:42
  The orientations of the 3 segments in C shaped trajectory are the same? That setting is favorable to the decoupled IK, so it can run faster. Need to do some fair comparisons. :warning: 
  > ...


* [name=Bill] 1:36:12
  The decoupled IK may constrain the arm into more human-liked motion.