Todo List

Class AzmqFlatbuffer

the buffer pools may be a premature optimization. Evaluate this.

Member AzmqFlatbuffer::async_send_flatbuffer (std::shared_ptr< flatbuffers::FlatBufferBuilder > fbbP)

make it so FlatBufferBuilders can be used directly without shared_ptr overhead.

Member AzmqFlatbuffer::AzmqFlatbuffer (azmq::socket socket)

consider making default_circular_buffer_size and receive_buffer_type configurable

Member AzmqFlatbuffer::GetUnusedBufferBuilder ()

eliminate the need for this extra allocation, though this may be premature optimization

Member AzmqFlatbuffer::receive_buffer_type

Consider making this a simple std::vector so it is runtime configurable

Member AzmqFlatbuffer::~AzmqFlatbuffer ()

maybe do something useful with the error code from shutting down the socket?

File Eigen.hpp

convert to use template metaprgramming to define simple functions that simplify and automate the necessary conversions

Member getObjectTransformQuaternionTranslationPair (int objectHandle, int relativeToObjectHandle=-1)

TODO(ahundt) handle errors/return codes from simGetObjectPosition

Namespace grl

remove IGNORE_ROTATION or make it a runtime configurable parameter

remove IGNORE_ROTATION or make it a runtime configurable parameter

Member grl.driver.GRL_Driver.run ()

TODO(ahundt) Move to another thread, this may help avoid the slowdown detailed above

Member grl.driver.TeachModeTest.run ()

This section isn't working... debug it to fix the object

Class grl.TeachMode

the method used to simulate teach mode is a little jumpy, needs to be improved.

Class grl.ZMQManager

support sending data back to the controller PC

Class grl::HandEyeCalibrationVrepPlugin

this implementation is a bit hacky, redesign it

separate out grl specific code from general kuka control code

Template on robot driver and create a driver that just reads/writes to/from the simulation, then pass the two templates so the simulation and the real driver can be selected.

Member grl::HandEyeCalibrationVrepPlugin::construct ()

move this into the actual constructor, but need to correctly handle or attach vrep shared libraries for unit tests.

Member grl::HandEyeCalibrationVrepPlugin::estimateHandEyeScrew ()

probably want to run at least part of this in a separate thread.

evaluate if applyEstimate should not be called by this

Member grl::HandEyeCalibrationVrepPlugin::HandEyeCalibrationVrepPlugin (Params params=defaultParams())

allow KukaFRIThreadSeparator parameters to be updated

figure out how to re-enable when .so isn't loaded

Member grl::HandEyeCalibrationVrepPlugin::Params

allow default params

Class grl::InverseKinematicsController

move to own header with no vrep dependencies

figure out how the interface for following the motion will work VFControlller stands for "virtual fixtures" controller

Member grl::InverseKinematicsController::followVFP_

will want to use an addVFFollow member function once it is added in

Member grl::InverseKinematicsController::InverseKinematicsController (size_t num_joints, mtsVFBase::CONTROLLERMODE cm)

this is just done quickly, make it and the constructor be done right

Member grl::InverseKinematicsController::totalRows

maybe parameterize this somehow

Class grl::open_chain_tag

how close is this to a 1d linestring? Or maybe an nd linestring if you even represent dh params this way?

Class grl::PivotCalibrationVrepPlugin

the rotation component may be different between the

Member grl::PivotCalibrationVrepPlugin::construct ()

move this into the actual constructor, but need to correctly handle or attach vrep shared libraries for unit tests.

Member grl::PivotCalibrationVrepPlugin::estimatePivotOffset ()

evaluate if applyEstimate should not be called by this

Member grl::PivotCalibrationVrepPlugin::PivotCalibrationVrepPlugin (Params params=defaultParams())

allow KukaFRIThreadSeparator parameters to be updated

figure out how to re-enable when .so isn't loaded

Member grl::robot::arm::copy (std::string model, OutputIterator it, grl::revolute_joint_velocity_open_chain_state_constraint_tag)

R800 velocity limits aren't correct!

find a better design where this can be expanded for more models of robot in the future, maybe a std::unordered_map?

Member grl::robot::arm::copy (const FRIMonitoringMessage &monitoringMsg, KukaState &state)

fill out missing state update steps

Member grl::robot::arm::encode (LowLevelStepAlgorithmType &step_alg, KUKA::FRI::ClientData &friData, boost::system::error_code &ec)

