Merge branch 'master' of https://github.com/ab3nd/TinyRobo

docs/proposal/swarm.bib

@@ -5,6 +5,16 @@ @inproceedings{montgomery2009receiver
   year={2009}
 }
 
+@inproceedings{hayes2001swarm,
+  title={Swarm robotic odor localization},
+  author={Hayes, Adam T and Martinoli, Alcherio and Goodman, Rodney M},
+  booktitle={Intelligent Robots and Systems, 2001. Proceedings. 2001 IEEE/RSJ International Conference on},
+  volume={2},
+  pages={1073--1078},
+  year={2001},
+  organization={IEEE}
+} 
+
 @article{hasslacher1995living,
   title={Living machines},
   author={Hasslacher, Brosl and Tilden, Mark W},
@@ -16,6 +26,53 @@ @article{hasslacher1995living
   publisher={Elsevier}
 }
 
+@article{belta2007symbolic,
+  title={Symbolic planning and control of robot motion [grand challenges of robotics]},
+  author={Belta, Calin and Bicchi, Antonio and Egerstedt, Magnus and Frazzoli, Emilio and Klavins, Eric and Pappas, George J},
+  journal={IEEE Robotics \& Automation Magazine},
+  volume={14},
+  number={1},
+  pages={61--70},
+  year={2007},
+  publisher={IEEE}
+}
+
+@inproceedings{ashley2007meld,
+  title={Meld: A declarative approach to programming ensembles},
+  author={Ashley-Rollman, Michael P and Goldstein, Seth Copen and Lee, Peter and Mowry, Todd C and Pillai, Padmanabhan},
+  booktitle={2007 IEEE/RSJ International Conference on Intelligent Robots and Systems},
+  pages={2794--2800},
+  year={2007},
+  organization={IEEE}
+}
+
+@inproceedings{dantu2011programming,
+  title={Programming micro-aerial vehicle swarms with karma},
+  author={Dantu, Karthik and Kate, Bryan and Waterman, Jason and Bailis, Peter and Welsh, Matt},
+  booktitle={Proceedings of the 9th ACM Conference on Embedded Networked Sensor Systems},
+  pages={121--134},
+  year={2011},
+  organization={ACM}
+}
+
+@inproceedings{mottola2014team,
+  title={Team-level programming of drone sensor networks},
+  author={Mottola, Luca and Moretta, Mattia and Whitehouse, Kamin and Ghezzi, Carlo},
+  booktitle={Proceedings of the 12th ACM Conference on Embedded Network Sensor Systems},
+  pages={177--190},
+  year={2014},
+  organization={ACM}
+}
+
+@inproceedings{viroli2012linda,
+  title={Linda in space-time: an adaptive coordination model for mobile ad-hoc environments},
+  author={Viroli, Mirko and Pianini, Danilo and Beal, Jacob},
+  booktitle={International Conference on Coordination Languages and Models},
+  pages={212--229},
+  year={2012},
+  organization={Springer}
+}
+
 @inproceedings{sims1994evolving,
   title={Evolving virtual creatures},
   author={Sims, Karl},

docs/proposal/swarm_proposal.tex

@@ -442,7 +442,7 @@ \subsubsection{Pheromone Approaches}
 Because pheromones are chemicals with spatial locations, it would be possible to combine the use of pheromones with reaction diffusion equations to structure activity within a space or to converge to patterns of activity over time  \cite{turing1952chemical}. 
 Assuming even diffusion of the robots in space, the global map of the pheromone concentrations is represented over the network by the locally-computed concentrations computed by each robot.
 
-In pheromone robotics, the pheromones are usually simulated or ``virtual'' pheromones, rather than real chemicals which are detected by chemical sensors. 
+In pheromone robotics, the pheromones are usually simulated or ``virtual'' pheromones, rather than real chemicals which are detected by chemical sensors (for an exception, see \cite{hayes2001swarm}). 
 Each pheromone can have properties such as diffusion and evaporation rates that result in the pheromone spreading in space or gradually disappearing. 
 In addition to its properties, the pheromones may have other characteristics which robots can sense. 
 For example, a robot may emit a pheromone which diffuses into the environment and evaporates quickly, so distance from the robot can be determined by the strength of the pheromone, and approaching or avoiding the robot may be accomplished by moving up or down the gradient of pheromone strength. 
@@ -509,12 +509,13 @@ \subsubsection{Pheromone Approaches}
 \subsubsection{Compositional Approaches}
 
 Rather than developing a novel control program for each robot automatically, it may be possible to compose programs from behavioral primitives, such that some combination of the primitives results in the emergence of the desired behavior. 
-A compositional approach to program generation requires the definition of primitives out of which programs can be composed. 
+A compositional approach to program generation requires the definition of primitives out of which programs can be composed, and some degree of assurance that these primitives can cover the space of possible tasks required from the robot. 
 One possible list of primitives is disperse (no other nodes within distance d), general disperse (no more than n nodes within distance d), clump/cluster, attract to location, swarm in a direction, and scan area \cite{evans2000programming}.
 Another proposed catalog of behaviors for swarm control bases the simple behaviors on pheromones or chemical sensing in single cells \cite{nagpal2004catalog}. 
 The proposed behaviors are the use of gradient sensing for position and direction information, local inhibition and competition, lateral inhibition for spatial information, local monitoring, quorum sensing for timing and counting, checkpoint and consensus sensing, and random exploration. 
 The first five are common in amorphous computing as well, but the last three are not. %TODO what are their uses?. 
-While these behaviors are themselves expressed in terms of pheromones, the composition of the primitives into complete programs is not dictated by a pheromone-based system. 
+While these behaviors are themselves expressed in terms of pheromones, the composition of the primitives into complete programs is not dictated by a pheromone-based system.
+Furthermore, compostional approaches have been proposed in control-theoretic terms as well as pheremone-based terms, so the process of composition of primitives can be viewed as a metastrategy for the creation of programs, rather than a process specific to pheremone robotics \cite{belta2007symbolic}.
 
 These senses are sufficient for relatively complex behaviors. 
 Quorum sensing is used to detect whether the local agent count is sufficient for a task. 
@@ -662,6 +663,36 @@ \subsubsection{Evolutionary Composition}
 Such a library could take advantage of the possible overfitting of GA evolution by storing primitives intentionally overfitted to specific situations and robots, and using the best matches. 
 For example, a controller that aggregates small-scale UAVs outdoors is likely quite different from one that aggregates medium-scale wheeled robots indoors, even though they are both aggregation controllers. 
 
+\subsection{Domain-Specific Languages for Swarm Robotics}
+
+Proto and other programming languages for amorphous computers provide abstractions for compuation performed on homogeneous spatially-distributed computating nodes, but do not generally support motion of nodes within the space. 
+Other versions of tuple-space based amorphous computation include motion of the agents, but do not explicitly support heterogeneity \cite{viroli2012linda}.
+
+The Voltron programming language provides what its authors describe as ``team-level programming'' for autonomous drones \cite{mottola2014team}.
+This level of programming is distinct from drone-level programming, where specific instructions are provided to each drone, and swarm programming, where each drone has the same instructions and operates without communication with other drones.
+Voltron programs consist of sensing tasks that are subject to space and time constraints, so the language does not permit the user to specify direct interactions between drones. 
+This leaves out activities beyond sensing that may be useful for swarm robots, such as patrolling an area or collaboratively moving an object.
+Additionally, Voltron is based on the assumptions that drones have global localization, synchronous clocks, and reliable inter-unit communication.   
+
+Karma provides a programming framework for micro-aerial vehicles with minimal localization and no communication in the field \cite{dantu2011programming}.
+The framework allows the composition of behaviors described at the level of individual robots. 
+Rather than each robot performing series of behaviors in response to input from its sensors, each robot is tasked by a central ``hive'' to perform a single behavior, such as performing a sensor sweep of an area. 
+The hive collects data from robots as they return to the hive, and updates a central data store, which includes both the sensor information from the individual robots and spatial information about the sensor information. 
+The hive then assigns activities to robots based on rules that use the central data store to determine which activities should be performed. 
+As a result, while the individual robots are autonomous and not in communication with the hive while operating, the hive maintains a central data store that is used to guide the future behaviors of the swarm. 
+This model does permit a form of interaction between swarm members, in that information from one swarm member can inform the behavior of another member, but it does not permit dynamic collaboration between swarm members while they are operating away from the hive. 
+
+Meld is a programming language for robot ensembles, which are composed of individual modular robots \cite{ashley2007meld}. 
+However, many of the problems facing an ensemble of modules are the same as those facing a swarm, such as determining the overall goal, moving to proper positions, and detecting when the goal has been acheived. 
+Meld is written in terms of facts and rules. 
+Facts describe things such as adjacency between robots and location of robots. 
+Rules are applied to facts, resulting in the generation of new facts. 
+By including rules that generate facts which describe motor actions, the application of rules to the known state of the system can create a ``to-do list'' of actions for individual members of the system to perform. 
+Rules are said to ``prove'' facts, and when no further facts can be proven, the system has arrived in a final state. 
+Since facts that alter the state of the world can make previous facts false, the set of facts available must be periodically purged of facts that no longer hold. 
+The authors of Meld point out that logic programming, of which Meld is an example, is poor at representing state beyond what can be computed as a consequence of the base facts. 
+However, it is also claimed that the use of aggregates, which compute results based on the provable facts, can be used to store state about the system, avoiding this restriction. 
+
 \section{Proposed work}
 
 For the purposes of this work, the tasks that users will be asked to complete consist largely of directing the motion of the swarm. 
@@ -717,7 +748,7 @@ \subsection{Compilation of user commands into robot programs}
 For example, if the task assigned to the swarm is to surround a fixed point, and localization information is available, then each robot can be given a program that instructs it to move towards a known location, based on its current known location.
 Even if the robots cannot determine their location, but the UI and program generator have it, the robots closest to the point can be assigned programs that cause them to act as beacons, while all the other robots are assigned programs to wander until they see a beacon and then move towards it. 
 If, instead, neither the robots nor the program generator have information on the location of the robots, then all of the robots can be assigned programs that instruct them to wander until they detect the target point, and then act as beacons, at which point the overall behavior of the system returns to the previous example.
-In the most extreme case, neither the robots nor the user interface have any information about the location of the robots. This extreme is outside the scope of this work, as it is more suited to an interface that permits the provisioning of the robots with a description of the target point. A method for providing such a description through multitouch gestures is likely to be more tedious than other approaches, e.g. summarizing desired sensor precepts or including an image of the target area for the robots to recognize. 
+In the most extreme case, neither the robots nor the user interface have any information about the location of the robots. This extreme is outside the scope of this work, as it is more suited to an interface that permits the provisioning of the robots with a description of the target point. A method for providing such a description through multitouch gestures is likely to be mNSFore tedious than other approaches, e.g. summarizing desired sensor precepts or including an image of the target area for the robots to recognize. 
 
 All of the valid expressions possible in the command language should be converted into programs for the robots, or the user must be usefully informed as to why it was not possible. 
 The synthesized program should result in convergence of the swarm's overall behavior to the desired result. 

docs/robot_makers_2/root.tex

@@ -22,6 +22,8 @@
 %\usepackage{amsmath} % assumes amsmath package installed
 %\usepackage{amssymb}  % assumes amsmath package installed
 
+\linespread{0.99}
+
 \title{\LARGE \bf
 TinyRobo: A Platform for Tabletop Swarm Research
 }
@@ -163,8 +165,12 @@ \section{Conclusions}
 TinyRobo provides a hardware platform for relatively cheap and easy construction of tabletop swarm robots.
 Unlike many previously existing platforms, it is commercially available, and can be extended by users to new mobility hardware. 
 The TinyRobo schematics and PCB design files are available at \url{https://github.com/ab3nd/TinyRobo/}, and the PCBs are commercially available from Dirty PCBs at  \url{http://dirtypcbs.com/view.php?share=20617&accesskey=775edbb47111a5cd47e422829b761675}
+
+\section{Acknowledgements}
+
+This work was supported in part by the National Science Foundation through IIS-1426968. 
+
 \bibliographystyle{apalike}
 \bibliography{rm2.bib}
 
-
 \end{document}

software/argos_sim/CMakeLists.txt

@@ -0,0 +1,42 @@
+cmake_minimum_required(VERSION 2.8.12)
+project(argos_tinyrobo)
+
+# Deactivate RPATH for MacOSX
+set(CMAKE_MACOSX_RPATH 0)
+
+# Set the path where CMake will find additional scripts
+set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} ${CMAKE_SOURCE_DIR}/cmake)
+
+# Find the ARGoS package, make sure to save the ARGoS prefix
+find_package(PkgConfig)
+pkg_check_modules(ARGOS REQUIRED argos3_simulator)
+set(ARGOS_PREFIX ${ARGOS_PREFIX} CACHE INTERNAL "")
+set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} ${ARGOS_PREFIX}/share/argos3/cmake)
+
+# Check whether all the necessary libs have been installed to compile the
+# code that depends on Qt and OpenGL
+include(ARGoSCheckQTOpenGL)
+
+# Look for the (optional) galib library
+#find_package(GALIB)
+#if(GALIB_FOUND)
+#  include_directories(${GALIB_INCLUDE_DIRS})
+#endif(GALIB_FOUND)
+
+# Find Lua
+find_package(Lua52 REQUIRED)
+
+# Set ARGoS include dir
+include_directories(${CMAKE_SOURCE_DIR} ${ARGOS_INCLUDE_DIRS} ${LUA_INCLUDE_DIR})
+
+# Set ARGoS link dir
+link_directories(${ARGOS_LIBRARY_DIRS})
+
+# Descend into the controllers directory
+#add_subdirectory(controllers)
+
+# Descend into the loop_functions directory
+#add_subdirectory(loop_functions)
+
+# Descend into the embedding directory
+#add_subdirectory(embedding)

software/argos_sim/buzz_scripts/gradient.bzz

@@ -0,0 +1,30 @@
+
+#This is just the sample gradient buzz script from the wiki
+
+function init() {
+  if(id == 0) {
+    # Source robot
+    mydist = 0.
+  }
+  else {
+    # Other robots
+    mydist = 1000
+	 # Listen to other robots' distances
+    neighbors.listen("dist_to_source",
+      function(value_id, value, robot_id) {
+        mydist = math.min(
+          mydist,
+          neighbors.get(robot_id).distance + value)
+		  debug("mydist = ", mydist)
+      })
+  }
+}
+
+function step() {
+  neighbors.broadcast("dist_to_source", mydist)
+  debug("d=", mydist)
+}
+
+function destroy() {
+}
+