AHHHHH!!!

As a lidapy developer, I need the ability to add and manage additional python packages to support new lidapy functionality.

Currently, the only lidapy dependencies are being installed by apt-get because they are part of larger non-python dependencies (e.g., ROS). The best way to manage python specific dependencies seems to be pip.

I propose that we create a requirements.txt file to document our python specific dependencies, and allow them to be installed automatically using pip install -r requirements.txt.

As a first example of this new mechanism, I intend on using it to manage a dependence on the mock package in support of unit testing. (This is available in version of Python3 in the unittest package, but is not available in the core Python2 packages.)

Assuming this works, I will document this in the README.md as an installation step, and update the Travis CI testing script to run pip install -r requirements.txt.

In processes and threads that use message passing, we need to guarantee that those processes and threads operate under the following constraints:

1. Receive at most a single message from each subscribed to topic per invocation
2. Publish at most a single message to each published to topic per invocation

To do otherwise would be rude.

One idea that was discussed for achieving this would be to maintain a map for each topic, and to set a boolean value whenever a message is published or subscribed to/from that topic. If publishing or subscribing happens 2x, then return a warning or error and prevent the operation. Upon subsequent invocations of the process or thread (for example, between calls to a module's "call" method), the topic map could be cleared to enable publishing/subscribing again.

It's very important that this solution work for all types of FrameworkRunnables.

These instructions should be listed, if at all, only for lidapy-framework examples that use gazebo, and should not be part of the general installation instructions.

I've stubbed out a set of "message classes" in both the Python LIDA framework and ROS for communications between the LIDA modules. We need to determine what these messages should look like and whether the current message classes are sufficient / desirable.

This is the list so far:

• Behavior
• Coalition
• ConsciousContent
• Cue
• Episode
• Feature
• Percept
• SpatialMap

One possible problem is that these messages are all "singular" nouns, but we may need to make them plural (e.g., Behaviors rather than Behavior).

I'm creating this issue to help organize the discussion.

@CognitiveComputingResearchGroup/python-lida-framework

Calling a script or program that spawns multiple processes from a element in a ROS launch file fails because ROS expects each to have a 1-to-1 mapping with a process.

If we don't want to structure our code to have a single script per module (which is annoying) then I think we will need to adopt a strategy similar to an earlier version of lidapy, which used command-line arguments to specify which module to launch in a multiple module script.

If someone has an alternate idea I am all ears... Otherwise, I am going to add some helper functions to lidapy to make supporting command-line arguments that launch a LIDA module easier.

Update ROS to Kinetic Kame.
Update Gazebo to Gazebo7.
Update Vagrant provisioning to use supported Ubuntu version (Ubuntu Wily (15.10) or Ubuntu Xenial (16.04 LTS)
Update LidaPy for ROS API changes.
Update document (README.md, etc.) to reflect these changes.

Let the pain begin!

This is a large task, so I may break it up into smaller issues. In particular, there is some "feasibility research" that needs to be done as part of this that may make it a bear.

Possible Complications and Considerations:

1. When attempting to upgrade to Ubuntu 16.04 several months ago, there were problems with the virtual box. It did not follow box standards and seemed unusable. This needs to be researched and may be a show stopper if we are unable to find a usable box.
2. It would be great if we could upgrade to Python 3, but I am not sure ROS is fully supporting Python 3 at this point. Additional research is needed.

We need to add classes to support the scheduling of "FrameworkTasks" as background threads/processes. Based on preliminary research on Python, it appears that, for CPU intensive operations, processes are necessary rather than threads. This is because the Python language has a GIL (Global Interpreter Lock) that will prevents more than one thread from executing Python bytecode at a time. In other words, Python threads will only improve performance on operations that have a long I/O wait.

Note: It will not be the responsibility of these new classes to coordinate the execution of the spawned up processes, so that they occur at a particular "tick" (as we did in the TaskManager class of the Java framework). Furthermore, each LIDA module will be independently responsible for managing its own process pool. (No global coordination!)

Need to restore the previous machine state (i.e., remove entries from .bashrc, remove workspace directory, remove .lidapy hidden directory, etc.) on error.

The setup script currently continues on error in many cases. Additional error handling is needed to stop further execution of steps in the script when one of the early steps results in an error.

Some received messages are None even when blocking receive and all published messages are not None.

Sean, help! I don't understand--please create an example so that I understand how to use this nice framework you've worked so hard to create!! Augggggh!!

I found that tensorflow has a pre-trained model for Image Recognition with a python API to it.

We might be able to use it directly without much hassle.

"When running the script the first time, you will have to run source ~/.lidapy/setup.bash."

It is unclear whether which of the two scripts should run first.

Also, it would be helpful to add one or two lines explaining precisely what the scripts will do.

The file "./scripts/setup.sh" is a file that setups up lidapy and should be run only ONCE.

It has the same name as files found in the "devel" folder of a ros workspace, which should be run any time one wants to configure their ros environment in a certain way.

The identical name seems unnecessary, and has the potential for confusing a user into believing that the /scripts/setup.sh file could be safely run more than once--this may not be the case!

It is suggested to change the filename to "setup_lidapy.sh" or something similar to avoid this confusion.

Is the execution in the framework scheduled based on time? If a process (call() method) takes long to execute, what happens then?

Installation of the lidapy framework does not generally proceed without problems. The installation script (currently named /scripts/setup.sh, see previous issue!) should therefore run in interactive mode by default--the additional screen space used will be no more an annoyance than the stdout produced during a ROS installation for instance, and could possibly provide information helpful for debugging a faulty installation.

We need to:

1. add method / class / module level comments to the code
2. determine if there is a way to externalize the API documentation from the code comments (similar to what we could do with javadoc)
3. document the usage of our configuration files
4. document steps to integration with ROS

When we get further along we will probably want to put together a workshop tutorial paper as well.

Ubuntu:
$ sudo apt-get install ros-jade-ros-base

Non-Ubuntu:
$ sudo echo "Installing ROS (the robot OS)" | tee -a /var/tmp/vagrant_prov.log
$ sudo apt-get install -y ros-jade-desktop-full &>>/var/tmp/vagrant_prov.log
$ sudo rosdep init &>>/var/tmp/vagrant_prov.log
$ rosdep -y update &>>/var/tmp/vagrant_prov.log

This is likely to produce dissonant behavior between the two installations.

Perhaps it is better to give the user the link to ROS installation instructions?
http://wiki.ros.org/jade/Installation/Ubuntu

Will try a new Ubuntu install
$ sudo apt-get update
$ sudo apt-get install ros-jade-desktop-full
$ sudo rosdep init
$ rosdep update
$ source /opt/ros/jade/setup.bash

According to our conceptual model, if a content is broadcasted it's activation in the Current Situational Model should be brought down to 0. Rationale is that once a content is broadcasted its immediate relevance/salience to the agent is reduced. Almost any other content is currently more important than this content. The content whose activation is forced to be 0 may gain activation again if it is still relevant.

This is a free sample.

We need to begin working on a set of unit test cases for the Python LIDA framework. We should also take advantage of GitHub's continuous integration options.

Outline of steps:

1. Explore options for Python unit testing
2. Implement the test cases for each module (We should try to break this up among the team members.)
3. Determine how these test cases can be automatically executed via a GitHub continuous integration provider

I've modified the repository to allow admin pull requests to bypass review. I don't like it, but the current process is not working well.

We can discuss this during our next meeting.

Something is going on with this test case. Need to figure out why it is occasionally causing the build to fail.

Traceback (most recent call last):

File "/home/travis/build/CognitiveComputingResearchGroup/lidapy-framework/test/test_lidapy.py", line 468, in test_listeners

self.assertEqual(1, len(listener.msg_queue))

AssertionError: 1 != 0