Migrate FakeControlboard's JMC to FakeJoint

[PeterBowman]

The FakeJoint device lacks several interface implementations (and, probably, does not interpolate trajectories). On the other hand, FakeControlboard can do that, but only on a controlboard-level manner, i.e. joint control is embedded. The point here is to extract each joint controller from that and make FakeControlboard just load dynamically the number of joints/devices requested by the user.

In the long run, I wonder whether we'll need FakeControlboard at all, since CanBusControlboard may load FakeJoints on request and even make them work together with other node devices, either on a real CAN network or with a simulated one (CanBusFake).

[jgvictores]

Totally agree with dropping FakeControlboard in the future.

[PeterBowman]

Idea: leave FakeControlboard as an empty device-launcher shell, move all logic to FakeJoint, and let it be instantiated by CanBusControlboard (it already is) and FakeControlboard. The point being that CanBusControlboard should focus on CAN communications, therefore there would always be a CAN bus device attached to it. Either we make it optional and rename the controlboard device, or keep these two things separate: a universal device launcher that supports CAN devices with some optional fake joints, and a "fake-CAN" controlboard only composed by fake joints.

[jgvictores]

Whichever solution, I guess we are looking for a balance between:

1. Having fake devices that are useful for debugging
2. Not having to maintain excessive code

That said, if we really have to hack the CanBusFake a lot in order to emulate the CAN behavior for things to work, and see it is not really worth the effort, we should forget about it, just work with FakeControlboard. However, I believe this is not the case. Instead, CanBusFake can be very minimal, so we could actually just forget about FakeControlboard and work with CanBusControlboard+CanBusFake. I'd see no need for renaming CanBusControlboard as it only switches between CanBus options. Exception: think about including devices that are not integrated via CAN.

[PeterBowman]

Idea: leave FakeControlboard just for its use as a multiplexer (#171) of FakeJoints, i.e. assign it the board role (#211).

[PeterBowman]

Note that testBasicCartesianControl.cpp opens a FakeControlboard device.

[PeterBowman]

It is a misconception that FakeControlboard is a control board of FakeJoints, and I probably got it wrong from the very beginning. Indeed, the FakeControlboard is a fully fledged simulation of a joint controller that, at the time of writing, accepts position and velocity commands. The YARP counterpart device named fakeMotionControl follows a similar principle but, unless I'm wrong, it does not interpolate intermediate targets as our device does (through time stepping), i.e. all movements are instantaneous.

On the other hand, the FakeJoint does literally nothing. It is a stub implementation of several motor interfaces with the only aim to return a boolean true so that callers perceive a positive result in usual completion checks (if (!p->positionMove(q)) return false;). In contrast, FakeControlboard has been successfully exploited as a lightweight simulator in testBasicCartesianControl, among other valid usage.

I'll have to reconsider my original point. FakeJoint should not die and its purpose must prevail. When a physical driver/motor fails, we replace its device in the CAN bus configuration with this kind of fake "controller". It must return true and, probably, I have to review its treatment of output values (e.g. how should q be treated in getEncoders(q)?). That's as far as it goes regarding internal state.

Then, FakeControlboard or anything similar to it should be kept available, too. I wonder if YarpOpenraveControlboard is a better fit for this case, although it is certainly sure that an additional, heavy dependency (OpenRAVE) makes this device less attractive for trivial usage (cc @jgvictores).

Perhaps current status-quo is worth to be preserved, code cleanup aside. I'm going to implement all raw motor interfaces in FakeJoint as described earlier (mostly bare function body, return true).

[jgvictores]

By original design goals:

• FakeControlboard : Yes, the goal is to act like a light-weight simulator for use cases such as testing kinematics solvers as stated above.
• FakeJoint: Yes, the goal is to act as a dummy joint within a CanBusControlboard or equivalent.

Regarding YarpOpenraveControlboard replacing FakeControlboard: IMHO, I'd say there are strong enough drawbacks. You'd need to compile openrave-yarp-plugins (most dependencies served: YARP, YCM, CMake, except for OpenRAVE). Regarding OpenRAVE here (just to test a kinematic solver) :

• OpenRAVE is currently tedious to install for the most part, having to compile from source with its own dependencies (such as boost).
• While I'm fond of OpenRAVE and trying to leave openrave-yarp-plugins as stable as possible, simulators evolve a lot, e.g. currently Bullet gaining momentum and includes features only OpenRAVE had until now.

As I write this, I'll describe how my initial conception of this issue was a terrible idea. My idea was in fact CanBusControlboard replacing FakeControlboard, via: 1) We move the light-weight simulation logic to the FakeJoints, and 2) We use a CanBusFake. Drawbacks: 1) This is undesired, we do not want a dead/dummy driver to emulate it as moved (so we'd have to indicate it to act as "blocked" anyway), and 2) All the CanBusFake calls would also populate the screen too much to actually be useful to test kinematic solvers.

As such, yes, it seems reasonable to maintain the FakeControlboard /FakeJoint coexistence. In any case, if I were forced to eliminate FakeControlboard, the YarpOpenraveControlboard via seems so bloated I would rather promote CanBusControlboard+CanBusFake for this task (which may be due to my ignorance on the current state of CanBusControlboard, which you may consider also over-bloated for the use case).

[PeterBowman]

All the CanBusFake calls would also populate the screen too much to actually be useful to test kinematic solvers.

Those calls are meaningless, therefore I think we can disable all console output in CanBusFake and thus avoid this trouble.

As such, yes, it seems reasonable to maintain the FakeControlboard /FakeJoint coexistence. In any case, if I were forced to eliminate FakeControlboard, the YarpOpenraveControlboard via seems so bloated I would rather promote CanBusControlboard+CanBusFake for this task (which may be due to my ignorance on the current state of CanBusControlboard, which you may consider also over-bloated for the use case).

I'm not sure I'm getting this right. Do you want to repurpose the CanBusFake device? Shouldn't that read CanBusControlboard + FakeJoint instead?

Question: should we rename FakeControlboard/FakeJoint so that noone gets confused about their main goal? I'm prone to pick VirtualControlboard for the former so that "fake" always means "no-op" (as in CanBusFake).

For the sake of completeness, I found the fakebot device in YARP's codebase. Somewhat close to our intent, but we won't use it anyway.

[PeterBowman]

Question: should we rename FakeControlboard/FakeJoint so that noone gets confused about their main goal? I'm prone to pick VirtualControlboard for the former so that "fake" always means "no-op" (as in CanBusFake).

ASWJ let's rename FakeControlboard to EmulatedControlboard.

[PeterBowman]

Closing as WONTFIX per the above reasons. Two tasks derive from this:

• rename FakeControlboard and post an announcement
• clean FakeJoint and implement remaining motor interfaces

[PeterBowman]

rename FakeControlboard and post an announcement

Done at daf0bc5, cc @roboticslab-uc3m.