do nothing if in an unsupported command mode? Or do the same as the next else if step?

should this be different if it is in torque mode?

allow copying of data directly between commandmsg and monitoringMsg

should this be different if it is in torque mode?

allow copying of data directly between commandmsg and monitoringMsg

Member grl::robot::arm::get (const FRIMonitoringMessage &monitoringMsg, const KUKA::FRI::ESafetyState)

consider using another default value, or perhaps boost::optional<Kuka::FRI::ESafetyState>?

Member grl::robot::arm::kuka::detail::copyJointState (T values, OutputIterator it, bool dataAvailable=true)

replace with joint_iterator<tRepeatedDoubleArguments,T>()

Member grl::robot::arm::kuka::detail::get (T &values, bool dataAvailable=true)

handle dataAvaliable = false case

support tRepeatedIntArguments, and perhaps const versions

Class grl::robot::arm::KukaDriver

enable commanding and monitoring to be independently configured for both FRI and JAVA interface.

Member grl::robot::arm::KukaDriver::construct (Params params)

create a function that calls simGetObjectHandle and throws an exception when it fails

figure out how to re-enable when .so isn't loaded

implement reading configuration in both FRI and JAVA mode from JAVA interface

perhaps allow user to control this?

Member grl::robot::arm::KukaDriver::get (OutputIterator output, grl::revolute_joint_angle_open_chain_state_tag)

implement get function

Member grl::robot::arm::KukaDriver::get (OutputIterator output, grl::revolute_joint_torque_open_chain_state_tag)

implement get function

Member grl::robot::arm::KukaDriver::run_one ()

make this handled by template driver implementations/extensions

Member grl::robot::arm::KukaDriver::set (Range &&range, grl::cartesian_wrench_command_tag)

perhaps support some specific more useful data layouts

Member grl::robot::arm::KukaFRIClientDataDriver< LowLevelStepAlgorithmType >::is_active ()

consider expanding to support real error codes

Member grl::robot::arm::KukaFRIClientDataDriver< LowLevelStepAlgorithmType >::update_state (LowLevelStepAlgorithmType &step_alg, std::shared_ptr< KUKA::FRI::ClientData > &friData, boost::system::error_code &receive_ec, std::size_t &receive_bytes_transferred, boost::system::error_code &send_ec, std::size_t &send_bytes_transferred)

is this thread safe?

Class grl::robot::arm::KukaFRIdriver< LowLevelStepAlgorithmType >

support generic read/write

ensure commands stay within machine limits to avoid lockup

reset and resume if lockup occurs whenever possible

in classes that use this driver, make the use of this class templated so that the low level update algorithm can change.

add getter for number of milliseconds between fri updates (1-5) aka sync_period aka send_period aka ms per tick

Member grl::robot::arm::KukaFRIdriver< LowLevelStepAlgorithmType >::construct (Params params)

create a function that calls simGetObjectHandle and throws an exception when it fails

Member grl::robot::arm::KukaFRIdriver< LowLevelStepAlgorithmType >::get (KukaState &state)

should this exist? is it written correctly?

Member grl::robot::arm::KukaFRIdriver< LowLevelStepAlgorithmType >::getMaxVel ()

make this configurable for different specific robots. Currently set for kuka lbr iiwa 14kg R820

Member grl::robot::arm::KukaFRIdriver< LowLevelStepAlgorithmType >::run_one ()

use runtime calculation of NUM_JOINTS instead of constant

probably only need to set this once

construct new low level command object and pass to KukaFRIClientDataDriver this is where we used to setup a new FRI command

should the results of getlatest state even be possible to call without receiving real data? should the library change?

Member grl::robot::arm::KukaFRIdriver< LowLevelStepAlgorithmType >::set (Range &&range, grl::cartesian_wrench_command_tag)

perhaps support some specific more useful data layouts

Class grl::robot::arm::KukaJAVAdriver

make sure mutex is locked when appropriate

Member grl::robot::arm::KukaJAVAdriver::construct (Params params)

create a function that calls simGetObjectHandle and throws an exception when it fails

TODO(ahundt) switch from linux socket to boost::asio::ip::udp::socket, see Kuka.hpp and KukaFRIdriver.hpp for examples, and make use of KukaUDP class.

TODO(ahundt) Consider switching to boost::asio synchronous calls (async has high latency)!

TODO(ahundt) Need to switch back to an appropriate exception rather than exiting so VREP isn't taken down.

