Interval Timer Implementation - Looking for Feedback on Approach

Monty Code
1

Hi everyone,

I am Daniel and I am starting to work on the Interval Timer feature for modeling object behaviors. Before diving into the code, I wanted to share my understanding of the issue and get some feedback to make sure I am on the right track.

After reading the documentation and exploring the codebase, here is my current understanding:

What the interval timer does?

The timer works like a clock that marks the time since the last significant event. Instead of continuous time, it uses discrete “time cells”. Each tick represents an interval, and when a significant event happens, the timer resets to tick 0.

The main purpose is to improve the learning process on dynamic behaviors

How it integrates with the architecture?

The timer maps to the cortical column layers like this:

L1 receives the current tick from the timer (broadcast to all LMs)
L4 receives features from the Sensor Module (already implemented)
L5b stores the current state in the sequence (new, advances when timer resets)
L6a stores spatial location (already implemented)

The timer would be a global component in MontyBase that broadcasts its state to all Learning Modules through the existing step flow.

Main components to implement

  • IntervalTimer class with methods like get_current_tick(), reset(), step(), and set_speed()
  • Modifications to the State class to include tick information
  • Buffer updates to store temporal information with observations
  • Hypothesis expansion from (location, rotation) to (location, rotation, state)
  • Object model changes to associate features with both location and temporal state

Questions I have

What defines a “significant event” that resets the timer? Should it be based on feature changes detected by the SM, state changes detected by the LM, or something else?

How many time cells should the timer have by default? The documentation shows 12 as an example, but is this configurable per experiment?

When the timer reaches the maximum tick without a reset, should it stay at the last tick or do something else?

Proposed aproach

Start with a simple IntervalTimer class with configurable num_time_cells (default 12)
Use logarithmic resolution so short intervals have more precision than long ones (as suggested in the documentation)
Add tick to non_morphological_features in State to minimize changes to the existing structure
Make the timer optional in MontyBase so existing experiments keep working
Broadcast the timer to all LMs including static morphology models, but static LMs will simply ignore the temporal information
Use the existing FeatureChangeFilter pattern as inspiration for detecting significant events

I am open to discussing any of these points. If there are many things to clarify, I am also available for a meeting to talk through the details.

Looking forward to your feedback!

2 Likes
2

Hi @Daniel_Lizarazo welcome to the forum and thank you for looking into this item and volunteering your help!

Your understanding of the problem and proposed implementation is already really good, and most of your open questions are also still open questions for us that we would have to figure out empirically.

Before I go into detailed replies to the points you listed, I just wanted to mention that there is a video on YouTube where we discuss this part specifically, if you haven’t seen it yet: https://youtu.be/01U-ZXEjEsc?si=2w1yE49mFKm51Uwl Also, as this topic is quite on the cutting edge of our theory and research and also our own thinking around some of the details is still evolving, I think it would be great to meet some time to be able to talk about this item in more depth. Especially also since it relates to a lot of other items here Object Behaviors and it is likely tricky to implement and test in isolation. But maybe we can come up with a good plan for that without exploding the scope of what you signed up for :slight_smile:

Now, to some of your points specifically:

re. the Main components to implement list: As I just mentioned, the scope of this item can easily get quite large, so I would try and keep it focused on the interval timer and associated infrastructure for now. Items like Hypothesis space including state, object models including state, and sensor modules detecting changes are all related but listed as separate items. Of course, we are super happy if you want to contribute to those as well, but I’m trying to define a self-contained first step instead of having you solve all the complexities of modeling object behaviors. I’m happy to talk more about your questions around those other items as well, but will leave them out for now. From your bullet list, I would focus on the first 3 items first, simulate significant events, and defer incorporating this info in models or hypotheses for now. One additional item would be to add a way for individual learning modules to adjust the speed of the global timer.

re. How many time cells should the timer have by default?: This is an open question that we would like to determine empirically, so having a parameter for this, as you suggest, would be great.

re. What happens when the timer reaches the end without a significant event: We don’t have a definite answer for this yet. Something we propose is that as time passes, the threshold for detecting a significant event gets lower and lower. For now, I would recommend just implementing a reset of the timer when the end is reached, and we see how far this gets us.

re. modifying the State class: This is a bit of a tricky question that would be great to discuss with you and the team a bit more. Conceptually, the tick information seems quite different from the CMP messages, since it is a global signal that all the LMs receive. But I agree that adding it to the State class seems like the simplest solution for now. I would, however, add it as a new field instead of as part of the non_morphological_features.

I hope this helps! I am happy to talk more about any of those and also to set up a meeting sometime. Just DM me for scheduling if you are interested in that.

Best wishes,

Viviane

2 Likes