Change DifferentialWheeled interitance to virtual

[dmiklic]

In order to enable multiple inheritance for differental wheeled robots.

[stephanemagnenat]

I have two points related to this change:

• This is likely to break ABI, I do not have time to test right now, but naively I would say it does so. A detailed explanation is available here: http://syrcose.ispras.ru/2009/files/02%5Fpaper.pdf
• In which context do you need that change?

[dmiklic]

We are trying to extend Enki's world model with additional physical properties, such as heat:

https://github.com/larics/assisi-playground/tree/heat-integration

We did this by subclassing Enki::World and Enki::Robot. Now, in order to have a differential drive robot that can also interact with the heat model (e.g. have a temperature sensor or actuator), we need to subclass both DifferentialWheeled and ExtendedRobot objects. To do this in a clean way, we need the abovementioned change.

To what extent is ABI breakage a concern?

[stephanemagnenat]

I see and understand why you need the virtual.

ABI breakage is not a problem, we should just remember to update the LIB_MAJOR define in CMakeLists.txt when we do a release. Actually I should do proper release instead of having an ongoing git tree never released. I always hope I can do a nice cleanup but I never find the time. Now there is a person doing RPM packages, and this person proposes to use shared libraries, as it is normally done in packaged libraries. I agree with that change, but this implies that I am a bit more serious with tracking ABI changes. I will talk to the RPM packager and come back to you on that.

[dmiklic]

Ok, thanks. Let me know what the verdict is :)

[dmiklic]

Hey Stephane, any news on the status of this.

We would also need the World::step function to become virtual, for the same reasons. Can I add this to the pull request too?

[stephanemagnenat]

Yes, please update the pull request, I will merge it afterwards.

[dmiklic]

Done, thanks!

[stephanemagnenat]

While reading your extensions in assisi-playground, I am thinking whether there would be a better way to structure the way the world interacts with objects. There could be a concept of WorldInteraction, with the Physics being the default one (and the BluetoothBase a second one), so that the world itself is just a container of things. What do you think? Would it help on your side?

[plsm]

I created the class PhysicSimulation in order to simulate other physical quantities or characteristics. The heat model requires a matrix of cells that are updated in each step. If you want to create a WorldInteraction I think that collision detection would be one instance of such class. The world could be a container of things and we add objects to those things: an object could be added to more than one thing because it has a physical mass and generates heat.

Right now all objects interact with everybody else. It is in method objectStep that an object checks if it should interact with the arguments.

[stephanemagnenat]

I agree. About your last point: yes and this should be improved. I have the plan for a long time to use libnabo (https://github.com/ethz-asl/libnabo) to improve that point.

[dmiklic]

To sum up, Stephane, can you merge the pull request so that we can proceed with the integration and testing of the heat model in assisi-playground?

In the long run, I guess we should create a branch of enki in which we would add the WorldInteraction concept and work on that until it is ready to be merged into the master branch?

[stephanemagnenat]

Ok I will merge. It would be great if you could contribute a prototype of the WorldInteraction concept in a branch.

[dmiklic]

Thanks Stephane. We'll work on the WorldInteraction and let you know as soon as we have something useful.