TODO(ahundt) switch from linux socket to boost::asio::ip::udp::socket, see Kuka.hpp and KukaFRIdriver.hpp for examples, and make use of KukaUDP class.

Member grl::robot::arm::KukaJAVAdriver::get (KukaState &state)

should this exist? is it written correctly?

Member grl::robot::arm::KukaJAVAdriver::run_one ()

ADD SUPPORT FOR READING ARM STATE OVER JAVA INTERFACE

make this handled by template driver implementations/extensions

is this the best string to pass for the full arm's name?

when new

TODO(ahundt) eventually run this in a separate thread so we can receive packets asap and minimize dropping

Member grl::robot::arm::KukaJAVAdriver::set (Range &&range, grl::cartesian_wrench_command_tag)

perhaps support some specific more useful data layouts

Member grl::robot::arm::KukaJAVAdriver::~KukaJAVAdriver ()

TODO(ahundt) switch to asio, remove destruct call from destructor

Class grl::robot::arm::KukaState

replace with something generic

commandedPosition and commandedPosition_goal are used a bit ambiguously, figure out the difference and clean it up.

Class grl::robot::arm::LinearInterpolation

Generalize this class using C++ techinques "tag dispatching" and "type traits". See boost.geometry access and coorinate_type classes for examples

Member grl::robot::arm::LinearInterpolation::hasCommandData ()

make this accessible via a nonmember function

check if duration remaining should be greater than zero or greater than the last tick size

Member grl::robot::arm::LinearInterpolation::LinearInterpolation ()

verify this doesn't corrupt the state of the system

Member grl::robot::arm::LinearInterpolation::operator() (ArmData &friData, cartesian_wrench_command_tag)

look in FRI_Client_SDK_Cpp.zip to see if position must be set for cartesian wrench. Ref files: LBRWrenchSineOverlayClient.cpp, LBRWrenchSineOverlayClient.h, friLBRCommand.cpp, friLBRCommand.h

Member grl::robot::arm::LinearInterpolation::operator() (ArmData &friData, revolute_joint_angle_open_chain_command_tag)

maybe this should be the revolute_joint_angle_interpolated_open_chain_state_tag()?

correctly pass velocity limits from outside, use "copy" fuction in Kuka.hpp, correctly account for differing robot models. This should be in KukaFRIdriver at the end of this file.

Member grl::robot::arm::LinearInterpolation::operator() (ArmData &friData, revolute_joint_torque_open_chain_command_tag)

look in FRI_Client_SDK_Cpp.zip to see if position must be set for joint torques. Ref files: LBRTorqueSineOverlayClient.cpp, LBRTorqueSineOverlayClient.h, friLBRCommand.cpp, friLBRCommand.h

Class grl::ros::KukaLBRiiwaROSPlugin

Main Loop Update Rate must be supplied to underlying Driver for FRI mode. see KukaLBRiiwaVrepPlugin for reference, particularly kukaDriverP_->set(simulationTimeStep_,time_duration_command_tag());

Main Loop Update Rate must be supplied to underlying Driver for FRI mode. see KukaLBRiiwaVrepPlugin for reference, particularly kukaDriverP_->set(simulationTimeStep_,time_duration_command_tag());

Main Loop Update Rate must be supplied to underlying Driver for FRI mode. see KukaLBRiiwaVrepPlugin for reference, particularly kukaDriverP_->set(simulationTimeStep_,time_duration_command_tag());

Main Loop Update Rate must be supplied to underlying Driver for FRI mode. see KukaLBRiiwaVrepPlugin for reference, particularly kukaDriverP_->set(simulationTimeStep_,time_duration_command_tag());

Main Loop Update Rate must be supplied to underlying Driver for FRI mode. see KukaLBRiiwaVrepPlugin for reference, particularly kukaDriverP_->set(simulationTimeStep_,time_duration_command_tag());

Member grl::ros::KukaLBRiiwaROSPlugin::construct (Params params)

create a function that calls simGetObjectHandle and throws an exception when it fails

properly support passing of io_service

create a function that calls simGetObjectHandle and throws an exception when it fails

properly support passing of io_service

create a function that calls simGetObjectHandle and throws an exception when it fails

properly support passing of io_service

create a function that calls simGetObjectHandle and throws an exception when it fails

properly support passing of io_service

create a function that calls simGetObjectHandle and throws an exception when it fails

properly support passing of io_service

