August and September Update

[miquelramirez]

Several major changes / updates /etc.

• A number of important bugs fixed in hybrid dynamics solver

• Introduced the notion of reward signals into the framework, so we can do planning in the max-benefit setting

• $$IW(k)$$ driver and interface reconciled with NoveltyFactory, this allows to run IW(k) independently again

• Changed the interface of the singleton classes so their unique_ptr's can be managed by each instance of the planner created in the same process

• Added the EmbeddedDriver interface, for either generic or application specific FS planners that are to be used embedded in other systems (i.e. simulators, etc.)

• ODE networks are now decomposed, this should be resulting in much more accurate trajectories when dynamics are highly non-linear

• Fixed several issues in the handling of conditional effects by the "hybrid" front-end

• First pass on modularised build system:

  • Build is now hierachical, I propose to start with a "flat" set of modules core, gecode, soplex, ompl that separate components that depend from third party libraries (other than boost of course) from those which are core interfaces and do not require such dependencies. See scons scripts in modules/xxxx for details. General philosophy similar to that of old lapkt, but now with a better environment and infrastructure.
  • Introduced macros FS_USES_XXXX where XXXX is the identifier of a third-party library, this allows to customise products introduced into factories in compile time and also to use #ifndef FS_USES_XXX #error "XXX not installed" sanity checks in the code.
  • pkgconfig descriptors are generated for each modality of fs, so we have a clear, centralised way to propagate flags conveniently

• Actions with procedural effects are in:

  • New: ProceduralEffect class, minimal implementation
  • Added hooks to the LogicalComponentRegistry for ProceduralEffect creator methods
  • GroundAction::apply is now overridden by ProceduralAction
  • Made sure actions with procedural effects but no declarative effects aren't simplified away
  • Changed the FSTRIPS+ parser so it accepts action symbols starting with @

[miquelramirez]

Yay!

[gfrances]

¡A por ellos!

[gfrances]

@miquelramirez, what would the intended way of avoiding the dependence with e.g. soplex be? When I try to compile with the new build system, I still get the old fatal error: soplex.h: No such file or directory message. This is because src/constraints/soplex/lp.hxx is unconditionally including that file. Perhaps this is related to pkgconfig, which I still have to read about? Question is: do we want to phisically separate the code (our code) that depends on third-party modules on different folders - so that e.g. all code depending on soples goes to a subfolder (perhaps git submodule in the future?) "modules/soplex", etc. ?? That seems like a good approach to me, a bit like that we tried to do with the new LAPKT but never really finished doing? Or perhaps there are better alternatives? What did you have in mind?

Thanks for all the work! I'm slowly going through the different commits...

[miquelramirez]

what would the intended way of avoiding the dependence with e.g. soplex be? When I try to compile with the new build system, I still get the old fatal error: soplex.h: No such file or directory message. This is because src/constraints/soplex/lp.hxx is unconditionally including that file. Perhaps this is related to pkgconfig, which I still have to read about?

You can switch off the libraries now via setting the vars in custom.py or as arguments to scons. build.py does not propagate yet (and I don't see any reason that would prevent it from doing so) these arguments to the quite hidden call to scons.

pkg-config is a system for creating descriptors of libraries, so you can access in a uniform way details such as the right combinations of compiler flags, depedencies etc. Note that I made that every build (production, debug, etc.) now creates its own .pc descriptor too.

Question is: do we want to phisically separate the code (our code) that depends on third-party modules on different folders - so that e.g. all code depending on soples goes to a subfolder (perhaps git submodule in the future?) "modules/soplex", etc. ?? That seems like a good approach to me, a bit like that we tried to do with the new LAPKT but never really finished doing?

Eventually yes, I think so too. In any case, the changes I have been making (defining sub-scripts for scons so we can define the modules ourselves) facilitate moving towards that. What you're seeing here is the first pass on a very boring thing (but necessary if we want to exercise the flexibility of FS).

Thanks for all the work! I'm slowly going through the different commits...

There's a lot to get through, let me know if you find anything "curious" or you notice that I have broken something. As a first stop, I'd recommend to review the build system (including the hybrid-mpc-planner extension to FS, showing how we can fork planners out of FS without compromising privacy) and the IW(k) algorithm (which I brought back to life after a long spell in the underworld).

Last, on the roadmap is to get working the ompl module... right now it is using the old Gecode interfaces to sample goal states. Now that we have settled the design of the representation of object values, it is time to revisit this and get it working again.

[gfrances]

Yup, I was actually trying to compile with: scons use_soplex=no use_ompl=no And the soplex error mentioned above appears the same:

In file included from src/heuristics/l2_norm.hxx:7:0,
                 from .build/prod/src/heuristics/l2_norm.cxx:1:
src/constraints/soplex/lp.hxx:18:20: fatal error: soplex.h: No such file or directory

Hence my question. Should the include be conditional? Actually, there's probably no point in including soplex/lp.hxx, etc., if use_soplex=false, right? All the related includes plus the registration of related handlers / heuristics into some register object should be done conditionally based on the FS_USE_XXX macros, according to the current design... is that right? I can do that, just making sure we're on the same page :-)

[miquelramirez]

Nooo

[miquelramirez]

Sorry @gfrances I was tired and had clumsy fingers... I need to be careful when using Github from the phone.... the "Delete Branch" button was there in the middle of the screen. A gentle swipe and poof! all is gone :sake:

[miquelramirez]

Should the include be conditional?

Yes, it should

Actually, there's probably no point in including soplex/lp.hxx, etc., if use_soplex=false, right?

Nope, but probably we will get compilation errors until...

All the related includes plus the registration of related handlers / heuristics into some register object should be done conditionally based on the FS_USE_XXX macros, according to the current design... is that right?

Exactly : +1

[gfrances]

Sorry @gfrances I was tired and had clumsy fingers... I need to be careful when using Github from the phone.... the "Delete Branch" button was there in the middle of the screen. A gentle swipe and poof! all is gone :sake:

Not really, that's the beauty of distributed VCS, the branch would still be on your computer, and on mine, so you could just push it back to Github ;-)

In any case, then I'll start moving files around and adding conditional includes... to achieve my first goal, which is: to compile the planner without soplex installed :-)... not sure if I'll do this now or next week though, but shouldn't be too complicated.... thanks!

[miquelramirez]

:+1: