jharwell / rcppsw Goto Github PK

This provides a OOP approach for class initialization that can replace classes
that need an init() method, because for some reason they can't be fully
constructed in the constructor and/or the constructor is long and tedious. Also
suitable for constructors that have a large # of arguments.

This would encapsulate the action that is undertaken after a decomposable task
or one of its children has finished to determine if partitioning should be
employed for the next task.

• In either case, a pointer to the next task to execute should be returned.

Pull in from fordyca. It is reusable, and so should be here.

Frequently when using the loop, where you are using it to drive a robot's linear velocity as it approaches a target, it overshoots the target and begins to oscillate around it because it does not slow down fast enough as it approaches the target. This should not happen.

Would be responsible for managing the execution of a task tree by an entity such
as a robot.

• Only need to create the polled version of this for now, as the
  threaded/asynchronous version should use Intel's tbb.
• Should still have a base executive abstract class
• Should support access of tasks by name
• Creation of tasks should be done elsewhere; only root of task tree should be
  passed to executive's constructor.
• Constructor should take a parameter specifying the maximum allowed task
  partitioning depth.
• Definitely needs to be an er_client.

Interface:

execute() - Runs the currently active task. If that task finishes, it should
get the finished task's parent (a partitionable task), and use it
to figure out what task to execute next.

Internal functions:

get_next_task() - Runs the partitioning algorithm on the parent of a task that
just finished, to determine what task should be executed
next.

Declared, but not defined, so when I try to use it else I get a runtime symbol lookup failure.

Also remove g_null_server.

For use with things that obstensibly require an er_server handle, but which I
don't really care about logging the output from.

Currently prevents any unit tests from compiling...

HFSMs should not be required to specify transition tables for every
external event that occurs (they still should be able to, should they
wish). Instead, they should provide a single function that takes an external
event, derived from fsm::event_data, and sends it to the current state. If
that state cannot handle it, then it will return a signal up to its parent state.

This is a bug because without this functionality you really don't have an HFSM,
but sort of a weird hybrid simple_fsm/HFSM.

Should be sharing_factory--much more self-explanatory.

I would need to not only run it, but clean up the formatting after, as it is not
quite what I prefer.

There is not currently a way to change the parent state of a state once it is
declared, something that is need for bottom-up inheritance (i.e. that in which
derived classes build on top of the functionality provided by base classes).

Meaning mainly abort and partition. Will help a lot with debugging and also evaluating the effectivness of my research approach.

This is used when you want to create a copy of an object at runtime (i.e. a copy
constructor, but explicit).

Right now in every HFSM I have, as well as simple_fsm, the update_state(),
next_state(), etc. functions and member variables are all duplicated. There is
no reason why this couldn't be part of base_fsm and inherited (overridable if
needed).

For large numbers of the same object, the server should allow you to attached to
a single uuid, so that the module list doesn't get littered with 1000s of ids
for different instances of the same object.

The attachment function should search by name, not by uuid, so I couldn't use
the find() function on the list itself--iterator needed.

Issue with non-type template parameters.

What this means is if I have an explore_fsm that I need to change
explore_fsm.ST_explore to two DIFFERENT states for two different classes that
each contain an explore_fsm instance, then because a global variable/table is
used to track this, whichever object updates the parent of a state in the table
last is the winner.

This should be changed so it works as expected.

Previously, due to event_data being typedefed to no_event_data, there was no
compiler warning if there was a mismatch between the declaration of a
state/state_entry/etc., and its implementation. OR, if a class inherited a state
from another class, but declared it with a mismatched declaration. This should
be fixed so that errors result if things do not match.

This will greatly reduce the includes that need to be compiled in fordyca,
and probably other projects as well.

Right now you have no way of knowing if the last state you were in is the same
as the current state you are in, which I need for debugging purposes, to turn
down the verbosity of logging. This is distinct from previous_state(), which is
the previous state you were in, (i.e. that "last" state that was different than
the one you are currently in).

Should help me with trying to quickly grasp what functions have been overriden
in a derived class.

Hopefully if I switch to forward decls it will save compilation time...

Now that I'm starting to use my simple task executive, it is segfaulting
horribly and just not working. Need to do some basic debugging so that it at
least does not crash.

This class would be capable of being decomposed into subtasks (i.e. it would be
a node in some sort of tree). Each subtask would be another decomposable task,
or NULL/some sentinel value if the task was considered atomic (not
decomposable).

It should have:

• Tracking for estimating its execution time, as well as that of its children.
• A name.

Right now if the calling object is polymorphic you get a bunch of cryptic
compiler errors.

Also, if possible visitable classes should be able to specific a specific set of
classes that they will accept visitors from, rather than any class.

As in, "has the task started yet".

Will pull as much as I can from fordyca (everything that is not ARGoS-specific). Things to include:

• task abort probability calculator
• task time estimate tracker
• task partition probability
• pheromone density

• Pull mainly from FORDYCA, and then create my own 2D coordinate class inspired by
  argos::CVector2.

It seems like a classic initialization/first time doing something error.

I.e. if a type has already been registered, it should NOT be an error to register it again.

Specifically, the ability to have a 2D grid of pointers to objects, or a 2D grid
of objects.

Does not advance state properly.

Should really be event_data rather than just event--way more readable.

At the top, logical tasks. Each logical task corresponds to a task sequence of
other logical tasks that execute it. Each has a unique name.

• Atomic tasks are not decomposable, and have an associated FSM. The task sequence
  to execute atomic tasks is the task itself.

• Decomposable tasks do not have an FSM. They return an ordered list of the
  tasks that must be accomplished in order to execute them. They take 2 template
  arguments: the 2 subtasks that the task can be decomposed into.