Member grl::ros::KukaLBRiiwaROSPlugin::jt_callback (const trajectory_msgs::JointTrajectoryConstPtr &msg)

: execute the rest of the trajectory

: execute the rest of the trajectory

: execute the rest of the trajectory

: execute the rest of the trajectory

: execute the rest of the trajectory

Member grl::ros::KukaLBRiiwaROSPlugin::jt_pt_callback (const trajectory_msgs::JointTrajectoryPointConstPtr &msg)

: execute the rest of the trajectory

: execute the rest of the trajectory

: execute the rest of the trajectory

: execute the rest of the trajectory

: execute the rest of the trajectory

Member grl::ros::KukaLBRiiwaROSPlugin::run_one ()

setting joint position clears joint force in KukaDriverP_. Is this right or should position and force be configurable simultaeously?

setting joint position clears joint force in KukaDriverP_. Is this right or should position and force be configurable simultaeously?

setting joint position clears joint force in KukaDriverP_. Is this right or should position and force be configurable simultaeously?

setting joint position clears joint force in KukaDriverP_. Is this right or should position and force be configurable simultaeously?

setting joint position clears joint force in KukaDriverP_. Is this right or should position and force be configurable simultaeously?

Member grl::ros::KukaLBRiiwaROSPlugin::simJointPosition

replace all these simJoint elements with simple KukaLBRiiwaROSPlugin::State

replace all these simJoint elements with simple KukaLBRiiwaROSPlugin::State

replace all these simJoint elements with simple KukaLBRiiwaROSPlugin::State

replace all these simJoint elements with simple KukaLBRiiwaROSPlugin::State

replace all these simJoint elements with simple KukaLBRiiwaROSPlugin::State

replace all these simJoint elements with simple KukaLBRiiwaROSPlugin::State

replace all these simJoint elements with simple KukaLBRiiwaROSPlugin::State

replace all these simJoint elements with simple KukaLBRiiwaROSPlugin::State

replace all these simJoint elements with simple KukaLBRiiwaROSPlugin::State

Member grl::vrep::getJacobian (vrep::VrepRobotArmDriver &driver, bool jacobianOnly=false)

get target position, probably relative to base

do we need to use these options?

FIX HACK jacobianSize include orientation component, should be 7x6 instead of 7x3

do we need to use these options?

FIX HACK jacobianSize include orientation component, should be 7x6 instead of 7x3

Class grl::vrep::InverseKinematicsVrepPlugin

verify Robotiiwa is the correct base, and RobotMillTipTarget is the right target, because if the transform doesn't match the one in the jacobian the algorithm will break

Member grl::vrep::InverseKinematicsVrepPlugin::construct (Params params=defaultParams())

TODO(ahundt) accept params for both simulated and measured arms

TODO(ahundt) replace hardcoded joint strings with a vrep tree traversal object that generates an RBDyn MultiBodyGraph

TODO(ahundt) fix hard coded Revolute vs fixed joint https://github.com/ahundt/grl/issues/114

TODO(ahundt) last "joint" RobotMillTip is really fixed...

TODO(ahundt) extract real inertia and center of mass from V-REP with http://www.coppeliarobotics.com/helpFiles/en/regularApi/simGetShapeMassAndInertia.htm

TODO(ahundt) consider the origin of the inertia! https://github.com/jrl-umi3218/Tasks/issues/10#issuecomment-257198604

TODO(ahundt) add real support for links, particularly the respondable aspects, see LBR_iiwa_14_R820_joint1_resp in RoboneSimulation.ttt

verify object lifetimes

read objective rows from vrep

set vrep explicit handling of IK here, plus unset in destructor of this object

Member grl::vrep::InverseKinematicsVrepPlugin::InverseKinematicsVrepPlugin ()

need to call parent constructor:

Member grl::vrep::InverseKinematicsVrepPlugin::jointHandles_

move this item back into VrepRobotArmDriver

Member grl::vrep::InverseKinematicsVrepPlugin::testPose ()

TODO(ahundt) rethink where/when/how to send command for the joint angles. Return to LUA? Set Directly? Distribute via vrep send message command?

Member grl::vrep::InverseKinematicsVrepPlugin::updateKinematics (const bool runOnce=false, const GoalPosE solveForPosition=GoalPosE::realGoalPosition, const AlgToUseE alg=AlgToUseE::multiIterQP, const PostureTaskStrategyE postureStrategy=PostureTaskStrategyE::constant)

