Control of End Effector wires / IO incompatible with monitor / Dynamixel servos

[JamesNewton]

At the wiki page: https://github.com/HaddingtonDynamics/Dexter/wiki/End-Effectors#j20--j21-blue-and-green-wires we documented the use of the w 64 value oplet to switch the blue and green wires at the end effector to other functions such as RC servo, PWM out, or generic IO. Address 65 and 66 could then be used to set the PWM duty, frequency, etc...

However, access to the functions at address 64 (and 65, 66) were removed in https://github.com/HaddingtonDynamics/Dexter/commit/42df0e01285ef8b67764ed53f3cc697df44d4d93 when keyholeing was added to reduce the size of the FPGA address space, but that was probably not necessary since these are not keyholed, their address simply changed. Indirection from the old address (64-66) to the new address (31-33) can be supported via the OldMemMapInderection array.

In https://github.com/HaddingtonDynamics/Dexter/commit/42df0e01285ef8b67764ed53f3cc697df44d4d93#diff-691272021fae98368efb598f8e089c16R285 we:

Re-enable IO control and "Gripper" items in 'w' oplet. Specifically addresses 64: END_EFFECTOR_IO, 65: SERVO_SETPOINT_A, 66: SERVO_SETPOINT_B, 73: GRIPPER_MOTOR_CONTROL, 74: GRIPPER_MOTOR_OFF_WIDTH, and 75: GRIPPER_MOTOR_ON_WIDTH should again be accessible via the w oplet.

The complete DexRun.C file with these changes is available here: https://github.com/HaddingtonDynamics/Dexter/blob/StepAngles/Firmware/DexRun.c Note: this is on the StepAngles branch and requires an updated of the FPGA .bit file for compatibility: https://github.com/HaddingtonDynamics/Dexter/tree/StepAngles/Gateware

This re-adding has not been completely tested, and the monitor mode may interfere with address 64 because it wants to get the status of the dynamixel servos and so re-enables them, overwriting whatever setup has been done there. For now, this can be avoid by starting with runMode of zero. E.g. DexRun 1 3 0 in RunDexRun.

TODO: Find a way to avoid query of Dynamixels when address 64 is set for something else.

[JamesNewton]

In https://github.com/HaddingtonDynamics/Dexter/commit/31c1e41f59eb86452bd60402ce426722c248e1ff we add shadow_map array which duplicates the values of the mapped array in standard RAM rather than in the FPGA shared map space. The RegExp search and replace function of VSCode was used to change every occurrence of mapped\[(.*)\] ?=(.*) into mapped[$1]=shadow_map[$1]=$2. e.g. mapped[END_EFFECTOR_IO]=128+64+4; becomes mapped[END_EFFECTOR_IO]=shadow_map[END_EFFECTOR_IO]=128+64+4;

The end result is that we can now read back the last known setting of any mapped address. In https://github.com/HaddingtonDynamics/Dexter/commit/9718c9e49224d4deeaacba39f92bc7cb9f036759 we test that shadow_map[END_EFFECTOR_IO] to see if it's been set for the Dynamixels, and if not, we don't query them for their position in the monitor thread.

This appears to work and should close this issue. Further testing in other IO modes should probably get done at some point.

[kgallspark]

Sounds good. We will test over the next couple of daysOn Oct 2, 2019 4:52 PM, JamesNewton notifications@github.com wrote:Closed #73.

—You are receiving this because you are subscribed to this thread.Reply to this email directly, view it on GitHub, or mute the thread.