Skip to content

[UFE] Burt Configurations

Craig McDonald requested to merge feature/configurations-ufe into devel-ufe

Description

We've had discussions about how best to organize configuration data and their default values. This merge request mostly deals with my attempts to make things a little more organized.

I created the IConfig interface for Burt subsystem configurations that we want to be able to serialize, read/write to file, and read/write from robot EEPROM when applicable. I also re-organized the BurtConfiguration class.

Then I created a ConfigurationFileTest in BurtSharp.Sandbox to test file read/write, robot get/put, json serialize/deserialize, as well as loading defaults from BurtConfiguration.

I modified the FrictionCalibration program to be geared toward user force estimation, since it is no longer used for Burt medical systems. We use the output of the friction calibration, which is a FrictionCompConfig, to augment the DriveDynamicsConfig used in Dynamics.cs (see DriveDynamicsConfig.AddFriction(FrictionCompConfig configLeft, FrictionCompConfig configRight)).

I added to the DisturbanceObserverTest in BurtSharp.Sandbox the option to "Load configs from file", which sort of brings this all together. The FromFile() function loads forward kinematics, dynamics, and friction configuration files from /opt/barrett/config so that we can have all the kinematics and dynamics parameters used by the user force estimation algorithm in one place where they are easy to edit.

[Note: This issue was resolved. (see discussion below)] There is a conflict between Mathnet.Numerics Matrix type and our JSON serialization library, I cannot easily use the forward kinematics config defined by the mainboard as an IConfig. As a temporary solution, there are currently two types of ForwardKinematicsConfig: one in the BurtSharp.Control namespace, defined in BurtSharp/Control/ForwardKinematics.cs, and one in the BurtSharp.CoAP.MsgTypes namespace, defined in BurtSharp/CoAP/MsgTypes.cs. I tried to make this as painless as possible by preferring the Control.ForwardKinematicsConfig everywhere in BurtSharp, and then converting between the two when communicating with the robot over CoAP.

Other miscellaneous changes:

  • Added many comments throughout for undocumented public properties, functions, classes, etc.
  • Added IDataLogger interface to DataLogger so we can have multiple data loggers storing different records in one List
  • Removed the dependency on UnityEngine in a few places, since my goal is to remove it entirely.

What to focus on

  • The organization of BurtConfiguration.cs. Does it make sense?
  • Does the use of IConfig and the ConfigurationFileTest.cs adequately address some of our organizational issues? Could it be better?
  • The DisturbanceObserver should now be configurable, and that should be tested with DisturbanceObserverTest
Edited by Craig McDonald

Merge request reports