TODO(ahundt) change source of current state based on if physical arm is running

TODO(ahundt) move code below here back into separate independent setup and solve functions, move some steps like limits to construct()

TODO(ahundt) rethink where/when/how to send command for the joint angles. Return to LUA? Set Directly? Distribute via vrep send message command?

TODO(ahundt) make solver object a member variable if possible, initialize in constructor

TODO(ahundt) ulimits aren't the same size as jointHandles_, need velocity limits too

TODO(ahundt) hardcoded mill tip joint limits, remove these

TODO(ahundt) replace hardcoded velocity limits with real and useful limits specific to each joint loaded from V-REP or another file.

TODO(ahundt) was this commented correctly?

TODO(ahundt) remove BOOST_VERIFY(), try/catch solver failure, print an error, send a v-rep message, and shut down solver or enter a hand guiding mode

Member grl::vrep::jointToLink (const std::vector< std::string > &jointNames)

TODO(ahundt) joint to link and joint to respondable only works for v-rep provided scene heirarchy names, modify full class so these workarounds aren't needed in other words this assumes everything is named like the following: joint1: LBR_iiwa_14_R820_joint1 link1: LBR_iiwa_14_R820_link1 link1_respondable: LBR_iiwa_14_R820_link1_resp

TODO(ahundt) FIX HACK! Manually adding last link

TODO(ahundt) FIX HACK! Manually adding last link

Member grl::vrep::jointToLinkRespondable (std::vector< std::string > jointNames)

TODO(ahundt) HACK joint to link and joint to respondable only works for v-rep provided scene heirarchy names, modify full class so these workarounds aren't needed.

TODO(ahundt) link 1 isn't respondable because it is anchored to the ground, but should there be an empty string so the indexes are consistent or skip it entirely? (currently skipping)

TODO(ahundt) link 1 isn't respondable because it is anchored to the ground, but should there be an empty string so the indexes are consistent or skip it entirely? (currently skipping)

Class grl::vrep::KukaVrepPlugin

this implementation is a bit hacky, redesign it

separate out grl specific code from general kuka control code

Template on robot driver and create a driver that just reads/writes to/from the simulation, then pass the two templates so the simulation and the real driver can be selected.

Member grl::vrep::KukaVrepPlugin::construct (Params params)

move this into the actual constructor, but need to correctly handle or attach vrep shared libraries for unit tests.

Member grl::vrep::KukaVrepPlugin::KukaVrepPlugin (Params params=defaultParams())

allow KukaFRIThreadSeparator parameters to be updated

read ms_per_tick from the java interface

Member grl::vrep::KukaVrepPlugin::measuredArmParams ()

measuredArmParams are hardcoded, parameterize them

Member grl::vrep::KukaVrepPlugin::run_one ()

re-enable simulation feedback based on actual kuka state

Member grl::vrep::SetRBDynArmFromVrep (const std::vector< std::string > &vrepJointNames, const std::vector< int > &vrepJointHandles, const rbd::MultiBody &simArmMultiBody, rbd::MultiBodyConfig &simArmConfig, std::string debug="")

TODO(ahundt) add torque information

Member grl::vrep::SetVRepArmFromRBDyn (const std::vector< std::string > &vrepJointNames, const std::vector< int > &vrepJointHandles, const rbd::MultiBody &simArmMultiBody, const rbd::MultiBodyConfig &simArmConfig, std::string debug="")

TODO(ahundt) add torque information

Class grl::vrep::UniversalRobotsVrepPlugin

this implementation is a bit hacky, redesign it

separate out grl specific code from general kuka control code

Template on robot driver and create a driver that just reads/writes to/from the simulation, then pass the two templates so the simulation and the real driver can be selected.

Member grl::vrep::UniversalRobotsVrepPlugin::construct (Params params)

move this into the actual constructor, but need to correctly handle or attach vrep shared libraries for unit tests.

Member grl::vrep::UniversalRobotsVrepPlugin::Params

allow default params

Member grl::vrep::UniversalRobotsVrepPlugin::run_one ()

re-enable simulation feedback based on actual UniversalRobots state

Member grl::vrep::UniversalRobotsVrepPlugin::UniversalRobotsVrepPlugin (Params params=defaultParams())

allow UniversalRobotsFRIThreadSeparator parameters to be updated

Class grl::vrep::VrepRobotArmDriver

add support for links, particularly the respondable aspects, see LBR_iiwa_14_R820_joint1_resp in RoboneSimulation.ttt

