search

roboticslab-uc3m / yarp-devices

A place for YARP devices
https://robots.uc3m.es/yarp-devices/
9 stars 7 forks source link

Review and parse fake CAN devices at the controlboard level #241

Closed PeterBowman closed 4 years ago

PeterBowman commented 4 years ago

Stemming from https://github.com/roboticslab-uc3m/yarp-devices/issues/192, I wanted to strip the FakeJoint device from unnecessary debug console output and make it implement all YARP motor interfaces, quite similar to what CanBusControlboard looks like AToW. Also, the CanBusFake device deserves a small cleanup.

Adding documentation label since I found no trivial placement for new .ini file usage (see next comments), hence this issue will serve as ad-hoc documentation for new device usage.

PeterBowman commented 4 years ago

I want to: replace a TechnosoftIpos device with a FakeJoint device (e.g. missing or broken hardware). What should I do: rename idxx-ipos to idxx-fake (or whatever I want as long as it contains the fake substring). Example: broken CAN id 23.

[devCan leftArmBus]
device "CanBusControlboard"
description "CAN bus wrapper for TEO's left arm"
buses ("pcan-leftArm")
pcan-leftArm ("id21-ipos" "id22-ipos" "id23-fake" "id24-ipos" "id25-ipos" "id26-ipos")

[wrapper leftArmPort]
// ...

I want to: replace a CanBusPeak device with a CanBusFake device (e.g. missing or broken hardware). What should I do: rename pcan-xxx to fake-xxx (or whatever I want as long as it contains the fake substring), replace the list of raw nodes with the number of FakeJoint devices I need to map to instead. Example: broken left arm CAN bus.

[devCan manipulationBus]
device "CanBusControlboard"
description "CAN bus wrapper for TEO's arms"
buses ("fake-leftArm" "pcan-rightArm")
fake-leftArm 6
pcan-rightArm ("id15-ipos" "id16-ipos" "id17-ipos" "id18-ipos" "id19-ipos" "id20-ipos")

[wrapper leftArmPort]
// ...

[wrapper rightArmPort]
// ...
PeterBowman commented 4 years ago

Also, the config.ini file is no longer mandatory on initial launchCanBus configuration as long as you don't pass the --home option. This option needs a configured calibrator device that, in turn, requires an .ini file which has been previously included via config.ini. Therefore, if you add a calibrator property to the YARP wrapper device, launchCanBus will issue a warning and the homing commands will not be available on runtime. Similarly, you'll see a warning whenever config.ini is missing, but this will obviously escalate to an error if a non-fake device is requested. I allowed this behavior so that config.ini can be omitted in a fake-only configuration.

PeterBowman commented 4 years ago

Ready at https://github.com/roboticslab-uc3m/yarp-devices/commit/c0c2522e9d707511328e6adb56762baa4253d2b8. I'll stress this again: there is no need (and won't work anyway) to create a idxx-fake.ini file or similar. The handling of both fake CAN buses (CanBusFake) and fake CAN nodes (FakeJoint) is done at the CanBusControlboard level, i.e. I have hardcoded both device names so that those are instantiated when a fake substring is present in the expected YARP options.