Week of June 8th
I familiarized myself with the simulation software used by my group and experimented with modifying an input file to run simulations with different parameters. I created 2 annotated movies of a pursuit/evasion scenario with different conditions (one with the pursuers having a larger view radius than the evaders, and the other with the reverse situation). In the process I became familiar with the Linux/UNIX command-line interface.
I also defined my research plan for the summer and gave a short presentation of my plan to members of the Parasol lab. I will be working on modularity, the concept of compartmentalizing the existing group behavioral framework into discrete modules that can be combined in different ways to achieve a greater variety of behaviors. I will be using this updated framework to create various multiple-agent area search behaviors, which involves a group of agents searching an obstacle-filled space for a stationary or mobile target.
This week I attended an informative Brown Bag seminar about graduate school, which will be beneficial to me as I am about to start looking for graduate schools.
Week of June 15th
This week I am took my first look at the C++ behavioral framework. I am in the midst of modifying the code to decouple strategies from specific behaviors so that a strategy can be used by more than just one behavior.
I moved the flee strategy from the FleeBehavior() class to a RandSpotScoreStrat() class, which inherits from the GeneralStrategy() class. I then simulated the new implementation to verify its correctness; the agents' behavior does not seem different from before, so the implementation is unlikely to be incorrect. [Edit - this was proved wrong later on.] Moving the strategy consisted of moving six functions (deviseStrategy, needsStrategy, adjustStrategy, hasNoStrategy etc.) to the RandSpotScoreStrat class, as well as some functions related to them (such as scorePt, which scores points generated in the strategy according to their distance and direction from pursuing agents). I also moved the generateSpots() function to a Building Blocks class as suggested by Jory.
I initially encountered problems with compiling the new code because the functions I had moved made use of several other functions inherited by the FleeBehaviors class from CGeneralEvadingRule and so on. These functions include communicateArea, findPath and updateVisibleAgents. I considered copying these functions to the GeneralStrategy class so that the functions in the RandSpotScoreStrat class would be able to use them, but I found that these functions were themselves using other functions embedded in the classes. According to Phil's suggestion, I instead created functions that used getCurrentBehavior() to access these functions.
I also wrote a loadStrategy() function in sh_gui_main.cpp, similar to loadBehaviorRule and the load() functions in individual behaviors, that loads variables according to a strategy and values specified in the input file.
Next week I plan to try and migrate more strategies and maybe start creating my own strategies.
Week of June 22nd
I successfully extracted the hiding strategy from HideBehavior class and moved it to a new class, FreePtMemScoreStrat, which inherits from the GeneralStrategy class. This was very similar to what I had done for the Flee behavior so it took very little time, but didn't give me much of an insight into the code.
However, I learned a lot from the foraging behavior. I moved the foraging strategy from CForagingBehavior class to ForageSpotScoreStrat, which inherits from the GeneralStrategy class. The foraging strategy required some changes compared to the previous strategies (hide and flee) because the functions . Since these strategies can be called by different behaviors, it was necessary to rename needsExploreArea etc. according to the conventions used by Flee and Hide, or at least make it possible to call needExploreArea, etc. from behaviors other than Foraging.
I found this week's Parasol seminar by Dr. Dinesh Manocha especially fascinating. He is also heavily involved in multi-agent simulation and had a very unique approach to creating collision-free simulations. Although I know motion planning and multi-agent robotics are vast areas of research, seeing Dr. Manocha's research gave me a basis for comparison with the mtehods of my group, the Group Behaviors group at the Parasol lab.
Week of June 29th
I am currently attempting to diagnose problem occuring when a behavior calls a strategy not originally associated with it. The behaviors generally work when they call the specific strategies that were extracted from them (as one would expect), but fail when they call other strategies.
I am temporarily reverting the Forage behavior by removing the ForageSpotScoreStrat class so that I can focus on making Flee and Hide correctly interchangeable. I am also mapping the relationships of the different functions in the Flee/Hide behaviors and strategies and moving some functions/variables from strategies to their original behaviors. Since I originally copied all variables defined in the behaviors to their respective strategies, I will determine if I need to erase definitions of certain variables (e.g. bool m_useMemory) from either the behavior or the strategy (and make the appropriate change in the input file).
I liked the Technical Writing presentation given during the Brown Bag seminar this week. It was short and somewhat general, but the speaker had an unusual (and interesting) take on a technical report as a kind of storyline.
Week of July 6th
I realized what I had been doing wrong when extracting strategies from behaviors - I was moving too much. It was decided that I should take a step back and examine my approach more closely before trying to move anything else.
Accordingly, I planned a modification to the behavioral framework that would allow behaviors and strategies to be more compatible. The problem is that strategies currently only work with the specific behaviors they were designed for. Even when strategies associated with different behaviors have functions of the same name (e.g. needsStrategy), the functions are different, which I hadn't realized at first. Some analogous functions work very differently from one another, i.e. a boolean function in the Flee behavior and a similarly named in the Hide behavior return true on almost exactly the opposite conditions.
According to my proposed modification, behavior classes will define functions that decide when goals should be set while strategy classes will define functions that set goals. By separating the "why" and "how" of goal creation, it should be possible for behaviors to work with any strategy. A behavior will still be able to decide when it is relevant, and only the method by which it can set a goal (and the resulting movement by the agent) will change.
Week of July 13th
This week I implemented the changes I proposed last week, with the two simplest behaviors (Flee and Hide). Fortunately, I don't have to modify any functions in any major way. All the cases for a behavioral response (or lack thereof) are pretty much covered by the existing functions. It's just a matter of moving the right functions to the strategies while retaining the others in the behaviors. I feel like I've made a leap of understanding here.
I also attended the first set of REU student presentations on Thursday. Many of the other REU students are doing interesting research, but I guess it is too early for them to be showing any results, since we still have a couple of weeks.
Week of July 20th
Major progress this week! I managed to convert the forage behavior into a strategy (much more correctly this time) and modified the applyRule() function of the General Exploration Rule to use the new proposed methods needsGoal and applyGoal. These two functions will likely become the standard way of evaluating and setting goals.
I have tested the strategies of flee, hide and forage for their interchangeability among the three behaviors. three appear to work correctly when changed around, with a minor quirk involving the hide behavior. (I suspect I'll find some errors or other oddities but these should be easily corrected.)
I noticed an interesting behavior whereby under one combination, the foraging agents stay out of one another's view radius. This is direct proof that using strategies is advantageous. At first I thought the 'spread out and forage' behavior was an example of emergence.
I also prepared my paper outline this week. Things are starting to pick up, and I'm preparing for a busy week ahead.
Week of July 27th
This was the penultimate week, and I'm glad I managed to tie up most things. I started by fixing an issue with odd behavior that occurred when strategies were switched around. Last week, some combinations of strategies produced odd behavior, such as agents perpetually oscillating between two positions when using Hide behavior. This was caused by how I handled the different goal-setting method of the Forage strategy compared to the Flee/Hide strategies. I have modified my workaround and the odd behavior has largely disappeared; interchanging strategies is now more natural.
There are still a couple of quirks, such as one with the Hide behavior, but I don't believe these are related to the modifications I made and I don't think they really affect the simulation too much. So far, all of my attempts to solve this problem have led to more problems. In any case, I will work on correcting these next week.
Week of August 5th
I'm now in the final week of summer research! The summer has gone by a little too quickly. I'm glad to have had the experience. This should prepare me well for doing a senior-year thesis over the next two semesters. My Undergraduate Research Fellows application has just been approved and I'm eagerly anticipating my final year as an undergrad.