write generic getters and setters for this object like in KukaFRIalgorithm.hpp and the member functions of KukaFRIdriver, KukaJAVAdriver

Member grl::vrep::VrepRobotArmDriver::construct ()

create a function that calls simGetObjectHandle and throws an exception when it fails

TODO(ahundt) move these functions/member variables into params_ object, take as parameters from lua!

Member grl::vrep::VrepRobotArmDriver::getJointHandles ()

deal with !allHandlesSet()

Member grl::vrep::VrepRobotArmDriver::getLinkHandles ()

deal with !allHandlesSet()

Member grl::vrep::VrepRobotArmDriver::getLinkRespondableHandles ()

deal with !allHandlesSet()

Member grl::vrep::VrepRobotArmDriver::getState (State &state)

handle cyclic joints (see isCyclic below & simGetJointInterval)

TODO(ahundt) is always setting infinity if it is cyclic the right thing to do?

Class grl::VrepInverseKinematicsController

verify Robotiiwa is the correct base, and RobotMillTipTarget is the right target, because if the transform doesn't match the one in the jacobian the algorithm will break

Member grl::VrepInverseKinematicsController::construct (Params params=defaultParams())

set desiredKinematicsStateP name, INITIALIZE ALL MEMBER OBJECTS, & SET NAMES

verify object lifetimes

read objective rows from vrep

objectiveRows seems to currently be a 3 vector, may eventually want a rotation and translation, perhaps with quaternion rotation

set vrep explicit handling of IK here, plus unset in destructor of this object

Member grl::VrepInverseKinematicsController::jointHandles_

move this item back into VrepRobotArmDriver

Member grl::VrepInverseKinematicsController::updateKinematics ()

does this leak memory when called every time around?

set rotation component of current position

set rotation component of desired position

move code below here back under run_one updateKinematics() call

need to provide tick time in double seconds and get from vrep API call

check the return code, if it doesn't have a result, use the VREP version as a fallback and report an error.

: rethink where/when/how to send command for the joint angles. Return to LUA? Set Directly? Distribute via vrep send message command?

Member grl::VrepInverseKinematicsController::VrepInverseKinematicsController (size_t num_joints=7, mtsVFBase::CONTROLLERMODE cm=mtsVFBase::CONTROLLERMODE::JPOS)

need to call parent constructor:

Member KUKA::LBRState::NUM_DOF

replace all instances of this with the getter now provided

Member LUA_SIM_EXT_GRL_IK_GET_TRANSFORM (SLuaCallBack *p)

implement and connect up this function Returns the current transform estimate in a format that vrep understands

implement and connect up this function Returns the current transform estimate in a format that vrep understands

Member LUA_SIM_EXT_HAND_EYE_CALIB_GET_TRANSFORM (SLuaCallBack *p)

implement and connect up this function Returns the current transform estimate in a format that vrep understands

Member LUA_SIM_EXT_KUKA_LBR_IIWA_START (SLuaCallBack *p)

report an error?

report an error?

Member LUA_SIM_EXT_PIVOT_CALIB_GET_TRANSFORM (SLuaCallBack *p)

implement and connect up this function Returns the current transform estimate in a format that vrep understands

Member operator<< (boost::log::formatting_ostream &out, std::vector< T > &v)

move elsewhere, because it will conflict with others' implementations of outputting vectors

move elsewhere, because it will conflict with others' implementations of outputting vectors

move elsewhere, because it will conflict with others' implementations of outputting vectors

move elsewhere, because it will conflict with others' implementations of outputting vectors

move elsewhere, because it will conflict with others' implementations of outputting vectors

move elsewhere, because it will conflict with others' implementations of outputting vectors

move elsewhere, because it will conflict with others' implementations of outputting vectors

move elsewhere, because it will conflict with others' implementations of outputting vectors

move elsewhere, because it will conflict with others' implementations of outputting vectors

Member operator<< (std::ostream &out, std::vector< T > &v)

move elsewhere, because it will conflict with others' implementations of outputting vectors

move back to KukaFRIClientDataTest.cpp

Member operator<< (std::ostream &out, const boost::container::static_vector< T, N > &v)

move somewhere that won't cause conflicts

Member operator<< (std::ostream &out, boost::container::static_vector< T, U > &v)

move elsewhere, because it will conflict with others' implementations of outputting vectors

Member TranslationToDual (const Vector &vT)

use boost::geometry::get?