Think of an approach to avoid passing hard-coded values for discrete haptic commands

[kouroshD]

At the moment, in the hapticGlove code, we have defined a hard coded values in an enum class for the thumper commands to activate or deactivate the palm haptic feedback to the user. Those are added in

walking-teleoperation/modules/HapticGlove_module/include/GloveWearable.hpp

Lines 38 to 71 in 8d336ef

	enum class HapticGlove::SenseGlove::ThumperCmd : unsigned int
	{
	None = 126,
	/// <summary> Turn off the thumper effects. </summary>
	TurnOff = 124,
	/// <summary> A 5-second long, constant vibration. </summary>
	Cue_Game_Over = 118,
	/// <summary> A double-click at 100% intensity. </summary>
	Button_Double_100 = 10,
	/// <summary> A double click at 60% intensity. </summary>
	Button_Double_60 = 11,
	/// <summary> Simulates an impact of the hand at 100% intensity. </summary>
	Impact_Thump_100 = 1,
	/// <summary> Simulates an impact of the hand at 30% intensity. </summary>
	Impact_Thump_30 = 3,
	/// <summary> Simulates an sharp impact of the hand at 40% intensity.
	/// </summary>
	Impact_Thump_10 = 6,
	/// <summary> A light vibration to cue the user that an object it picked up.
	/// 100% intensity. </summary>
	Object_Grasp_100 = 7,
	/// <summary> A light vibration to cue the user that an object it picked up.
	/// 60% intensity. </summary>
	Object_Grasp_60 = 8,
	/// <summary> A light vibration to cue the user that an object it picked up.
	/// 30% intensity. </summary>
	Object_Grasp_30 = 9
	};

similarly to https://github.com/robotology/wearables/blob/ff6bd84a98f3fc01dc44e09af24475c2c72ce1ae/devices/HapticGlove/include/SenseGloveHelper.hpp#L38-L70 .

The values do not have substantially any continuity rule, i.e., the value of a number does not show the amplitude or the frequency of the vibrotactile feedback to the user. On the other side, the wearable interface is limited in the sense that we can only set to haptic feedback name a value to be sent to the wearable device.

The point raised in a PR comment in #72 (comment) .

This issue is mean to rethink if we can come out with some ideas possibly avoiding such hard-coded enum class specific to a wearable device.
cc @S-Dafarra

[S-Dafarra]

FYI @EhsanRanjbari