• render using latest version of octomap in director
• add support and controls to UI e.g. change color modes
• switch remaining uses from octomap_raw_t to drc_map_octree_t
• have the map server renderer use new rendering code, but also be able to access polydata
• Have map server publish color octrees. (Will need to check on ROS/Exotica side)

Issue: Drawing only a portion of the height of the octree is not available through the Octomap rendering code. (e.g. to remove the ceiling of an octree). It was available previously with the gtk version

MAP_DEPTH - heightmaps, depthmaps
MAP_OCTREE - octree + transform map_octree_t
MAP_CLOUD - point cloud

POINTS_COLLECTION
OBJECT_COLLECTION

OCTOMAP*** - octree + transform octomap_raw_t

General publishing of point clouds to UI doesn't exist
MAP_OCTREE and OCTOMAP render different things

• different messages

As discussed with @gizatt , we will re work this to be a set of vectors of properties
rather than a vector of sets of properties - as we previously used to do.
(This fits with current tools and ROS conventions)

I'll work on this.

choose either whole body control, left arm, right arm or both

Previously Pat and us folks in Edinburgh discussed moving back to private development.

I have just set oh-distro to be read only. Please move your pull requests and branches to:
https://github.com/openhumanoids/oh-distro-private

The working assumption is to push master of private to public occasionally.

Could not build the controls directory without SNOPT.

I downloaded Gurobi outside of the OH build process, but there were no instructions on how to link the compiler to my external Gurobi installation.

Could not run build Director without the Controls directory and some Atlas drivers.

Spoke to Russ about setting up OpenHumanoids with a precompiled binary for SNOPT.

@gizatt : I've summarised the messaging we are looking to put in place here:
https://github.com/openhumanoids/oh-distro/wiki/State-Estimation-Messaging

I'll try to run your translator while manually moving the robot on the winch to get a log to patch all this up.

This is also related ( @raluca-scona ):
https://github.com/openhumanoids/main-distro/issues/2285

@rdeits has been pulling the InstQP into drake and making it C++. Is there a future for the 'control' directory? A lot of its is stale matlab and quite a bit of it hasn't been touched since the Trials.

We had talked about this briefly at the DRC. @rdeits : Is it possible to simple ditch it going forward?

For example @MarcoCar has started (in his branch) a separate directory for motion planning (using Drake) which never had a specific home.

I am trying to build OH without access to the atlas_drivers external (but have access to SNOPT and built gurobi on its own) and am getting the following errors:

[ 14%] Building CXX object src/CMakeFiles/AtlasFallDetector.dir/AtlasFallDetector.cpp.o
In file included from /home/rc/oh-distro/software/control/src/AtlasFallDetector.cpp:1:0:
/home/rc/oh-distro/software/control/src/AtlasFallDetector.hpp:12:39: fatal error: lcmtypes/atlas/status_t.hpp: No such file or directory
#include "lcmtypes/atlas/status_t.hpp"
^
compilation terminated.
make[4]: *** [src/CMakeFiles/AtlasFallDetector.dir/AtlasFallDetector.cpp.o] Error 1
make[3]: *** [src/CMakeFiles/AtlasFallDetector.dir/all] Error 2
make[2]: *** [all] Error 2
make[1]: *** [all] Error 2
make: *** [all] Error 2

I tried cd'ing into drc_lcmtypes, doing a make clean, then make again in /software. That didn't work.

The idea is to have the public (i.e. non OH organisation members) be able to build oh-distro without access to private externals, with no guarantee of functionality though.

The steps hereto are:

• disable matlab-dependent parts when matlab is not present (#37)
• disable atlas-collection by default (follow-up/last step in #30)
• resolve flycapture, e.g. either move to atlas-collection or disable by default in drivers/tobuild.txt
• skip ptgrey if flycapture is not found, e.g. using cmake if-not-found-return or also move to atlas-collection/flycapture

Any thoughts on the last two points @patmarion, @mauricefallon ?

Two tests have been broken after switching to Valkyrie as the default robot:

testTelopPanel.py
http://kobol.csail.mit.edu/cd/testDetails.php?test=3491786&build=19960

testContinuousWalking.py
http://kobol.csail.mit.edu/cd/testDetails.php?test=3491780&build=19960

Either we should add args to these tests so that they use Atlas v5, or we should update the tests to correctly use the Valkyrie model. Even better, adapt the tests so they pass with Atlas or Valkyrie, then run the tests in both modes!

These two modules should be removed:
oh-distro/software/pronto/pronto-utils/src/pronto_joint_tools
oh-distro/software/utils/drc_utils/src/joint_utils
... basically just a header with the joint names.

They are used in a few places but aren't needed. They exist from when ATLAS_STATE (now CORE_ROBOT_STATE) didn't have joint names in it.

After updating to drake master:

>> addpath_control;
>> BasePlanner.withValkyrie(2);
Error using Valkyrie
Abstract classes cannot be instantiated.  Class 'Valkyrie' inherits abstract methods or properties but does not implement them.  See the list of methods and properties that 'Valkyrie' must implement if you do not intend the class to be
abstract.

Error in DRCPlanner.constructValkyrie (line 38)
      r = Valkyrie([], options);

Error in BasePlanner.withValkyrie (line 8)
      obj = BasePlanner(BasePlanner.constructValkyrie(varargin{:}));

The controller segfaults when transitioning into single foot balancing. The video should explain it but:

• move mass onto one foot, works fine
• remove other foot from control authority, robot falls. InstQP reports a NaN
  This used to work before the recent upgrade of drake in January.

@tkoolen or @rdeits : could you have a look?
I guess the intention is to replace this with a c++ alternative.

We would like to have a magnetometer field within the val_hardware_msgs/valImuSensor message type.

Currently pronto isn't properly working with simulated sensor signals from Val. (Atlas mean while is perfect).

The robot is rotating strangely. Likely this is because SCS uses a different urdf than oh-distro and the IMUs are in different places.

Just letting you know @raluca-scona , no need to look into this now

We did some static tests on Friday with the robot attached to the NASA Gantry:

This is what the head-to-hand calibration looks like:

Note that the lower arm was unpowered and the forearm yaw was aligned by eye and the fingers were not reporting their states. this shows the default finger positions. (the URDF/default finger positions make a 'Vulcan salute'). I think this is very promising.

But running some optimisation (sic) is likely help. An initial target is to achieve repeatable sub 1cm accuracy

During compilation, cloning OpenCV would freeze and quit after 3 attempts. Instead I used the system-installed instructions for OpenCV. When compiling, I got the following errors:

"Linking CXX executable ../../bin/occ-map-img-to-pixmap
/usr/bin/ld: warning: libdc1394.so.22, needed by /usr/local/lib/libopencv_highgui.so, not found (try using -rpath or -rpath-link)
/usr/local/lib/libopencv_highgui.so: undefined reference to dc1394_video_set_transmission' /usr/local/lib/libopencv_highgui.so: undefined reference todc1394_feature_set_value'
/usr/local/lib/libopencv_highgui.so: undefined reference to dc1394_video_set_iso_speed' /usr/local/lib/libopencv_highgui.so: undefined reference todc1394_feature_set_absolute_control'
/usr/local/lib/libopencv_highgui.so: undefined reference to dc1394_feature_set_power' /usr/local/lib/libopencv_highgui.so: undefined reference todc1394_feature_get_value'
/usr/local/lib/libopencv_highgui.so: undefined reference to dc1394_get_color_coding_from_video_mode' /usr/local/lib/libopencv_highgui.so: undefined reference todc1394_camera_free'
/usr/local/lib/libopencv_highgui.so: undefined reference to dc1394_convert_frames' /usr/local/lib/libopencv_highgui.so: undefined reference todc1394_camera_free_list'
/usr/local/lib/libopencv_highgui.so: undefined reference to dc1394_capture_is_frame_corrupt' /usr/local/lib/libopencv_highgui.so: undefined reference todc1394_video_set_operation_mode'
/usr/local/lib/libopencv_highgui.so: undefined reference to dc1394_video_get_supported_modes' /usr/local/lib/libopencv_highgui.so: undefined reference todc1394_debayer_frames'
/usr/local/lib/libopencv_highgui.so: undefined reference to dc1394_set_control_registers' /usr/local/lib/libopencv_highgui.so: undefined reference todc1394_free'
/usr/local/lib/libopencv_highgui.so: undefined reference to dc1394_video_get_mode' /usr/local/lib/libopencv_highgui.so: undefined reference todc1394_camera_new'
/usr/local/lib/libopencv_highgui.so: undefined reference to dc1394_video_get_supported_framerates' /usr/local/lib/libopencv_highgui.so: undefined reference todc1394_feature_get_all'
/usr/local/lib/libopencv_highgui.so: undefined reference to dc1394_get_image_size_from_video_mode' /usr/local/lib/libopencv_highgui.so: undefined reference todc1394_feature_whitebalance_set_value'
/usr/local/lib/libopencv_highgui.so: undefined reference to dc1394_video_set_mode' /usr/local/lib/libopencv_highgui.so: undefined reference todc1394_capture_dequeue'
/usr/local/lib/libopencv_highgui.so: undefined reference to dc1394_deinterlace_stereo' /usr/local/lib/libopencv_highgui.so: undefined reference todc1394_capture_enqueue'
/usr/local/lib/libopencv_highgui.so: undefined reference to dc1394_capture_stop' /usr/local/lib/libopencv_highgui.so: undefined reference todc1394_capture_setup'
/usr/local/lib/libopencv_highgui.so: undefined reference to dc1394_feature_set_mode' /usr/local/lib/libopencv_highgui.so: undefined reference todc1394_get_control_registers'
/usr/local/lib/libopencv_highgui.so: undefined reference to dc1394_capture_get_fileno' /usr/local/lib/libopencv_highgui.so: undefined reference todc1394_video_set_framerate'
/usr/local/lib/libopencv_highgui.so: undefined reference to dc1394_get_color_coding_bit_size' /usr/local/lib/libopencv_highgui.so: undefined reference todc1394_feature_whitebalance_get_value'
/usr/local/lib/libopencv_highgui.so: undefined reference to dc1394_new' /usr/local/lib/libopencv_highgui.so: undefined reference todc1394_camera_enumerate'
collect2: error: ld returned 1 exit status
make[7]: *** [bin/occ-map-img-to-pixmap] Error 1
make[6]: *** [src/map_server/CMakeFiles/occ-map-img-to-pixmap.dir/all] Error 2
make[5]: *** [all] Error 2
make[4]: *** [all] Error 2
make[3]: *** [src/occ-map-stamp/occ-map-build] Error 2
make[2]: *** [CMakeFiles/occ-map.dir/all] Error 2
make[1]: *** [all] Error 2
make: *** [all] Error 2
"

When copy-pasting the dependency list on a fresh install of trusty-desktop, unity-control-center gets damaged (via libcheese-gtk). Initial investigation narrowed it down to freeglut3-dev being the first package that exhibits the issue (i.e. cannot install all dependencies in one go). [This has now shown up on 3+ machines here, and does not show up on the Travis servers, hence it must be a desktop distribution issue]

Running

sudo apt-get install  libglew-dev libcheese7 libcheese-gtk23 libclutter-gst-2.0-0 libcogl15 libclutter-gtk-1.0-0 libclutter-1.0-0  xserver-xorg-input-all

before the dependency list fixes the issue for now. May need further investigation which package actually causes the issue, and which packages in our dependency list are unneeded/can be dropped/need to be upgraded.

I intend to gather up all Atlas specific code into a single place such that:

• software builds without drc_atlas lcm types. There are 30 of these currently.
• software builds without BDI proprietary library
• this will also simplify the dependency tree
• move us a couple of steps closer to full open source (i.e. checkout and build)

The steps:

• Fish out the 30 LCM types into a pod
• Move all dependent code into a single place: state-sync, bdi-footstep-translator.
• Fix some minor dependencies on these types e.g. signal scope and the fall detector
• Gather the dependent code and types with the driver (and disable by default)

Then during Valkyrie development, we will avoid the intermingling of our software and the manufacturer's API and proprietary files.