Currently we only have 2 bins (1 picking bin & 1 placing bin)

Need to add the third one on the left of the picking bin to implement ITER.

How are the bins loaded?

1. In picking.py we need to import BinsArena from robosuite.models.arena
2. In Arena: bins_arena.xml we have table_full_size (3-tuple): x, y, z of the table, table_friction (3-tuple): 3 mujoco friction, bin1_pos (3-tuple): Absolute cartesian coordinates
3. In picking.py __init__ we can initialise bin1_pos = (0.1, -0.25, 0.8), self.bin1_pos = np.array(bin1_pos)
4. In picking.py get_placement_initializer we have reference_pos = self.bin1_pos for pickObject

In picking.py,
When the self.object_randomization flag is set to True, _reset_internal() also activate the self.hard_reset flag on.

The flag is used in environments/base.py:reset().
When self.hard_reset is on, the following code is called starting on L311:

        if self.hard_reset and not self.deterministic_reset: #TODO: investigate increasing memory consumption when calling this every rollout
            self._destroy_viewer()
            self._load_model()              #  Create a manipulation task objec (arena/robot/object/placement of objects/goal objects)
            self._postprocess_model()
            self._initialize_sim()

When this is called at the end of every rollout, our memory usage increases significantly over the lifetime of the experiment, always resulting in an out of RAM segfault.

If we only randomize every 200 epochs we see this stabilizes, but we have not figured out the underlying cause.

These objects are buried down in the table.

1. o0027 plate
   Bottom part of the plate got buried.

2. o0035 padlock
   Circular part of the lock (lock head) got buried.

3. o0054 dice
   Dice almost got completely buried.

Need to look deeper at z_offset in _get_placement_initializer function in picking.py

Checking for Objects that fall

1. We need to develop a logic such that:
2. Detect if the object falls (i.e. if its height is less than the bin height)
3. If so, remove the object from lists where we track objects. like the sorted_object_list

objects appear constantly in the bottom-right section of bin1.
please help me check.

In branch picking_environment_new_reset we introduced a new reset formulation where we do soft resets after 1 object is picked up and hard resets when all objects or ill conditions appear.

Objects may fall in two situations:

1. #model==#load
   In cases, where the number of objects loaded is equal to the number of objects modeled, objects fall only from bin2, when a new object is placed unto bin2. This does not occur because that new object falls on top of the previous model, it must be related to the way the position of the objects is maintained across resets.

2. #model<#load
   In cases, where the number of modeled objects is less than the loaded number of objects, the objects tend to fall down while doing a regular pick in bin1.

There must be some problem in the way the position of an object is updated when it is the list of "self.not_yet_considered_objects"... Need to dig in here.

Integrate baxter as a single arm robot

1. Modify Baxter properties in robosuite/models/robots/baxter_robot.py to fit a single arm robot properties
2. Need to find other locations to enable baxter robot deployment in SingleArmEnv

Issue 2

Currently, when EEF limtis + EVAL are running, and those limits are violated, every rollout in the EVAL gets terminated early on. This continues until the eval number of steps/rollouts is completed.

The same thing happens if an object falls.

• Should we accept this behavior? The behavior should be common early on but improve as the robot learns.
• Should we turn off this limits with a flag (todo)?
• The code does not crash, but you get a null evaluation result.

Moving the Bins

1. we can move the bins closer to the robot.
2. if we move the bins will any calculations fail?
3. we could use a new branch for this check... this is important because if the objects falls to the floor we will never be able to pick it up

Pull commit 3080530..9a6b193 (minor clearing of comments)
Bug:

1. object loaded and modelled with self.object_randomization=False (using same objects after reset).
2. objects falls
3. during the next Picking._reset_internal() cannot generate a new goal as this object has been removed from self.object_names (or possibly not_yet_considered_object_names).

Brainstorming:

• This bug probably is not dependent on whether we are doing object_randomization or not, simply that if we only have 1 object, and remove it, we return an empty goal...