counterwithreset.cpp File Reference

Basic Counter with a FuturePublisher-based loop. More...

Go to the source code of this file.

Detailed Description

Basic Counter with a FuturePublisher-based loop.

Introduction

This examples cover the most basic way to close a loop in a graph - using a DetectorGraph::FuturePublisher. Unmarked loops are forbidden by the Framework as a Topographical sort is only possible in Directed Acyclic Graphs.

Intuitively, if there were cycles in a graph it would be impossible for the Framework to provide it's dependency guarantee:

For any Detector, all its dependencies will be evaluated before its own evaluation.

To construct closed loops the graph designer must explicitly define, per cycle/loop, which dependency (i.e. Topic) the above restriction will be waived.

Architecture

The example is composed of two Detectors. The first counts EventHappened and the second detects the condition at which the counter should be reset.

CounterWithReset

FuturePublisher vs. Lag<T>

The framework offers two ways of closing loops in a graph, DetectorGraph::FuturePublisher and DetectorGraph::Lag - this example employs the former.

In this graph it is clear that the TopicState used as a graph output is EventCount and that Reset is produced purely for the feedback path. It is also clear to the the designer of ResetDetecor that the published Reset TopicState should be evaluated in the next Evaluation pass and not in the current one. In such cases it is reasonable to put the responsibility for closing the loop on the writer of ResetDetector:

class ResetDetector : public DetectorGraph::Detector
, public DetectorGraph::SubscriberInterface<EventCount>
, public DetectorGraph::FuturePublisher<Reset>
{
public:
    ResetDetector(DetectorGraph::Graph* graph) : DetectorGraph::Detector(graph)
    {
        Subscribe<EventCount>(this);
        SetupFuturePublishing<Reset>(this);
    }

    void Evaluate(const EventCount& aEventCount)
    {
        if (aEventCount.count >= kMaxCount)
        {
            PublishOnFutureEvaluation(Reset());
        }
    }

    static const int kMaxCount = 5;
};

In cases where downstream parts of the graph also subscribe to the TopicState used in the feedback loop, DetectorGraph::Lag should be used instead. For more info on that see other Feedback Loop examples (e.g. Robot Localization)

Graph

The graph instantiated and evaluation code is unaffected. Both

class CounterWithResetGraph : public DetectorGraph::ProcessorContainer
{
public:
    CounterWithResetGraph()
    : mEventCountDetector(&mGraph)
    , mResetDetector(&mGraph)
    , mEventCountTopic(mGraph.ResolveTopic<EventCount>())
    {
    }

    EventCountDetector mEventCountDetector;
    ResetDetector mResetDetector;
    DetectorGraph::Topic<EventCount>* mEventCountTopic;

    virtual void ProcessOutput()
    {
        if (mEventCountTopic->HasNewValue())
        {
            const EventCount& eventCount = mEventCountTopic->GetNewValue();
            cout << "EventCount.count = " << eventCount.count << endl;
        }
    }
};

and

int main()
{
    CounterWithResetGraph counterGraph;
    for (int i = 0; i < 7; ++i)
    {
        counterGraph.ProcessData(EventHappened());
    }

    Test_Count();
    Test_ResetCount();
    Test_ResetDetected();
    Test_NoResetDetected();
    Test_CounterResetIntegration();
}

work in the same way as with simple graphs.

Running the program produces:

DetectorGraph: Graph Initialized
EventCount.count = 1
EventCount.count = 2
EventCount.count = 3
EventCount.count = 4
EventCount.count = 5
EventCount.count = 0
EventCount.count = 1
EventCount.count = 2

One important thing to note in this case is that ProcessOutput is called 8 times even though main only pushes 7 TopicStates into the graph - this is by design and allows all graph outputs to continue to be inspected exactly once per-evaluation. This is the case for all graphs with closed loops.

Definition in file counterwithreset.cpp.