Menu
▾
▴
simspark-svn
|
From: <yx...@us...> - 2013-03-12 14:03:24
|
Revision: 335
http://simspark.svn.sourceforge.net/simspark/?rev=335&view=rev
Author: yxu
Date: 2013-03-12 14:03:10 +0000 (Tue, 12 Mar 2013)
Log Message:
-----------
* open-source-paper:
institute
chmod a-x
image of simspark for SPL
realistic motor (copied from my thesis)
Modified Paths:
--------------
trunk/spark/doc/papers/2013/opensource.tex
trunk/spark/doc/papers/2013/reference.bib
Added Paths:
-----------
trunk/spark/doc/papers/2013/battery.tikz
trunk/spark/doc/papers/2013/fig/
trunk/spark/doc/papers/2013/fig/simspark-spl.png
trunk/spark/doc/papers/2013/joint-temp-LKneePitch.tikz
trunk/spark/doc/papers/2013/joint.tikz
trunk/spark/doc/papers/2013/latexmkrc
Added: trunk/spark/doc/papers/2013/battery.tikz
===================================================================
--- trunk/spark/doc/papers/2013/battery.tikz (rev 0)
+++ trunk/spark/doc/papers/2013/battery.tikz 2013-03-12 14:03:10 UTC (rev 335)
@@ -0,0 +1,248 @@
+%This file is generated by REP 0.0.2-383-g17a87c3-dirt
+
+\begin{tikzpicture}
+\pgfplotsset{anchor=north west}
+\pgfmathsetlengthmacro{\cellWidth}{\pgfkeysvalueof{/pgfplots/width}/1}
+\pgfmathsetlengthmacro{\cellHeight}{\pgfkeysvalueof{/pgfplots/height}/1}
+\pgfmathsetlengthmacro{\x}{0*\cellWidth}
+\pgfmathsetlengthmacro{\y}{0*\cellHeight}
+\pgfmathsetlengthmacro{\w}{1*\cellWidth}
+\pgfmathsetlengthmacro{\h}{1*\cellHeight}
+\begin{axis}[at={(\x,\y)}, width=\w, height=\h,
+hide x axis,
+axis y line*=right,
+enlarge x limits=false,
+ylabel={electric current (A)},
+xmin=0, xmax=750,
+]
+\addplot[every mark/.append style={solid},
+blue, dashdotted, mark=none] table[x=x, y=y] {
+x y
+5.043 1.61812632873
+15.0605 2.61651190247
+25.0735 2.72887719713
+35.0845 2.74117345598
+45.0985 2.70330908693
+55.129 2.74450510209
+65.1585 2.71658678486
+75.186 2.69235892598
+85.216 2.8823921542
+95.246 2.84156823026
+105.276 2.72627254765
+115.306 2.72972769432
+125.336 2.76257819429
+135.366 2.78718949213
+145.396 2.76316291264
+155.4275 2.75673101752
+165.457 2.76341345437
+175.4855 2.78213965807
+185.516 2.77809979032
+195.546 2.81913633817
+205.576 2.79840543607
+215.606 2.70479746263
+225.6365 2.72664463872
+235.666 2.74461141601
+245.696 2.77645195218
+255.726 2.73903002336
+265.755 2.80485345525
+275.785 2.79718284849
+285.815 2.71744862436
+295.845 2.8247708872
+305.876 2.72425261044
+315.906 2.42902336058
+325.935 2.35518946888
+335.965 2.16680407679
+345.9955 2.13273099877
+356.0265 2.16287054206
+366.0565 2.21978677654
+376.0855 2.25849845541
+386.1205 2.38293698811
+396.161 2.70612636778
+406.191 2.72186058355
+416.2055 2.75834678929
+426.2155 2.75598683227
+436.2255 2.85653345962
+446.243 2.75231905853
+456.2685 2.72212636345
+466.2935 2.7664001276
+476.3065 2.77045345349
+486.3085 2.76357345341
+496.3185 2.79606656726
+506.3355 2.78725345939
+516.351 2.7815017834
+526.36 2.84090679411
+536.376 2.77464464325
+546.391 2.71925345433
+556.405 2.77517620298
+566.4195 2.80583290053
+576.429 2.80621939212
+586.44 2.87509345987
+596.457 2.86788052256
+606.482 2.86203334873
+616.4985 2.88117345801
+626.5115 2.86623268571
+636.525 2.85541346184
+646.546 2.85868450975
+656.5735 2.86570679399
+666.5865 2.76313055614
+676.602 2.85113633756
+686.6235 2.72207321086
+696.6455 2.49382072336
+706.676 2.30139545007
+716.705 2.23011303686
+726.7345 2.24419943926
+736.7645 2.36709643944
+746.794 2.29889709886
+756.824 2.45491038409
+766.854 1.31349337919
+776.8845 0.0
+786.9145 0.0
+}; \label{real-current}
+\addplot[every mark/.append style={solid},
+magenta, dotted, mark=none, thick] table[x=x, y=y] {
+x y
+5.005 2.39675
+15.02 2.68107652695
+25.035 2.78480077844
+35.045 2.82327305389
+45.06 2.79132191617
+55.075 2.85058005988
+65.09 2.83838011976
+75.105 2.74701850299
+85.12 2.8003005988
+95.135 2.79988568862
+105.15 2.69727335329
+115.175 2.77754988024
+125.205 2.80128526946
+135.235 2.70671185629
+145.265 2.8217697006
+155.295 2.77411047904
+165.325 2.64893652695
+175.355 2.6990351497
+185.385 2.68256107784
+195.415 2.7540411976
+205.445 2.69730203593
+215.475 2.7335502994
+225.505 2.77422005988
+235.535 2.75148209581
+245.565 2.78419742515
+255.595 2.76504532934
+265.625 2.83281143713
+275.655 2.68026155689
+285.68 2.83020197605
+295.705 2.73585239521
+305.735 2.72528179641
+315.765 2.77525718563
+325.795 2.62815724551
+335.825 2.54314449102
+345.855 2.36030287425
+355.885 2.19402676647
+365.915 2.22898053892
+375.945 2.65052802395
+385.975 2.87474269461
+396.005 2.76045802395
+406.035 2.81162502994
+416.065 2.67910329341
+426.095 2.77494473054
+436.125 2.73028616766
+446.155 2.86563964072
+456.185 2.71784497006
+466.215 2.76890179641
+476.245 2.65759502994
+486.275 2.67877886228
+496.305 2.73931646707
+506.335 2.66729622754
+516.365 2.75485718563
+526.395 2.70058550898
+536.425 2.7470360479
+546.455 2.74969670659
+556.485 2.80388341317
+566.515 2.82135592814
+576.545 2.74127479042
+586.575 2.82163269461
+596.605 2.75241245509
+606.635 2.80448754491
+616.665 2.70096850299
+626.695 2.74002634731
+636.725 2.82832305389
+646.755 2.8212657485
+656.785 2.86141125749
+666.815 2.82044011976
+676.845 2.77074317365
+686.875 2.1409502994
+696.905 2.27848173653
+706.935 2.11926419162
+716.965 2.39025808383
+726.995 2.45736305389
+737.025 2.16040586826
+}; \label{sim-current}
+\end{axis}
+
+
+\begin{axis}[at={(\x,\y)}, width=\w, height=\h,
+xmin=0, xmax=750,
+xlabel={time (s)},
+ylabel={battery ($\times$51Wh)},
+legend pos=south west
+]
+\addplot[every mark/.append style={solid},
+black, solid, mark=none] table[x=x, y=y] {
+x y
+0 0.67
+60 0.6595
+120 0.649
+180 0.6385
+240 0.628
+300 0.6075
+360 0.597
+420 0.5765
+480 0.566
+540 0.5455
+600 0.535
+660 0.5245
+720 0.504
+780 0.4935
+840 0.473
+900 0.4625
+960 0.442
+1020 0.4315
+1080 0.421
+1140 0.4005
+1200 0.39
+1260 0.3695
+1320 0.359
+};
+\addlegendentry{real battery}
+\addplot[every mark/.append style={solid},
+red, densely dashed, mark=none, thick] table[x=x, y=y] {
+x y
+0 0.67
+60 0.66
+120 0.64
+180 0.63
+240 0.62
+300 0.61
+360 0.59
+420 0.58
+480 0.56
+540 0.55
+600 0.54
+660 0.52
+720 0.5
+780 0.49
+840 0.47
+900 0.46
+960 0.45
+1020 0.43
+1080 0.42
+1140 0.4
+1200 0.38
+1260 0.37
+1320 0.36
+};
+\addlegendentry{sim battery}
+\addlegendimage{/pgfplots/refstyle=real-current, blue, dashdotted}\addlegendentry{real
+ current}
+\addlegendimage{/pgfplots/refstyle=sim-current, magenta, dotted}\addlegendentry{sim current}
+\end{axis}
+\end{tikzpicture}
Added: trunk/spark/doc/papers/2013/fig/simspark-spl.png
===================================================================
--- trunk/spark/doc/papers/2013/fig/simspark-spl.png (rev 0)
+++ trunk/spark/doc/papers/2013/fig/simspark-spl.png 2013-03-12 14:03:10 UTC (rev 335)
@@ -0,0 +1,6217 @@
+\x89PNG
+
+ |
|
From: <yx...@us...> - 2013-03-15 15:38:26
|
Revision: 336
http://simspark.svn.sourceforge.net/simspark/?rev=336&view=rev
Author: yxu
Date: 2013-03-15 15:38:19 +0000 (Fri, 15 Mar 2013)
Log Message:
-----------
* open-source-paper:
more hints
text for figure
improve figure
restruct
Modified Paths:
--------------
trunk/spark/doc/papers/2013/joint.tikz
trunk/spark/doc/papers/2013/opensource.tex
Modified: trunk/spark/doc/papers/2013/joint.tikz
===================================================================
--- trunk/spark/doc/papers/2013/joint.tikz 2013-03-12 14:03:10 UTC (rev 335)
+++ trunk/spark/doc/papers/2013/joint.tikz 2013-03-15 15:38:19 UTC (rev 336)
@@ -2,36 +2,33 @@
\tikzstyle{module}=[draw, minimum height=1cm, minimum width=2cm]
\node[module] (sc) {\shortstack{Stiffness\\ Control}};
- \draw[<-] (sc) -- node[near end, above]{$k_s$} ++(-2,0);
+ \draw[<-] (sc) -- node[at end, above]{$k_s$} ++(-2,0);
- \node[module] (bl) at (3,0) {Backlash};
+ \node[module] (bl) at (3,0) {\shortstack{Temperature\\ Regulation}};
\draw[->] (sc) -- node[above]{$\tau_{max}$} (bl);
- \node[module] (ode) at (6,-1) {\shortstack{Simulation\\ Engine}};
- \draw[->] (ode) -- ++(0,2) -| node[above, near start]{$\theta, \dot{\theta}$}
- (bl);
+ \node[module] (ode) at (6,1) {\shortstack{Simulation\\ Engine}};
\draw[->] (bl.east) -- ++(0.3,0) |- node[right, near start]{$\tau_m$}
- ($(ode.north west)!0.3!(ode.south west)$);
-
- \node[module] (pd) at (0, -2) {\shortstack{PD\\ Controller}};
- \draw[<-] (pd) -- node[above, near end]{$\theta_r$} ++(-2,0);
- \draw[->] (ode) -- ++ (0,-2.3) -| node[above, near start] {$\theta,
- \dot{\theta}$} (pd);
-
- \node[module] (sl) at (3,-2) {\shortstack{Speed\\ Limitation}};
- \draw[->] (pd) -- node[above]{$\dot{\theta_r}$} (sl);
- \draw[->] (sl.east) -- ++(0.3,0) |- node[right, near start]{$\dot{\theta_e}$}
($(ode.north west)!0.7!(ode.south west)$);
+ \node[module] (sl) at (1.5,2) {\shortstack{Speed\\ Limitation}};
+ \draw[<-] (sl) -- node[above, at end]{$\dot{\theta_r}$} ++(-3.5,0);
+ \draw[->] (sl.east) -- ++(1.9,0) |- node[right, near start]{$\dot{\theta_e}$}
+ ($(ode.north west)!0.3!(ode.south west)$);
+
\draw[->] ($(ode.north east)!0.3!(ode.south east)$) -- node[above,
- at end]{$\theta$} ++(5,0);
+ at end]{$\theta$} ++(6,0);
- \node[module] (ps) at (9.5,-2) {\shortstack{Power\\ Consumption}};
+ \node[module] (ps) at (9.5, 0) {\shortstack{Power\\ Consumption}};
\draw[->] ($(ode.north east)!0.7!(ode.south east)$) -- ++(0.3,0) |-
node[right, near start] {$\tau, \dot{\theta}$} (ps);
+ \draw[->] (ps) -- ++(0,-1) -| node[above, near start]{$\Delta{Q}^+$}
+ (bl);
- \draw[->] (ps) -- node[above, near end]{$E,T$} ++(2.5,0);
+ \node[module] (bat) at (6, -2.5) {Battery};
+ \draw[->] (ps) -- ++(2, 0) |- node[above, near end]{$E$} (bat);
+ \draw[->] (bat) -| node[above, near start] {On/Off} (sc);
- \draw[dashed] (-1.3,-3.5) rectangle (11,2) node[anchor=north east] {Servo Motor Model};
+ \draw[dashed] (-1.3,-1.5) rectangle (12,3) node[anchor=north east] {Servo Motor Model};
\end{tikzpicture}
\ No newline at end of file
Modified: trunk/spark/doc/papers/2013/opensource.tex
===================================================================
--- trunk/spark/doc/papers/2013/opensource.tex 2013-03-12 14:03:10 UTC (rev 335)
+++ trunk/spark/doc/papers/2013/opensource.tex 2013-03-15 15:38:19 UTC (rev 336)
@@ -52,24 +52,34 @@
\maketitle
\begin{abstract}
- this is abstract
+ - current state of simspark
+ - changes 2013
+ - evidence of impact of the released component to the RoboCup community.
+ - technical contribution
+ - benefit for the RoboCup community.
\end{abstract}
\section{Introduction}
+The development on robots may be severely limited by the constrained resources.
+This is especially true in the research of multi-robots systems in areas such as RoboCup.
+Using simulation for algorithm development and testing makes thing easier.
\todo[inline]{Background/histsory}
\cite{Boedecker2008,OR05}
\todo[inline]{Releated work: SimRobot, Webots, V-REP, Gazebo...}
-\section{Current state / development sicen 2008}
+\section{Current state / development since 2008}
Because last paper about simspark was in 2008
\todo[inline]{sensors: ACC, FSR, restict vision, with line perceptions, image ...}
\todo[inline]{robot model: NAO}
\todo[inline]{soccer rules (referee)}
\todo[inline]{bigger fields and more robots}
-\section{realistic motor modelling}
+\section{Recent Development (Changes 2013)}
+
+
+\subsection{Realistic Motor}
NAO robot has twenty-one motor joints as its actuators.
The simple motor model is one reason for the unrealistic simulation results.
The ODE provides a simple model of real life servos.
@@ -77,9 +87,6 @@
There is no motor that works like this in reality.
Furthermore, some aspects like stiffness control, power consumption and temperature regulation, are missing but are also important for robotics.
-
-A PD controller was implemented for the simulated NAO. \todo{this is for angle position control like DCM of NAO}
-
\paragraph{Stiffness}
The stiffness determines how strong the motor is. The value is from 0.0
to 1.0, 0 means the motor is off and 1 means the motor is running at
@@ -218,13 +225,10 @@
\end{figure}
The whole process of joint simulation is summarized in
-\Cref{fig:joint}: stiffness is simulated by setting the maximum torque of
-the motor; desired speed of motor is determined by a PD controller
-according to the target angle (see \cref{eva-joint-motor}), current angle and current speed; backlash
-is modeled by the dead band model; and the simulation engine computes
-the resulted angle and torque applied; in the end, the consumed power
-and temperature are computed by \cref{eq:motor-power,eq:motor-temp}
-respectively.
+\Cref{fig:joint}: stiffness $k_s$ is simulated by setting the maximum torque
+of the motor $\tau_{max}$; the final maximum torque $\tau_m$ used by simulation engine is calculated by temperature regulation; and the simulation engine computes the resulted angle
+and torque applied; in the end, the consumed power and temperature are
+computed by \cref{eq:motor-power,eq:motor-temp} respectively. When the battery is empty, the maximum torque $\tau_{max}$ is set 0 to turn off the motor.
\begin{figure}
\centering
\inputtikz{joint}
@@ -232,11 +236,19 @@
\label{fig:joint}
\end{figure}
-\section{applications}
+\subsection{Heterogeneous Robots}
+\subsection{Agent Proxies}
+
+\subsection{Player Integration??}
+
+\section{Applications}
+
\paragraph{RoboCup simulation league (of course)}
+- some research?
+- roboviz
-\paragraph{research (used by teams have real robot)}
+\paragraph{Usage in real robot teams}
- we (NaoTH) have shared common interface with NAO
- FUmanoid
- education
@@ -245,17 +257,10 @@
\centering
\includegraphics[width = 0.95\columnwidth]{simspark-spl}
\caption{Prototype of the extended SimSpark for Standard Platform League.
- It simulates a game in our lab. The bottom of screen are images of robot cameras.}
+ The bottom of screen are images of robot cameras.}
\label{f:nao-models}
\end{figure}
-\section{development plan/ current development}
-\begin{itemize}
-\item heterogeneous robots
-\item agent proxies
-\item Player integration
-\end{itemize}
-
\section{Conclusion and Future Work}
\bibliographystyle{splncs03}
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <yx...@us...> - 2013-03-19 06:12:51
|
Revision: 338
http://simspark.svn.sourceforge.net/simspark/?rev=338&view=rev
Author: yxu
Date: 2013-03-19 06:12:44 +0000 (Tue, 19 Mar 2013)
Log Message:
-----------
Merge branch 'open-source-paper'
* open-source-paper:
some text
details in application
Modified Paths:
--------------
trunk/spark/doc/papers/2013/opensource.tex
trunk/spark/doc/papers/2013/reference.bib
Modified: trunk/spark/doc/papers/2013/opensource.tex
===================================================================
--- trunk/spark/doc/papers/2013/opensource.tex 2013-03-18 20:01:56 UTC (rev 337)
+++ trunk/spark/doc/papers/2013/opensource.tex 2013-03-19 06:12:44 UTC (rev 338)
@@ -65,10 +65,23 @@
Using simulation for algorithm development and testing makes thing easier.
\todo[inline]{Background/histsory}
+
+The SimSpark project started in 2003 and was based on the building blocks of the Spark project. It was initially developed by Marco Kögler and Oliver Obst at the University of Koblenz-Landau in Koblenz, Germany.
+SimSpark was registered with SourceForge\footnote{\url{http://simspark.sourceforge.net}} in 2004 and has an established code base with development increasing year-over-year.
\cite{Boedecker2008,OR05}
-\todo[inline]{Releated work: SimRobot, Webots, V-REP, Gazebo...}
+\todo[inline]{Plugin system, core part}
+Agents communicate with the simulation server via UDP or TCP, and therefore can be implemented in any language that supports such sockets.\todo{integrated agent as well}
+Multiple software agents can participate in one simulation.
+Simulations are created within the server using the Ruby language and text-based RSG files.
+SimSpark uses the Open Dynamics Engine (ODE) for detecting collisions and for simulating rigid body dynamics. ODE allows accurate simulation of the physical properties of objects such as velocity, inertia and friction.
+
+\todo[inline]{documents, wiki}
+
+\todo[inline]{Releated work: SimRobot, Webots, V-REP, Gazebo... A table compares different simulator}
+
+
\section{Current state / development since 2008}
Because last paper about simspark was in 2008
\subsection{Architectural Changes (?)}
@@ -92,6 +105,25 @@
\todo[inline]{integrated agents (simspark)}
\todo[inline]{physics simulation engine abstraction (simspark)}
+Key Features
+\paragraph{Multi-threads Supporting}
+In modern time, computers have more than one CPU or dual cores in one CPU.
+This improve the performance greatly, but only the multi-threaded program can benefit. SimSpark has an multi-threaded running loop.
+The implementation of multi-threaded loop is based on two conditions.
+First, every SimControlNode response for different parts of the simulation, they perform one by one in the singled-threaded mode, but they can run in parallel.
+Second, there is a active scene which stores the whole simulation data in a tree.
+The physics engine and SimControlNode interact through the active scene.
+As we know, the physics computation is the most time-consuming, and the physics engine does not need to access the active scene during physics computation.
+So the physics computation and SimControlNodes can run in parallel.
+At last, we get the multithreaded simulation loop as shown in the following UML diagram. Note that the agent’s action are also delayed one cycle in the multi-threaded loop.
+\todo[inline]{multi-thread UML}
+
+\todo[inline]{ODE TBB, sander's paper}
+
+\todo[inline]{Internal/External Monitor}
+
+\todo[inline]{logfiles}
+
\section{Recent Development (Changes 2013)}
@@ -286,25 +318,41 @@
\section{Applications}
-\paragraph{RoboCup simulation league (of course)}
-- some research?
-- roboviz
+\paragraph{RoboCup Soccer Simulation League}
+In RoboCup 2004, SimSpark was successfully used for the first official competition in RoboCup Simulation 3D League. Since then, it is used as a standard research platform and test bed. By using it, simulation teams not only have designed and tested new algorithms, but also developed useful research tools based on SimSpark. Some of these tools are released as open source also. For example, roboviz\todo{brief description of roboviz}
-\paragraph{Usage in real robot teams}
-- we (NaoTH) have shared common interface with NAO
-- FUmanoid
-- education
+\paragraph{Usage for Real Robot}
+As one of the long term goals of the soccer simulation is to aim for realism the long term objective are realistic humanoid players in a physical environment.
+These players should one day challenge the champion of the most recent World Cup.
+The SimSpark is also used by teams in RoboCup Standard Platform League and Humanoid League.
+The special situation between Standard Platform League and 3D Simulation League is that both leagues use the same robot model — NAO from Aldebaran.
+So it appears to be natural to reuse the work which has already been done in Simulation League and make SimSpark usable in Standard Platform League.
+Nao Team Humboldt developed their software architecture\cite{SCPR2010} which enables their control software can run both in real NAO and simulated NAO with SimSpark. This helps them to achieve some good results in both Simulation League and Standard Platform League.
+Furthermore, Nao Team Humboldt also promotes the usage of SimSpark in the Standard Platform League by implementing its rules. \Cref{f:simspark-spl} is the snapshot of the extended SimSpark for Standard Platform League.
+
\begin{figure}
\centering
\includegraphics[width = 0.95\columnwidth]{simspark-spl}
\caption{Prototype of the extended SimSpark for Standard Platform League.
The bottom of screen are images of robot cameras.}
- \label{f:nao-models}
+ \label{f:simspark-spl}
\end{figure}
+Of course the simulator can also be extended for other leagues by adding new robot models.
+For example, in RoboCup Humanoid Kid Size League, FUmanoid\cite{Donat2012} uses
+SimSpark to perform multi-level testing methods for archiving higher
+quality in each module of their robot control software and unlink the
+module test from the robotic hardware.
+
+
\section{Conclusion and Future Work}
+\todo[inline]{Other physic engine, Bullet}
+\todo[inline]{better GUI}
+
+\section*{Acknowledgments}
+
\bibliographystyle{splncs03}
\bibliography{reference}
\end{document}
Modified: trunk/spark/doc/papers/2013/reference.bib
===================================================================
--- trunk/spark/doc/papers/2013/reference.bib 2013-03-18 20:01:56 UTC (rev 337)
+++ trunk/spark/doc/papers/2013/reference.bib 2013-03-19 06:12:44 UTC (rev 338)
@@ -23,6 +23,27 @@
timestamp = {2010.08.21}
}
+@MASTERSTHESIS{Donat2012,
+ author = {Heiko Donat},
+ title = {Evaluation of Simulators for Humanoid Soccer Playing Robots and Integration
+ in an Existing System},
+ school = {Department of Computer Science, Freien Universit\"at Berlin},
+ year = {2012},
+ type = {Bachelor Thesis},
+ owner = {xu},
+ timestamp = {2013.03.17}
+}
+
+@INPROCEEDINGS{SCPR2010,
+ author = {Heinrich Mellmann and Yuan Xu and Thomas Krause and Florian Holzhauer},
+ title = {NaoTH Software Architecture for an Autonomous Agent},
+ booktitle = {International Workshop on Standards and Common Platforms for Robotics
+ (SCPR 2010)},
+ year = {2010},
+ address = {Darmstadt},
+ month = {November}
+}
+
@ARTICLE{OR05,
author = {Oliver Obst and Markus Rollmann},
title = {{SPARK} -- {A} {G}eneric {S}imulator for {P}hysical {M}ultiagent
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <yx...@us...> - 2013-03-25 08:55:32
|
Revision: 339
http://simspark.svn.sourceforge.net/simspark/?rev=339&view=rev
Author: yxu
Date: 2013-03-25 08:55:24 +0000 (Mon, 25 Mar 2013)
Log Message:
-----------
Merge branch 'open-source-paper'
* open-source-paper:
smaller figures
history
draft multi-thread
Modified Paths:
--------------
trunk/spark/doc/papers/2013/joint-temp-LKneePitch.tikz
trunk/spark/doc/papers/2013/joint.tikz
trunk/spark/doc/papers/2013/opensource.tex
trunk/spark/doc/papers/2013/reference.bib
Modified: trunk/spark/doc/papers/2013/joint-temp-LKneePitch.tikz
===================================================================
--- trunk/spark/doc/papers/2013/joint-temp-LKneePitch.tikz 2013-03-19 06:12:44 UTC (rev 338)
+++ trunk/spark/doc/papers/2013/joint-temp-LKneePitch.tikz 2013-03-25 08:55:24 UTC (rev 339)
@@ -3745,7 +3745,7 @@
1335.885 77.0
1336.552 77.0
};
-\addlegendentry{temperature of real robot}
+\addlegendentry{real robot}
\addplot[every mark/.append style={solid},
red, dashed, mark=none, thick, line legend] table[x=x, y=y] {
x y
@@ -5605,7 +5605,7 @@
1335.885 77.2528301182
1336.552 77.2375827936
};
-\addlegendentry{temperature of simulated robot}
+\addlegendentry{simulated robot}
\addlegendimage{/pgfplots/refstyle=current, green!30!white, fill=green!30!white}\addlegendentry{electric current}
\end{axis}
\end{tikzpicture}
Modified: trunk/spark/doc/papers/2013/joint.tikz
===================================================================
--- trunk/spark/doc/papers/2013/joint.tikz 2013-03-19 06:12:44 UTC (rev 338)
+++ trunk/spark/doc/papers/2013/joint.tikz 2013-03-25 08:55:24 UTC (rev 339)
@@ -2,33 +2,33 @@
\tikzstyle{module}=[draw, minimum height=1cm, minimum width=2cm]
\node[module] (sc) {\shortstack{Stiffness\\ Control}};
- \draw[<-] (sc) -- node[at end, above]{$k_s$} ++(-2,0);
+ \draw[<-] (sc) -- node[at end, above]{$k_s$} ++(-1.6,0);
\node[module] (bl) at (3,0) {\shortstack{Temperature\\ Regulation}};
\draw[->] (sc) -- node[above]{$\tau_{max}$} (bl);
- \node[module] (ode) at (6,1) {\shortstack{Simulation\\ Engine}};
- \draw[->] (bl.east) -- ++(0.3,0) |- node[right, near start]{$\tau_m$}
+ \node[module] (ode) at (5.7,0.6) {\shortstack{Simulation\\ Engine}};
+ \draw[->] (bl.east) -- ++(0.1,0) |- node[right, near start]{$\tau_m$}
($(ode.north west)!0.7!(ode.south west)$);
- \node[module] (sl) at (1.5,2) {\shortstack{Speed\\ Limitation}};
- \draw[<-] (sl) -- node[above, at end]{$\dot{\theta_r}$} ++(-3.5,0);
- \draw[->] (sl.east) -- ++(1.9,0) |- node[right, near start]{$\dot{\theta_e}$}
+ \node[module] (sl) at (1.5,1.2) {\shortstack{Speed\\ Limitation}};
+ \draw[<-] (sl) -- node[above, at end]{$\dot{\theta_r}$} ++(-3.1,0);
+ \draw[->] (sl.east) -- ++(1.6,0) |- node[right, near start]{$\dot{\theta_e}$}
($(ode.north west)!0.3!(ode.south west)$);
\draw[->] ($(ode.north east)!0.3!(ode.south east)$) -- node[above,
- at end]{$\theta$} ++(6,0);
+ at end]{$\theta$} ++(3.5,0);
- \node[module] (ps) at (9.5, 0) {\shortstack{Power\\ Consumption}};
- \draw[->] ($(ode.north east)!0.7!(ode.south east)$) -- ++(0.3,0) |-
+ \node[module] (ps) at (8.6, 0) {\shortstack{Power\\ Consumption}};
+ \draw[->] ($(ode.north east)!0.7!(ode.south east)$) -- ++(0.1,0) |-
node[right, near start] {$\tau, \dot{\theta}$} (ps);
- \draw[->] (ps) -- ++(0,-1) -| node[above, near start]{$\Delta{Q}^+$}
+ \draw[->] ($(ps.south east)!0.7!(ps.south west)$) -- ++(0,-0.2) -| node[above, near start]{$\Delta{Q}^+$}
(bl);
- \node[module] (bat) at (6, -2.5) {Battery};
- \draw[->] (ps) -- ++(2, 0) |- node[above, near end]{$E$} (bat);
+ \node[module] (bat) at (6, -1.7) {Battery};
+ \draw[->] ($(ps.south east)!0.3!(ps.south west)$) |- node[above, near end]{$E$} (bat);
\draw[->] (bat) -| node[above, near start] {On/Off} (sc);
- \draw[dashed] (-1.3,-1.5) rectangle (12,3) node[anchor=north east] {Servo Motor Model};
+ \draw[dashed] (-1.3,-1.1) rectangle (9.9,1.8) node[anchor=north east] {Servo Motor Model};
\end{tikzpicture}
\ No newline at end of file
Modified: trunk/spark/doc/papers/2013/opensource.tex
===================================================================
--- trunk/spark/doc/papers/2013/opensource.tex 2013-03-19 06:12:44 UTC (rev 338)
+++ trunk/spark/doc/papers/2013/opensource.tex 2013-03-25 08:55:24 UTC (rev 339)
@@ -5,6 +5,7 @@
\usepackage{textcomp} % for \textdegree
\usepackage[hidelinks]{hyperref}
\usepackage{cleveref}
+\crefname{figure}{Fig.}{Fig.}
\usepackage{xstring}
\usepackage{booktabs}
\usepackage{tikz}
@@ -64,26 +65,31 @@
This is especially true in the research of multi-robots systems in areas such as RoboCup.
Using simulation for algorithm development and testing makes thing easier.
-\todo[inline]{Background/histsory}
+% \paragraph{History}
+SimSpark was initially developed by Marco Kögler and Oliver Obst at the University of Koblenz-Landau in Koblenz, Germany\cite{OR05}.
+The project was registered as open source project in SourceForge\footnote{\url{http://simspark.sourceforge.net}} in 2004, it has an established code base with development increasing year-over-year\cite{Boedecker2008,usermanual}.
-The SimSpark project started in 2003 and was based on the building blocks of the Spark project. It was initially developed by Marco Kögler and Oliver Obst at the University of Koblenz-Landau in Koblenz, Germany.
-SimSpark was registered with SourceForge\footnote{\url{http://simspark.sourceforge.net}} in 2004 and has an established code base with development increasing year-over-year.
-\cite{Boedecker2008,OR05}
+
\todo[inline]{Plugin system, core part}
+In comparison to specialized simulators, users can create new simulations by using a scene description language.
+
+It served from the beginning as a test bed and a guide for essential new features that were added to the simulator during development. However changes to the simulator core were never customized for the soccer simulation. Instead generic simulator services were implemented with all soccer specific details contained in a set of plugins.
+
Agents communicate with the simulation server via UDP or TCP, and therefore can be implemented in any language that supports such sockets.\todo{integrated agent as well}
Multiple software agents can participate in one simulation.
Simulations are created within the server using the Ruby language and text-based RSG files.
SimSpark uses the Open Dynamics Engine (ODE) for detecting collisions and for simulating rigid body dynamics. ODE allows accurate simulation of the physical properties of objects such as velocity, inertia and friction.
-\todo[inline]{documents, wiki}
+\todo[inline]{Releated work: SimRobot, Webots, V-REP, Gazebo...}
-\todo[inline]{Releated work: SimRobot, Webots, V-REP, Gazebo... A table compares different simulator}
-
\section{Current state / development since 2008}
Because last paper about simspark was in 2008
+
+The soccer simulation for this tournament was developed in parallel with the SimSpark simulator. In its initial version players were modeled as spheres in a physical three dimensional world. Since then SimSpark grew considerably and now supports humanoid players with articulated bodies.
+
\subsection{Architectural Changes (?)}
\todo[inline]{separation of simspark and rcssserver3d}
\todo[inline]{Cmake migration?}
@@ -101,22 +107,23 @@
\todo[inline]{soccer rules (referee) (rcssserver3d)}
\todo[inline]{bigger fields and more robots (rcssserver3d)}
\todo[inline]{sync mode (simspark)}
-\todo[inline]{multi-threaded (simulation engine, agent controls) (simspark)}
\todo[inline]{integrated agents (simspark)}
\todo[inline]{physics simulation engine abstraction (simspark)}
-Key Features
-\paragraph{Multi-threads Supporting}
-In modern time, computers have more than one CPU or dual cores in one CPU.
-This improve the performance greatly, but only the multi-threaded program can benefit. SimSpark has an multi-threaded running loop.
-The implementation of multi-threaded loop is based on two conditions.
-First, every SimControlNode response for different parts of the simulation, they perform one by one in the singled-threaded mode, but they can run in parallel.
-Second, there is a active scene which stores the whole simulation data in a tree.
-The physics engine and SimControlNode interact through the active scene.
+\paragraph{Multi-threads Supporting\todo{agent controls}}
+In modern time, computers have a CUP with multi-cores or even multi-CPUs.
+This improves the performance greatly, but only the multi-threaded program can benefit.
+One great feature of SimSpark is switching between single thread mode and multi-threads
+mode. The multi-threads mode can improve the performance in computer with multi-cores CPU, but the single thread mode is also useful for developing the simulator.
+
+The implementation of multi-threads loop is based on two conditions.
+First, different tasks are assigned to different \textit{SimControlNode}s in SimSpark.
+For example, \textit{AgentControl} is a node that manages the communication with agents.
+For each simulation cycle, \textit{SimControlNode}s are executed one by one in the single thread mode, but they can run in parallel.
+Second, all data of simulation state is stored in a tree called \textit{active scene},
+the physics engine and \textit{SimControlNode}s interact through the \textit{active scene}.
As we know, the physics computation is the most time-consuming, and the physics engine does not need to access the active scene during physics computation.
-So the physics computation and SimControlNodes can run in parallel.
-At last, we get the multithreaded simulation loop as shown in the following UML diagram. Note that the agent’s action are also delayed one cycle in the multi-threaded loop.
-\todo[inline]{multi-thread UML}
+So the physics computation and \textit{SimControlNode}s can run in parallel.\todo[color=green]{UML?}\todo[color=yellow]{results of performance improvement, any benchmark?}
\todo[inline]{ODE TBB, sander's paper}
@@ -124,10 +131,12 @@
\todo[inline]{logfiles}
-\section{Recent Development (Changes 2013)}
+\section{Experimental Features}
+These features are experimental, they (probably) will be used in RoboCup 2013 for the first time. (Some of them are still under the development)
-
\subsection{Realistic Motor}
+\todo{motivation: my email...}
+\todo{shorter}
NAO robot has twenty-one motor joints as its actuators.
The simple motor model is one reason for the unrealistic simulation results.
The ODE provides a simple model of real life servos.
@@ -204,12 +213,24 @@
power consumption, the energy consumed by devices other than motors,
e.g. mainboard, CPU, camera, etc. has to be added. It is the power
consumption of the robot in an idle state (all motors are off), and measured to be 33 W.
+
\begin{figure}
\centering
- \inputtikz{battery}
- \caption{Power consumption of the real and the simulated robot in action.
- The electric current is the summary of all motors.}
- \label{fig:battery}
+ \begin{minipage}{0.49\columnwidth}
+ \centering
+ \pgfplotsset{width=0.9\columnwidth,height=7cm}
+ \inputtikz{battery}
+ \caption{Power consumption of the real and the simulated robot in action.
+ The electric current is the summary of all motors.}
+ \label{fig:battery}
+ \end{minipage}\hfill{}
+ \begin{minipage}{0.49\columnwidth}
+ \centering
+ \pgfplotsset{width=0.9\columnwidth,height=7cm}
+ \inputtikz{joint-temp-LKneePitch}
+ \caption{The temperature of the (knee pitch) motor in the simulation and the real robot. The green background is the electric current in the real robot.}
+ \label{fig:joint-temperature}
+ \end{minipage}
\end{figure}
\paragraph{Temperature Regulation}
@@ -264,13 +285,6 @@
\end{table}
After determining the parameters in the \cref{eq:motor-temp}, we can use this model to simulate motor temperature. In \Cref{fig:joint-temperature}, the simulated temperature is compared with data from the real robot.
-\begin{figure}
- \centering
- \pgfplotsset{width=0.88\columnwidth}
- \inputtikz{joint-temp-LKneePitch}
- \caption{The temperature of the (knee pitch) motor in the simulation and the real robot. The green background is the electric current in the real robot. The result shows the simulated temperature is very close to the values of the real robot.}
- \label{fig:joint-temperature}
-\end{figure}
The whole process of joint simulation is summarized in
\Cref{fig:joint}: stiffness $k_s$ is simulated by setting the maximum torque
@@ -308,7 +322,7 @@
separate robot models. To better support games with heterogeneous robots, we have
added the support for parametric models to simspark. Therefore, it is possible to
define models in which a number of parameters are variables and can have different
-values for different robot variations. When you want to load such a model, you shold
+values for different robot variations.\todo[color=green]{which parameters? for example} When you want to load such a model, you shold
specify which type of that robot is needed and its parameters are replaced in the
parametric model and the model is created.
@@ -319,7 +333,7 @@
\section{Applications}
\paragraph{RoboCup Soccer Simulation League}
-In RoboCup 2004, SimSpark was successfully used for the first official competition in RoboCup Simulation 3D League. Since then, it is used as a standard research platform and test bed. By using it, simulation teams not only have designed and tested new algorithms, but also developed useful research tools based on SimSpark. Some of these tools are released as open source also. For example, roboviz\todo{brief description of roboviz}
+In RoboCup 2004, SimSpark was successfully used for the first official competition in RoboCup Simulation 3D League. Since then, it is used as a standard research platform and test bed\todo{How many teams in last RoboCup?}. By using it, simulation teams not only have designed and tested new algorithms, but also developed useful research tools based on SimSpark. Some of these tools are released as open source also. For example, roboviz\todo{brief description of roboviz}
\paragraph{Usage for Real Robot}
As one of the long term goals of the soccer simulation is to aim for realism the long term objective are realistic humanoid players in a physical environment.
@@ -333,7 +347,7 @@
\begin{figure}
\centering
- \includegraphics[width = 0.95\columnwidth]{simspark-spl}
+ \includegraphics[width = 0.75\columnwidth]{simspark-spl}
\caption{Prototype of the extended SimSpark for Standard Platform League.
The bottom of screen are images of robot cameras.}
\label{f:simspark-spl}
@@ -348,6 +362,8 @@
\section{Conclusion and Future Work}
+SimSpark is a powerful tool to state different multi-agent research questions.
+
\todo[inline]{Other physic engine, Bullet}
\todo[inline]{better GUI}
Modified: trunk/spark/doc/papers/2013/reference.bib
===================================================================
--- trunk/spark/doc/papers/2013/reference.bib 2013-03-19 06:12:44 UTC (rev 338)
+++ trunk/spark/doc/papers/2013/reference.bib 2013-03-25 08:55:24 UTC (rev 339)
@@ -23,6 +23,17 @@
timestamp = {2010.08.21}
}
+@MANUAL{usermanual,
+ title = {SimSpark User's Manual},
+ author = {Joschka Boedecker and Klaus Dorer and Markus Rollmann and Yuan Xu
+ and Feng Xue and Marian Buchta and Hedayat Vatankhah and Stefan Glaser},
+ edition = {1.3},
+ month = {August},
+ year = {2010},
+ owner = {xu},
+ timestamp = {2013.03.19}
+}
+
@MASTERSTHESIS{Donat2012,
author = {Heiko Donat},
title = {Evaluation of Simulators for Humanoid Soccer Playing Robots and Integration
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <yx...@us...> - 2013-03-25 10:14:44
|
Revision: 340
http://simspark.svn.sourceforge.net/simspark/?rev=340&view=rev
Author: yxu
Date: 2013-03-25 10:14:37 +0000 (Mon, 25 Mar 2013)
Log Message:
-----------
Merge branch 'open-source-paper'
* open-source-paper:
roboviz
notes
Modified Paths:
--------------
trunk/spark/doc/papers/2013/opensource.tex
trunk/spark/doc/papers/2013/reference.bib
Modified: trunk/spark/doc/papers/2013/opensource.tex
===================================================================
--- trunk/spark/doc/papers/2013/opensource.tex 2013-03-25 08:55:24 UTC (rev 339)
+++ trunk/spark/doc/papers/2013/opensource.tex 2013-03-25 10:14:37 UTC (rev 340)
@@ -69,13 +69,9 @@
SimSpark was initially developed by Marco Kögler and Oliver Obst at the University of Koblenz-Landau in Koblenz, Germany\cite{OR05}.
The project was registered as open source project in SourceForge\footnote{\url{http://simspark.sourceforge.net}} in 2004, it has an established code base with development increasing year-over-year\cite{Boedecker2008,usermanual}.
-
-
\todo[inline]{Plugin system, core part}
In comparison to specialized simulators, users can create new simulations by using a scene description language.
-It served from the beginning as a test bed and a guide for essential new features that were added to the simulator during development. However changes to the simulator core were never customized for the soccer simulation. Instead generic simulator services were implemented with all soccer specific details contained in a set of plugins.
-
Agents communicate with the simulation server via UDP or TCP, and therefore can be implemented in any language that supports such sockets.\todo{integrated agent as well}
Multiple software agents can participate in one simulation.
@@ -91,7 +87,10 @@
The soccer simulation for this tournament was developed in parallel with the SimSpark simulator. In its initial version players were modeled as spheres in a physical three dimensional world. Since then SimSpark grew considerably and now supports humanoid players with articulated bodies.
\subsection{Architectural Changes (?)}
-\todo[inline]{separation of simspark and rcssserver3d}
+\todo[inline]{separation of simspark and rcssserver3d}\todo{Hedayat Vatankhah:
+Architecture Enhancements Proposal for Soccer Simulation Server 3D}
+It served from the beginning as a test bed and a guide for essential new features that were added to the simulator during development. However changes to the simulator core were never customized for the soccer simulation. Instead generic simulator services were implemented with all soccer specific details contained in a set of plugins.
+
\todo[inline]{Cmake migration?}
\todo[inline]{windows support (mingw32,VC)}
@@ -125,8 +124,13 @@
As we know, the physics computation is the most time-consuming, and the physics engine does not need to access the active scene during physics computation.
So the physics computation and \textit{SimControlNode}s can run in parallel.\todo[color=green]{UML?}\todo[color=yellow]{results of performance improvement, any benchmark?}
-\todo[inline]{ODE TBB, sander's paper}
+\todo[inline]{
+Sander van Dijk and Ubbo Visser
+Proposal: Boosting the 3D SSL Simulator
+Increase Research Possibilities in the RC SSL Community
+ODE TBB, ??sander's paper -- where??}\footnote{\url{http://www.robocup.org/2011/03/robocup-federation-call-for-project-proposals-2/}}
+
\todo[inline]{Internal/External Monitor}
\todo[inline]{logfiles}
@@ -333,7 +337,10 @@
\section{Applications}
\paragraph{RoboCup Soccer Simulation League}
-In RoboCup 2004, SimSpark was successfully used for the first official competition in RoboCup Simulation 3D League. Since then, it is used as a standard research platform and test bed\todo{How many teams in last RoboCup?}. By using it, simulation teams not only have designed and tested new algorithms, but also developed useful research tools based on SimSpark. Some of these tools are released as open source also. For example, roboviz\todo{brief description of roboviz}
+In RoboCup 2004, SimSpark was successfully used for the first official competition in RoboCup Simulation 3D League. Since then, it is used as a standard research platform and test bed\todo{How many teams in last RoboCup?}. By using it, simulation teams not only have designed and tested new algorithms, but also developed useful research tools based on SimSpark. Some of these tools are also released as open source.
+For example, RoboViz\cite{Stoecker2012} is designed to assess and develop agent behaviors in SimSpark,
+it facilitates the real-time visualization of agents running concurrently on the SimSpark simulator,
+and provides higher-level analysis and visualization of agent behaviors.
\paragraph{Usage for Real Robot}
As one of the long term goals of the soccer simulation is to aim for realism the long term objective are realistic humanoid players in a physical environment.
Modified: trunk/spark/doc/papers/2013/reference.bib
===================================================================
--- trunk/spark/doc/papers/2013/reference.bib 2013-03-25 08:55:24 UTC (rev 339)
+++ trunk/spark/doc/papers/2013/reference.bib 2013-03-25 10:14:37 UTC (rev 340)
@@ -77,3 +77,12 @@
RoboCup Simulation League competition. }
}
+@INPROCEEDINGS{Stoecker2012,
+ author = {Justin Stoecker and Ubbo Visser},
+ title = {RoboViz: Programmable Visualization for Simulated Soccer},
+ booktitle = {RoboCup 2011: Robot Soccer World Cup XV},
+ year = {2012},
+ owner = {xu},
+ timestamp = {2013.03.25}
+}
+
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <he...@us...> - 2013-03-28 13:15:06
|
Revision: 342
http://simspark.svn.sourceforge.net/simspark/?rev=342&view=rev
Author: hedayat
Date: 2013-03-28 13:14:58 +0000 (Thu, 28 Mar 2013)
Log Message:
-----------
Add some content for agent proxies section. Also some notes about rcssserver3d/simspark separation.
Modified Paths:
--------------
trunk/spark/doc/papers/2013/opensource.tex
trunk/spark/doc/papers/2013/reference.bib
Modified: trunk/spark/doc/papers/2013/opensource.tex
===================================================================
--- trunk/spark/doc/papers/2013/opensource.tex 2013-03-26 11:40:17 UTC (rev 341)
+++ trunk/spark/doc/papers/2013/opensource.tex 2013-03-28 13:14:58 UTC (rev 342)
@@ -84,7 +84,8 @@
In comparison to specialized simulators, users can create new simulations by using a scene description language.
-Agents communicate with the simulation server via UDP or TCP, and therefore can be implemented in any language that supports such sockets.\todo{integrated agent as well}
+Agents communicate with the simulation server via UDP or TCP, and therefore can be implemented in any language that supports such sockets.
+\todo{integrated agent as well}
Multiple software agents can participate in one simulation.
Simulations are created within the server using the Ruby language and text-based RSG files.
@@ -93,18 +94,25 @@
The soccer simulation for this tournament was developed in parallel with the SimSpark simulator. In its initial version players were modeled as spheres in a physical three dimensional world. Since then SimSpark grew considerably and now supports humanoid players with articulated bodies.
% \subsection{Architectural Changes (?)}
-\todo[inline]{separation of simspark and rcssserver3d}\todo{Hedayat Vatankhah:
-Architecture Enhancements Proposal for Soccer Simulation Server 3D}
-It served from the beginning as a test bed and a guide for essential new features that were added to the simulator during development. However changes to the simulator core were never customized for the soccer simulation. Instead generic simulator services were implemented with all soccer specific details contained in a set of plugins.
+It served from the beginning as a test bed and a guide for essential new features that were added to the simulator during development. However changes to the simulator core were never customized for the soccer simulation. Instead generic simulator services were implemented with all soccer specific details contained in a set of plugins and applications. Until 2008, soccer simulation and SimSpark simulator were developed and released as a single project called rcssserver3d, but it was already decided that they should be separated
+to make the separation more visible for both users new developers.
+In late 2008, the separation happened with the migration of sources from CVS repository
+at \url{http://sserver.sourceforge.net} to SimSpark's project Subversion repository at
+\url{http://simspark.sourceforge.net}. As part of this process, the project was broken
+to two main projects (SimSpark simulator and RCSSServer3D soccer simulation software)
+and two auxiliary projects (RSGEdit and simspark-utilities). Also, simspark binary was
+renamed to rcssserver3d to make it clear that it runs soccer simulation rather than a
+generic simulation environment.
-\todo[inline]{Cmake migration?}
-\todo[inline]{windows support (mingw32,VC)}
+SimSpark was never a single-platform project, but it practically didn't support
+Windows. In recent years, Windows support was added after migration from Autotools
+to CMake, and windows installers are now released.
\section{Spark}
\label{s:spark}
\subsection{New Sensors}
- ACC
- - FSR
+ - FRP (Force Resistance Perceptor)
- Gyro
- Restrict Vision
-- Line perceptions
@@ -343,9 +351,38 @@
parametric model and the model is created.
\subsection{Agent Proxies}
+Initially, SimSpark used SPADES\cite{riley2003spades} for managing external agents. It
+managed the simulation time and the time spend in agents for thinking. Later it was
+dropped because of its complexities and agents communicated with the server directly.
+The cycle duration was managed by the server without considering agents and the network
+latency. Therefore, if agents were unable to deliver their commands to the server in a
+cycle because of network latency, their commands were executed by the simulator
+in the next simulation cycle. As the number of soccer players in soccer simulation
+increased, this problem become more apparent.
-\subsection{Player Integration??}
+To solve this problem, the concept of agent proxies were proposed. Agent proxies
+run on the client machines were agents will be running, and they are responsible for
+communicating with the server. Agents communicate with the proxies instead of
+communicating directly with the simulator. In this model, the cycle time is managed
+by the proxies on the client side, and they communicate with the simulator in Sync Mode.
+Therefore, the simulator waits for all proxies to signal the end of a cycle and
+then proceeds with the next cycle. This model ensures that agents can use the allowed
+cycle time to think in a cycle when new information is delivered to them.
+This model is not ideal because the agents can have some spare time if network latency
+occures, but it is better, more predictable and more fair than the current model. Also,
+no new information is arrived to agents in that spare time and they cannot send new
+commands for that cycle. Hopefully, by using a new binary network protocol the network
+traffic and therefore the latency will be reduced considerably.
+
+Currently, an initial version of agent proxies is under development outside simspark
+project using Java.
+
+\subsection{Integration With Existing Robotic Frameworks}
+\todo{Hedayat Vatankhah:Architecture Enhancements Proposal for Soccer
+Simulation Server 3D}
+
+
\section{Applications}
\label{s:application}
\paragraph{RoboCup Soccer Simulation League}
Modified: trunk/spark/doc/papers/2013/reference.bib
===================================================================
--- trunk/spark/doc/papers/2013/reference.bib 2013-03-26 11:40:17 UTC (rev 341)
+++ trunk/spark/doc/papers/2013/reference.bib 2013-03-28 13:14:58 UTC (rev 342)
@@ -86,3 +86,12 @@
timestamp = {2013.03.25}
}
+@article{riley2003spades,
+ title={SPADES: a system for parallel-agent, discrete-event simulation},
+ author={Riley, Patrick},
+ journal={AI Magazine},
+ volume={24},
+ number={2},
+ pages={41},
+ year={2003}
+}
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <yx...@us...> - 2013-03-29 20:19:02
|
Revision: 345
http://simspark.svn.sourceforge.net/simspark/?rev=345&view=rev
Author: yxu
Date: 2013-03-29 20:18:52 +0000 (Fri, 29 Mar 2013)
Log Message:
-----------
Merge branch 'open-source-paper'
* open-source-paper:
nao model
spark section
begin Spark
short realistic motor
clean
draft introduction
Modified Paths:
--------------
trunk/spark/doc/papers/2013/joint-temp-LKneePitch.tikz
trunk/spark/doc/papers/2013/opensource.tex
trunk/spark/doc/papers/2013/reference.bib
Modified: trunk/spark/doc/papers/2013/joint-temp-LKneePitch.tikz
===================================================================
--- trunk/spark/doc/papers/2013/joint-temp-LKneePitch.tikz 2013-03-29 19:47:49 UTC (rev 344)
+++ trunk/spark/doc/papers/2013/joint-temp-LKneePitch.tikz 2013-03-29 20:18:52 UTC (rev 345)
@@ -1884,7 +1884,7 @@
enlarge x limits=false,
legend pos=north west,
xlabel={time (s)},
-ylabel={temperature (\textdegree{}C)},
+ylabel={temperature ($^{\circ}$C)},
]
\addplot[every mark/.append style={solid},
black, solid, mark=none, line legend] table[x=x, y=y] {
Modified: trunk/spark/doc/papers/2013/opensource.tex
===================================================================
--- trunk/spark/doc/papers/2013/opensource.tex 2013-03-29 19:47:49 UTC (rev 344)
+++ trunk/spark/doc/papers/2013/opensource.tex 2013-03-29 20:18:52 UTC (rev 345)
@@ -2,7 +2,6 @@
\usepackage[utf8]{inputenc}
\usepackage{todonotes}
\usepackage{amsmath}
-\usepackage{textcomp} % for \textdegree
\usepackage[hidelinks]{hyperref}
\usepackage{cleveref}
\crefname{figure}{Fig.}{Fig.}
@@ -25,6 +24,11 @@
\input{#1.tikz}
}
+\renewcommand{\textfraction}{0.15}
+\renewcommand{\topfraction}{0.85}
+\renewcommand{\bottomfraction}{0.65}
+\renewcommand{\floatpagefraction}{0.60}
+
\graphicspath{{fig/}}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{document}
@@ -64,45 +68,34 @@
\section{Introduction}
The development on robots may be severely limited by the constrained resources.
-This is especially true in the research of multi-robots systems in areas such as RoboCup.
+This is especially true in the research of multi-robot systems in areas such as RoboCup.
Using simulation for algorithm development and testing makes thing easier.
% \paragraph{History}
\textit{SimSpark}, a multi-robot simulator based on the generic components of the Spark\cite{OR05} physical multi-agent simulation system, has been used in the RoboCup Soccer Simulation League since 2004.
-The project was registered as open source project in SourceForge\footnote{\url{http://simspark.sourceforge.net}} in 2004, it has an established code base with development increasing year-over-year.
+The project was registered as open source project in SourceForge in 2004, it has an established code base with development increasing year-over-year.
As the result, RoboCup soccer simulations have changed significantly over the years, going from rather abstract agent representations to more and more realistic humanoid robot games\cite{Boedecker2008,usermanual}.
Thanks to the flexibility of the Spark system, these transitions were achieved with little changes to the simulator's core architecture.
-In this paper we describe the recent development of \textit{SimSpark} project, which make the \textit{SimSpark} possible to simulate 11 vs. 11 humanoid robot soccer games in real time\todo{is it real time in RoboCup? ``Almost! It'll be slower if there are many collisions''}.
-In section \ref{s:overview}, we will give an overview of \textit{SimSpark} project since 2008. After that, we will describe the development in core module -- names \textit{Spark} in section \ref{s:spark}. In section \ref{s:rcssserver3d}, we will give the implementation of RoboCup 3D Soccer Simulator -- \textit{RCSSServer3D}. We will introduce some ongoing work for RoboCup 2013 in
-section \ref{s:ongoing}. Furthermore, we will discuss the application of \textit{SimSpark} not only in simulation league but also other leagues with real robots in section \ref{s:application}. Finally, we will outline future development plans in section \ref{s:conclusion} .
+In this paper we describe the recent development of \textit{SimSpark} project, which make the \textit{SimSpark} possible to simulate 11 vs. 11 humanoid robot soccer games in real time\todo{is it real time in RoboCup 2012?}.
+In section \ref{s:overview}, we will give an overview of \textit{SimSpark} project since 2008. After that, we will describe the development of the \textit{Spark} simulation platform in section \ref{s:spark}.
+In section \ref{s:rcssserver3d}, we will briefly describe the implementation of RoboCup 3D Soccer Simulator -- \textit{RCSSServer3D}.
+We will introduce some new features for RoboCup 2013 in section \ref{s:ongoing}.
+Furthermore, we will discuss the application of \textit{SimSpark} not only in simulation league but also other leagues with real robots in section \ref{s:application}.
+Finally, we will outline future development plans in section \ref{s:conclusion} .
\todo[inline,color=gray]{Releated work: SimRobot, Webots, V-REP, Gazebo...}
\section{Project Overview}
\label{s:overview}
-Because last paper about simspark was in 2008
-In comparison to specialized simulators, users can create new simulations by using a scene description language.
-
-Agents communicate with the simulation server via UDP or TCP, and therefore can be implemented in any language that supports such sockets.
-It is also possible to use integrated agents, which are programmed as part of the
-simulator; but it is mainly for debugging purposes.
-Multiple software agents can participate in one simulation.
-
-Simulations are created within the server using the Ruby language and text-based RSG files.
-SimSpark uses the Open Dynamics Engine (ODE) for detecting collisions and for simulating rigid body dynamics. ODE allows accurate simulation of the physical properties of objects such as velocity, inertia and friction.
-
-The soccer simulation for this tournament was developed in parallel with the SimSpark simulator. In its initial version players were modeled as spheres in a physical three dimensional world. Since then SimSpark grew considerably and now supports humanoid players with articulated bodies.
-
-% \subsection{Architectural Changes (?)}
-It served from the beginning as a test bed and a guide for essential new features that were added to the simulator during development. However changes to the simulator core were never customized for the soccer simulation. Instead generic simulator services were implemented with all soccer specific details contained in a set of plugins and applications. Until 2008, soccer simulation and SimSpark simulator were developed and released as a single project called rcssserver3d, but it was already decided that they should be separated
-to make the separation more visible for both users new developers.
+Until 2008, soccer simulation and SimSpark simulator were developed and released as a single project called rcssserver3d, but it was already decided that they should be separated
+to make the separation more visible for both users and developers.
In late 2008, the separation happened with the migration of sources from CVS repository
at \url{http://sserver.sourceforge.net} to SimSpark's project Subversion repository at
\url{http://simspark.sourceforge.net}. As part of this process, the project was broken
-to two main projects (SimSpark simulator and RCSSServer3D soccer simulation software)
+to two main projects (Spark simulation platform and RCSSServer3D soccer simulation server)
and two auxiliary projects (RSGEdit and simspark-utilities). Also, simspark binary was
renamed to rcssserver3d to make it clear that it runs soccer simulation rather than a
generic simulation environment.
@@ -113,62 +106,24 @@
\section{Spark}
\label{s:spark}
-\paragraph{New Sensors}
- - ACC
- - FRP (Force Resistance Perceptor)
- - Gyro
- - Restrict Vision
- -- Line perceptions
- -- camera (image)
+As a generic simulation environment, Spark provides a rich set of features to create, debug and modify multi-robot simulation.
+It has three main components, including the simulation engine, the object and memory management system, and the physics engine. Details about architecture and concepts of Spark have been described in \cite{Boedecker2008,OR05}.
+In this section, we describe the necessary changes for simulating 11 vs. 11 humanoid robot soccer game.
+However changes to the simulator core were never customized for the soccer simulation.
+First, a set of sensors of humanoid robot are implemented as plugins. Second, multi-threads supporting takes advantage of multi-cores in modern CPU to be able to run in real time.
-\paragraph{Integrated Agents}
-Since the agents run as separate processes than the simulator, it was not possible to
-use debugging tools to debug agents while the server was running because if the
-agent process was paused, the simulator continued the simulation which would usually
-lead to unwanted results. For example, if the agent was paused in the middle of walking
-in an unstable state, it would fall on the ground. Therefore, support for integrated
-agents have been added to the simulator so that it is possible to program and run an
-agent as a part of the simulator process. It also makes development of simple agents
-easier since there is no need to bother about agent/server communication.
+\paragraph{Sensor Plugins}
+Sensors of a robot allows awareness of the robot's state and the environment.
+Humanoid robots like the NAO usually have many different sensors installed.
+We have implemented new plugins to simulate sensors of humanoid robots.
+Some of the sensors delivers information from physics engine, such as joint position, gyro, accelerometer, and force resistance. Furthermore, lines can be sensed by virtual vision.
+Additionally, a more realistic camera which delivers images rendered via OpenGL hardware accelerated offscreen buffers is implemented. Details of these sensors can be found in \cite{usermanual}.
-While support for integrated agents was mainly added to facilitate debugging, the
-addition of sync mode is a better solution for this purpose which is introduced below.
-
-\paragraph{Sync Mode}
-As the number of agents increase, the simulator puts a lot more load on CPU. As a
-result, it will be more difficult to run the agents on the same machine as the simulator
-since they will not get enough processing time in each cycle. This will make it
-difficult or almost impossible to develop and run multi-agent systems on a single
-machine or on older machines. To overcome this issue, a new running mode called
-``Sync Mode'' has been added to the simulator. When it is running in the sync mode,
-the cycles will not be advanced automatically. Instead, the simulator will proceed
-to the next cycle when all connected agents send a ``(sync)'' command indicating that
-they are finished with this cycle. Therefore, agents doesn't need to catch up with the
-simulator and it will wait for them as much as needed.
-
-Not only this feature will make it possible to experiment with the simulator on
-slower systems, but also it will make debugging much easier even on multi-agent setups.
-For instance, if an agent is paused in a debugger tool, the simulator will not proceed
-to the next cycle and also all other agents have to wait for the next cycle.
-
-\paragraph{Support for Other Physics Engines}
-SimSpark was initially built around ODE physics engine. However, it turned out that
-it has its own limitations and using other engines might provide extra benefits.
-For example, some engines might provide better multi-threaded support or could
-support hardware acceleration physics simulation. And some of them might be better
-suited to some types of simulation.
-
-As a result, a physics abstraction layer was implemented by Andreas Held \todo{should we cite people?} and ODE
-implementation was moved out of the core and become a plugin. Now, it is possible
-to implement support for other physics engines as plugins, and use an appropriate
-plugin for a simulation on each hardware. A partial implementation of Bullet physics
-plugin is already available.
-
-\paragraph{Multi-threads Supporting\todo{agent controls}}
-In modern time, computers have a CPU with multi-cores or even multi-CPUs.
+\paragraph{Multi-threads Supporting}
+In modern time, computers have a processor with multi-cores or even multi-CPUs.
This improves the performance greatly, but only the multi-threaded program can benefit.
One great feature of SimSpark is switching between single thread mode and multi-threads
-mode. The multi-threads mode can improve the performance in computer with multi-cores CPU, but the single thread mode is also useful for developing the simulator.
+mode. The multi-threads mode can improve the performance in computer with multi-cores processor, but the single thread mode is also useful for developing the simulator.
The implementation of multi-threads loop is based on two conditions.
First, different tasks are assigned to different \textit{SimControlNode}s in SimSpark.
@@ -177,38 +132,45 @@
Second, all data of simulation state is stored in a tree called \textit{active scene},
the physics engine and \textit{SimControlNode}s interact through the \textit{active scene}.
As we know, the physics computation is the most time-consuming, and the physics engine does not need to access the active scene during physics computation.
-So the physics computation and \textit{SimControlNode}s can run in parallel.\todo[color=green]{UML?}\todo[color=yellow]{results of performance improvement, any benchmark?}
+So the physics computation and \textit{SimControlNode}s can run in parallel.
+Furthermore, the physics engine, e.g. Open Dynamic Engine\cite{Smith:ODE}, is modified to run in parallel by using Intel Threading Building Blocks\cite{tbb}.
-\todo[inline]{
-Sander van Dijk and Ubbo Visser
-Proposal: Boosting the 3D SSL Simulator
-Increase Research Possibilities in the RC SSL Community
+In RoboCup 2012, the 11 vs. 11 humanoid robot (22 degree of freedom) soccer games were simulated in real time by computer with Intel Core i7-975 @3.33GHz CPU and 4G DDR3 RAM. \todo[color=yellow]{results of performance improvement, any benchmark?}
-ODE TBB, ??sander's paper -- where??}\footnote{\url{http://www.robocup.org/2011/03/robocup-federation-call-for-project-proposals-2/}}
+\section{RCSSServer3D}
+\label{s:rcssserver3d}
-\todo[inline]{Internal/External Monitor}
+As the competition environment for the Soccer Simulation 3D League at RoboCup,
+RCSSServer3D simulates the soccer field where two team of robots play soccer game.
+In its initial version players were modeled as spheres in a physical three dimensional world. Now it supports humanoid players with articulated bodies. In particular, the soccer environment and rules are implemented in the simulation, and the NAO robot manufactured by Aldebaran Robotics is modeled.
-\todo[inline]{logfiles}
+\paragraph{Soccer Simulation}
+Most rules of the soccer game are judged by an automatic rule set that enforces the basic soccer rule set.
+However more involved situations like detection unfair behavior still require a human referee.
+Noticeably, the size of soccer field is increasing every year, since the number of robots in each team is increasing. In RoboCup 2012, each team has 11 robots. This
-\section{RCSSServer3D}
-\label{s:rcssserver3d}
-\todo[inline]{robot model: NAO (rcssserver3d)}
-\todo[inline]{soccer rules (referee) (rcssserver3d)}
-\todo[inline]{bigger fields and more robots (rcssserver3d)}
+\paragraph{Robot Model}
+The NAO robot is currently used in the competitions of the Soccer Simulation 3D League at RoboCup. Its height is about 57cm and its weight is around 4.5kg.
+Its biped architecture with 22 degrees of freedom allows NAO to have great mobility.
+The NAO robot model is also equipped with a powerful selection of the
+sensors described in section \ref{s:spark}, to provide a widespread information base for
+agent development.
+
+There are differences between simulated NAO and real NAO. For example, the left hip and the right hip in the real NAO are physically connected by one motor so they cannot be controlled independently. The simulated robot has a motor for each joint. Furthermore, the simulated robot gets positions of objects via virtual vision sensor, while the real robot has to process images to understand the world. Never the less, this NAO model enables RCSSServer3D as a good humanoid robot research platform.
+
+
\section{Experimental Features}
\label{s:ongoing}
These features are experimental, they (probably) will be used in RoboCup 2013 for the first time. (Some of them are still under the development)
\subsection{Realistic Motor}
-\todo{motivation: my email...}
-\todo{shorter}
NAO robot has twenty-one motor joints as its actuators.
+The simulation engine, e.g. ODE, provides a simple model of real life servos:
+the motor brings the body up to speed in one step; and provides force that is not more than is allowed.
The simple motor model is one reason for the unrealistic simulation results.
-The ODE provides a simple model of real life servos.
-It has two parameters: a desired speed and the maximum force that is available to reach that speed. The motor brings the body up to speed in one step; and provides force that is not more than is allowed.
-There is no motor that works like this in reality.
Furthermore, some aspects like stiffness control, power consumption and temperature regulation, are missing but are also important for robotics.
+In this section, we proposed and implemented a realistic motor model. More details and experimental results are given in \cite{Xu2012}.
\paragraph{Stiffness}
The stiffness determines how strong the motor is. The value is from 0.0
@@ -217,15 +179,11 @@
this percentage is the maximum electric current applied to the motor. Setting the
stiffness to 0.5 means that the electric current limitation is reduced
to 50\%.
-
For a DC motor, the electric current, $I$, determines the output torque,
-$\tau$:
-\begin{align}
- \tau &= K_\tau I \label{eq:tau-i}
-\end{align}
-where $K_\tau$ is the torque constant of the motor. It can be found in the
-specifications from \cite{naoqi}. In
-the simulation, the maximum torque of the servo can be specified, therefore the
+$\tau = K_\tau I \label{eq:tau-i}$;
+where $K_\tau$ is the torque constant of the motor. $K_\tau$ can be found in the
+specifications of motor, e.g. \cite{naoqi}.
+The simulation engine can specified the maximum torque of the servo, therefore the
stiffness control can be easily implemented by setting the maximum torque
of the simulated servo:
\begin{align}
@@ -239,46 +197,36 @@
Another important aspect besides the motor's performance is its
power consumption: how much energy does it cost to run.
The robot is powered by a battery with limited energy, and has to walk during the
-game: half a game is 10 minutes.
+game.
An even more important factor in energy consumption is
that the motor can overheat if it consumes too much energy and
-becomes too hot. In the real NAO, Aldebaran Robotics estimates the temperature
-of each motor by integrating electric current, and shuts down the motor
-when the temperature is too high. Therefore modeling power consuming
-is important for implementing energy effective motions.
+becomes too hot.
+In the real robot, the temperature of each motor is measured, and the motor shuts down
+when the temperature is too high.
-DC motors are based on the following equations:
-\begin{align}
- U &= U_e + IR \label{eq:u-ir}\\
- U_e &= K_e \dot{\theta} \label{eq:u-ke}
-\end{align}
+DC motors are based on this equation:
+$U = U_e + IR \label{eq:u-ir} = K_e \dot{\theta} \label{eq:u-ke}$;
where $U$ is the voltage of input, $U_e$ is the back electromotive
force (EMF), $I$ is the electric current, $R$ is resistance,
$\dot{\theta}$ is the speed, and $K_e$ is the speed constant of the motor.
-
-The value of $R$ and $K_e$ can be found in the specifications from \cite{naoqi};
+The value of $R$ and $K_e$ can be found in the specifications of motor again;
and the simulation engine provides
the value of $\tau$ and $\dot{\theta}$; therefore we can calculate the
-power consumption by putting \cref{eq:tau-i,eq:u-ir,eq:u-ke} together:
+power consumption:
\begin{align}
- P &= UI \\
- &= U_eI + I^2R \\
- &= \frac{K_e}{K_\tau}\dot{\theta}\tau + \frac{R}{K_\tau^2}\tau^2
+ P = UI = U_eI + I^2R = \frac{K_e}{K_\tau}\dot{\theta}\tau + \frac{R}{K_\tau^2}\tau^2
\end{align}
-
And the total energy used by the motor is:
\begin{equation}
\label{eq:motor-power}
E = \sum_t{P_t\Delta{}t}
\end{equation}
-where $\Delta{}t$ is the time step of the simulation, and $P_t$ is the power consumed at time $t$.
-
-\Cref{fig:battery} compares the simulation result of this model to
-reality. In this example, the robot turns left for 5 minutes, then
-stands for 1 minutes and then turns right for 5 minutes. This is shown by the change of electric current in the figure. For the overall
+where $\Delta{}t$ is the time step of the simulation, and $P_t$ is the power consumed at time $t$. For the overall
power consumption, the energy consumed by devices other than motors,
e.g. mainboard, CPU, camera, etc. has to be added. It is the power
-consumption of the robot in an idle state (all motors are off), and measured to be 33 W.
+consumption of the NAO robot in an idle state (all motors are off), and measured to be 33 W.
+\Cref{fig:battery} compares the simulation result of this model to
+reality.
\begin{figure}
\centering
@@ -286,15 +234,18 @@
\centering
\pgfplotsset{width=0.9\columnwidth,height=7cm}
\inputtikz{battery}
- \caption{Power consumption of the real and the simulated robot in action.
- The electric current is the summary of all motors.}
+ \caption{Power consumption of the real and the simulated NAO robot in action.
+ The electric current is the summary of all motors.
+ In this example, the robot turns left for 5 minutes, then
+stands for 1 minutes and then turns right for 5 minutes. This is shown by the change of electric current.}
\label{fig:battery}
\end{minipage}\hfill{}
\begin{minipage}{0.49\columnwidth}
\centering
\pgfplotsset{width=0.9\columnwidth,height=7cm}
\inputtikz{joint-temp-LKneePitch}
- \caption{The temperature of the (knee pitch) motor in the simulation and the real robot. The green background is the electric current in the real robot.}
+ \caption{The temperature of the (knee pitch) motor in the simulation and the real NAO robot. The green background is the electric current in the real robot. Note that the temperature of real NAO has accuracy of 1 $^{\circ}$C.\newline
+ }
\label{fig:joint-temperature}
\end{minipage}
\end{figure}
@@ -302,10 +253,8 @@
\paragraph{Temperature Regulation}
We model the temperature and heat of the motor with the following equations:
\begin{align}
- \Delta{}Q^+ &= I^2R\Delta{}t \\
- \Delta{}Q^- &= -\lambda(T-T_e)\Delta{}t \\
- \Delta{}Q &= \Delta{}Q^+ + \Delta{}Q^-\\
- C &= \frac{\Delta{}Q}{\Delta{}T}
+ \Delta{}Q &= \Delta{}Q^+ + \Delta{}Q^- = I^2R\Delta{}t -\lambda(T-T_e)\Delta{}t \\
+ \Delta{}Q &= C\Delta{}T
\end{align}
where $T$ is the temperature of the motor, $T_e$
is the temperature of the environment, but it is the internal temperature
@@ -320,43 +269,15 @@
\label{eq:motor-temp}
T_{t+\Delta{}t} = T_t + \Delta{}T = T_t + \frac{[I^2R-\lambda(T_t-T_e)]\Delta{}t}{C}
\end{equation}
-
-In this model, we determined $T_e$, $\lambda$, and $C$ by experiments. It can be formulate as a classic linear regression problem. We rewrite \cref{eq:motor-temp} to:
-\begin{align}
- \label{eq:motor-temp-ols}
- \Delta{}tx_0 + T_t\Delta{}tx_1 - \Delta{}t x_2 &= I^2R \\
- x_0 &= C \\
- x_1 &= \lambda \\
- x_2 &= \lambda Te
-\end{align}
-A sequence values of $\Delta{}t$, $T_t$, and $I^2R$ can be measured by experiment, therefore the optimum values for $x_0$, $x_1$, and $x_2$ can be obtained by linear least squares method, so the parameters of \cref{eq:motor-temp} is determined. \Cref{tab:motor-parameter} gives the results of the experiment.
-\begin{table}[h]
- \centering
- \caption{Parameters $T_e$, $\lambda$ and $C$ in the \cref{eq:motor-temp} for different joints of the NAO V3.}
- \label{tab:motor-parameter}
- \begin{tabular}{lccc}
- \toprule
- Joints & $T_e$ (\textdegree{}C) & $\lambda$ (W/\textdegree{}C) & $C$ (J/\textdegree{}C)\\
- \midrule
- HipYawPitch & 33 & 0.0158 & 27.2 \\
- \midrule
- HipRoll & & & \\
- AnkleRoll & 27 & 0.0158 & 27.2 \\
- \midrule
- HipPitch & & & \\
- KneePitch & 27 & 0.0198 & 43.6 \\
- AnklePitch & & & \\
- \bottomrule
- \end{tabular}
-\end{table}
-
+In this model, we need to determine $T_e$, $\lambda$, and $C$ by experiments. It can be formulate as a classic linear regression problem.
+A sequence values of $\Delta{}t$, $T_t$, and $I^2R$ can be measured by experiment, therefore the optimum parameters of \cref{eq:motor-temp} is determined.
After determining the parameters in the \cref{eq:motor-temp}, we can use this model to simulate motor temperature. In \Cref{fig:joint-temperature}, the simulated temperature is compared with data from the real robot.
The whole process of joint simulation is summarized in
\Cref{fig:joint}: stiffness $k_s$ is simulated by setting the maximum torque
of the motor $\tau_{max}$; the final maximum torque $\tau_m$ used by simulation engine is calculated by temperature regulation; and the simulation engine computes the resulted angle
and torque applied; in the end, the consumed power and temperature are
-computed by \cref{eq:motor-power,eq:motor-temp} respectively. When the battery is empty, the maximum torque $\tau_{max}$ is set 0 to turn off the motor.
+computed by \cref{eq:motor-power,eq:motor-temp} respectively. When the battery is empty, the maximum torque $\tau_{max}$ is set to 0 to turn off the motor.
\begin{figure}
\centering
\inputtikz{joint}
@@ -431,12 +352,15 @@
\section{Applications}
\label{s:application}
\paragraph{RoboCup Soccer Simulation League}
-In RoboCup 2004, SimSpark was successfully used for the first official competition in RoboCup Simulation 3D League. Since then, it is used as a standard research platform and test bed\todo{How many teams in last RoboCup?}. By using it, simulation teams not only have designed and tested new algorithms, but also developed useful research tools based on SimSpark. Some of these tools are also released as open source.
+In RoboCup 2004, SimSpark was successfully used for the first official competition in RoboCup Simulation 3D League. Since then, it is used as a standard research platform and test bed\todo{How many teams in last RoboCup?}.
+Simulation teams also developed useful research tools based on SimSpark. Some of these tools are also released as open source.
For example, RoboViz\cite{Stoecker2012} is designed to assess and develop agent behaviors in SimSpark,
it facilitates the real-time visualization of agents running concurrently on the SimSpark simulator,
-and provides higher-level analysis and visualization of agent behaviors.
+and provides higher-level analysis and visualization of agent behaviors.
+Combined with these tools, SimSpark becomes a good platform to develop and test new algorithms for multi-robot systems.
+It is also widely used to teach artificial intelligence and robotic lectures.
-\paragraph{Usage for Real Robot}
+\paragraph{RoboCup Soccer Standard Platform League}
As one of the long term goals of the soccer simulation is to aim for realism the long term objective are realistic humanoid players in a physical environment.
These players should one day challenge the champion of the most recent World Cup.
The SimSpark is also used by teams in RoboCup Standard Platform League and Humanoid League.
@@ -454,6 +378,7 @@
\label{f:simspark-spl}
\end{figure}
+\paragraph{RoboCup Soccer Humanoid League}
Of course the simulator can also be extended for other leagues by adding new robot models.
For example, in RoboCup Humanoid Kid Size League, FUmanoid\cite{Donat2012} uses
SimSpark to perform multi-level testing methods for archiving higher
@@ -463,7 +388,7 @@
\section{Conclusion and Future Work}
\label{s:conclusion}
-SimSpark is a powerful tool to state different multi-agent research questions.
+SimSpark is a powerful tool to state different multi-robot researches.
\paragraph{Integration With Existing Robotic Frameworks}
To enhance the usability of SimSpark for wider usage, and also to make it easier
@@ -490,9 +415,9 @@
who have developed programs for real robots using the framework to experiment
with SimSpark.
-\todo[inline]{Other physic engine, Bullet}
+\todo[inline]{Other physic engine, Bullet / physics simulation engine abstraction}
\todo[inline]{better GUI}
-
+\todo[inline]{more robot models?}
\section*{Acknowledgments}
\bibliographystyle{splncs03}
Modified: trunk/spark/doc/papers/2013/reference.bib
===================================================================
--- trunk/spark/doc/papers/2013/reference.bib 2013-03-29 19:47:49 UTC (rev 344)
+++ trunk/spark/doc/papers/2013/reference.bib 2013-03-29 20:18:52 UTC (rev 345)
@@ -77,6 +77,26 @@
RoboCup Simulation League competition. }
}
+@ARTICLE{riley2003spades,
+ author = {Riley, Patrick},
+ title = {SPADES: a system for parallel-agent, discrete-event simulation},
+ journal = {AI Magazine},
+ year = {2003},
+ volume = {24},
+ pages = {41},
+ number = {2}
+}
+
+@MANUAL{Smith:ODE,
+ title = {Open Dynamic Engine User Guide},
+ author = {Russell Smith},
+ year = {2006},
+ note = {Last visited at 07.02.2013},
+ file = {:windows/E/download_doc/RoboCup/ode-latest-userguide.pdf:PDF},
+ typeoflit = {EB/OL},
+ url = {http://www.ode.org}
+}
+
@INPROCEEDINGS{Stoecker2012,
author = {Justin Stoecker and Ubbo Visser},
title = {RoboViz: Programmable Visualization for Simulated Soccer},
@@ -86,12 +106,22 @@
timestamp = {2013.03.25}
}
-@article{riley2003spa...
[truncated message content] |
|
From: <yx...@us...> - 2013-03-30 00:43:27
|
Revision: 347
http://simspark.svn.sourceforge.net/simspark/?rev=347&view=rev
Author: yxu
Date: 2013-03-30 00:43:18 +0000 (Sat, 30 Mar 2013)
Log Message:
-----------
submit open-source-paper
* open-source-paper:
submit
spell checking
draft 1 (in 8 pages)
future work
Modified Paths:
--------------
trunk/spark/doc/papers/2013/joint.tikz
trunk/spark/doc/papers/2013/opensource.tex
trunk/spark/doc/papers/2013/reference.bib
Modified: trunk/spark/doc/papers/2013/joint.tikz
===================================================================
--- trunk/spark/doc/papers/2013/joint.tikz 2013-03-29 21:11:54 UTC (rev 346)
+++ trunk/spark/doc/papers/2013/joint.tikz 2013-03-30 00:43:18 UTC (rev 347)
@@ -1,5 +1,5 @@
\begin{tikzpicture}
- \tikzstyle{module}=[draw, minimum height=1cm, minimum width=2cm]
+ \tikzstyle{module}=[draw, minimum height=0.9cm, minimum width=2cm]
\node[module] (sc) {\shortstack{Stiffness\\ Control}};
\draw[<-] (sc) -- node[at end, above]{$k_s$} ++(-1.6,0);
@@ -26,9 +26,9 @@
\draw[->] ($(ps.south east)!0.7!(ps.south west)$) -- ++(0,-0.2) -| node[above, near start]{$\Delta{Q}^+$}
(bl);
- \node[module] (bat) at (6, -1.7) {Battery};
+ \node[module, minimum height=0.5cm] (bat) at (6, -1.3) {Battery};
\draw[->] ($(ps.south east)!0.3!(ps.south west)$) |- node[above, near end]{$E$} (bat);
\draw[->] (bat) -| node[above, near start] {On/Off} (sc);
- \draw[dashed] (-1.3,-1.1) rectangle (9.9,1.8) node[anchor=north east] {Servo Motor Model};
+ \draw[dashed] (-1.3,-0.8) rectangle (9.9,1.7) node[anchor=north east] {Servo Motor Model};
\end{tikzpicture}
\ No newline at end of file
Modified: trunk/spark/doc/papers/2013/opensource.tex
===================================================================
--- trunk/spark/doc/papers/2013/opensource.tex 2013-03-29 21:11:54 UTC (rev 346)
+++ trunk/spark/doc/papers/2013/opensource.tex 2013-03-30 00:43:18 UTC (rev 347)
@@ -1,6 +1,7 @@
\documentclass{llncs}
+\usepackage[belowskip=-15pt,aboveskip=10pt]{caption}
\usepackage[utf8]{inputenc}
-\usepackage{todonotes}
+\usepackage[disable]{todonotes}
\usepackage{amsmath}
\usepackage[hidelinks]{hyperref}
\usepackage{cleveref}
@@ -71,16 +72,15 @@
Using simulation for algorithm development and testing makes thing easier.
% \paragraph{History}
-\textit{SimSpark}, a multi-robot simulator based on the generic components of the Spark\cite{OR05} physical multi-agent simulation system, has been used in the RoboCup Soccer Simulation League since 2004.
+SimSpark, a multi-robot simulator based on the generic components of the Spark\cite{OR05} physical multi-agent simulation system, has been used in the RoboCup Soccer Simulation League since 2004.
The project was registered as open source project in SourceForge in 2004, it has an established code base with development increasing year-over-year.
As the result, RoboCup soccer simulations have changed significantly over the years, going from rather abstract agent representations to more and more realistic humanoid robot games\cite{Boedecker2008,usermanual}.
Thanks to the flexibility of the Spark system, these transitions were achieved with little changes to the simulator's core architecture.
-In this paper we describe the recent development of \textit{SimSpark} project, which make the \textit{SimSpark} possible to simulate 11 vs. 11 humanoid robot soccer games in real time\todo{is it real time in RoboCup 2012?}.
-In section \ref{s:overview}, we will give an overview of \textit{SimSpark} project since 2008. After that, we will describe the development of the \textit{Spark} simulation platform in section \ref{s:spark}.
-In section \ref{s:rcssserver3d}, we will briefly describe the implementation of RoboCup 3D Soccer Simulator -- \textit{RCSSServer3D}.
+In this paper we describe the recent development of SimSpark project, which make the SimSpark possible to simulate 11 vs. 11 humanoid robot soccer games in real time\todo{is it real time in RoboCup 2012?}.
+In section \ref{s:overview}, we will give an overview of the SimSpark project since 2008. After that, we will describe the development of the Spark simulation platform in section \ref{s:spark} and the implementation of RoboCup 3D Soccer Simulator in section \ref{s:rcssserver3d}.
We will introduce some new features for RoboCup 2013 in section \ref{s:ongoing}.
-Furthermore, we will discuss the application of \textit{SimSpark} not only in simulation league but also other leagues with real robots in section \ref{s:application}.
+Furthermore, we will give the application examples of SimSpark in section \ref{s:application}.
Finally, we will outline future development plans in section \ref{s:conclusion}.
\section{Project Overview}
@@ -102,11 +102,11 @@
\section{Spark}
\label{s:spark}
-As a generic simulation environment, Spark provides a rich set of features to create, debug and modify multi-robot simulation.
+As a generic simulation environment, Spark provides a rich set of features to create, debug and modify multi-robot simulations.
It has three main components, including the simulation engine, the object and memory management system, and the physics engine. Details about architecture and concepts of Spark have been described in \cite{Boedecker2008,OR05}.
In this section, we describe the necessary changes for simulating 11 vs. 11 humanoid robot soccer game.
-However changes to the simulator core were never customized for the soccer simulation.
-First, a set of sensors of humanoid robot are implemented as plugins. Second, multi-threads supporting takes advantage of multi-cores in modern CPU to be able to run in real time.
+However changes to the simulator core were never specialized for the soccer simulation.
+% First, a set of sensors of humanoid robot are implemented as plugins. Second, multi-threads supporting takes advantage of multi-cores in modern CPU to be able to run in real time.
\paragraph{Sensor Plugins}
Sensors of a robot allows awareness of the robot's state and the environment.
@@ -116,8 +116,8 @@
Additionally, a more realistic camera which delivers images rendered via OpenGL hardware accelerated offscreen buffers is implemented. Details of these sensors can be found in \cite{usermanual}.
\paragraph{Multi-threads Supporting}
-In modern time, computers have a processor with multi-cores or even multi-CPUs.
-This improves the performance greatly, but only the multi-threaded program can benefit.
+% In modern time, computers have a processor with multi-cores or even multi-CPUs.
+% This improves the performance greatly, but only the multi-threaded program can benefit.
One great feature of SimSpark is switching between single thread mode and multi-threads
mode. The multi-threads mode can improve the performance in computer with multi-cores processor, but the single thread mode is also useful for developing the simulator.
@@ -138,7 +138,8 @@
As the competition environment for the Soccer Simulation 3D League at RoboCup,
RCSSServer3D simulates the soccer field where two team of robots play soccer game.
-In its initial version players were modeled as spheres in a physical three dimensional world. Now it supports humanoid players with articulated bodies. In particular, the soccer environment and rules are implemented in the simulation, and the NAO robot manufactured by Aldebaran Robotics is modeled.
+In its initial version players were modeled as spheres in a physical three dimensional world. Now it supports humanoid players with articulated bodies.
+% In particular, the soccer environment and rules are implemented in the simulation, and the NAO robot manufactured by Aldebaran Robotics is modeled.
\paragraph{Soccer Simulation}
Most rules of the soccer game are judged by an automatic rule set that enforces the basic soccer rule set.
@@ -153,35 +154,34 @@
sensors described in section \ref{s:spark}, to provide a widespread information base for
agent development.
-There are differences between simulated NAO and real NAO. For example, the left hip and the right hip in the real NAO are physically connected by one motor so they cannot be controlled independently. The simulated robot has a motor for each joint. Furthermore, the simulated robot gets positions of objects via virtual vision sensor, while the real robot has to process images to understand the world. Never the less, this NAO model enables RCSSServer3D as a good humanoid robot research platform.
+There are differences between simulated NAO and real NAO. For example, the left hip and the right hip in the real NAO are physically connected by one motor so they cannot be controlled independently. The simulated robot has one motor for each joint. Furthermore, the simulated robot gets positions of objects via virtual vision sensor, while the real robot has to process images to understand the world. Nevertheless, this NAO model enables RCSSServer3D to be a good humanoid robot research platform.
\section{Experimental Features}
\label{s:ongoing}
-For getting more realistic simulation, some new features are proposed and implemented, including realistic motor, heterogeneous robots, and agent proxies. Furthermore, a new graphic user interface is implemented for better user experiences.
+For getting more realistic simulation, some new features are proposed and implemented, including realistic motor, heterogeneous robots, and agent proxies.
+% Furthermore, a new graphic user interface is implemented for better user experiences.
These experimental features probably will be used in RoboCup 2013 for the first time.
\subsection{Realistic Motor}
NAO robot has twenty-one motor joints as its actuators.
-The simulation engine, e.g. ODE, provides a simple model of real life servos:
+The simulation engine, i.e. ODE, provides a simple model of real life servos:
the motor brings the body up to speed in one step; and provides force that is not more than is allowed.
The simple motor model is one reason for the unrealistic simulation results.
-Furthermore, some aspects like stiffness control, power consumption and temperature regulation, are missing but are also important for robotics.
-In this section, we proposed and implemented a realistic motor model. More details and experimental results are given in \cite{Xu2012}.
+% Furthermore, some aspects like stiffness control, power consumption and temperature regulation, are missing but are also important for robotics.
+In this section, we proposed and implemented a realistic motor model. More details and experimental results are described in \cite{Xu2012}.
\paragraph{Stiffness}
-The stiffness determines how strong the motor is. The value is from 0.0
-to 1.0, 0 means the motor is off and 1 means the motor is running at
-full power. In the real robot,
-this percentage is the maximum electric current applied to the motor. Setting the
-stiffness to 0.5 means that the electric current limitation is reduced
-to 50\%.
+The stiffness determines how strong the motor is.
+% The value is from 0.0 to 1.0, 0 means the motor is off and 1 means the motor is running at full power.
+In the real robot, this percentage is the maximum electric current applied to the motor.
+% Setting the stiffness to 0.5 means that the electric current limitation is reduced to 50\%.
For a DC motor, the electric current, $I$, determines the output torque,
$\tau = K_\tau I \label{eq:tau-i}$;
-where $K_\tau$ is the torque constant of the motor. $K_\tau$ can be found in the
-specifications of motor, e.g. \cite{naoqi}.
-The simulation engine can specified the maximum torque of the servo, therefore the
+where $K_\tau$ is the torque constant of the motor, and can be found in the
+specification.
+The simulation engine can specify the maximum torque of the servo, therefore the
stiffness control can be easily implemented by setting the maximum torque
of the simulated servo:
\begin{align}
@@ -192,17 +192,14 @@
denotes the maximum torque of the servo when stiffness is 1.
\paragraph{Power Consumption}
-Another important aspect besides the motor's performance is its
-power consumption: how much energy does it cost to run.
-The robot is powered by a battery with limited energy, and has to walk during the
+Another important aspect of real motor is power consumption.
+Because the robot is powered by a battery with limited energy, and has to walk during the
game.
-An even more important factor in energy consumption is
-that the motor can overheat if it consumes too much energy and
-becomes too hot.
-In the real robot, the temperature of each motor is measured, and the motor shuts down
+Furthermore, the motor can overheat if it consumes too much energy and becomes too hot.
+In real robots, the temperature of each motor is measured, and the motor shuts down
when the temperature is too high.
-DC motors are based on this equation:
+DC motors can be modeled by the following equation:
$U = U_e + IR \label{eq:u-ir} = K_e \dot{\theta} \label{eq:u-ke}$;
where $U$ is the voltage of input, $U_e$ is the back electromotive
force (EMF), $I$ is the electric current, $R$ is resistance,
@@ -221,32 +218,31 @@
\end{equation}
where $\Delta{}t$ is the time step of the simulation, and $P_t$ is the power consumed at time $t$. For the overall
power consumption, the energy consumed by devices other than motors,
-e.g. mainboard, CPU, camera, etc. has to be added. It is the power
-consumption of the NAO robot in an idle state (all motors are off), and measured to be 33 W.
-\Cref{fig:battery} compares the simulation result of this model to
-reality.
+e.g. main board, CPU, camera, etc. has to be counted.
+% \Cref{fig:battery} compares the simulation result of this model to
+% reality.
-\begin{figure}
- \centering
- \begin{minipage}{0.49\columnwidth}
- \centering
- \pgfplotsset{width=0.9\columnwidth,height=7cm}
- \inputtikz{battery}
- \caption{Power consumption of the real and the simulated NAO robot in action.
- The electric current is the summary of all motors.
- In this example, the robot turns left for 5 minutes, then
-stands for 1 minutes and then turns right for 5 minutes. This is shown by the change of electric current.}
- \label{fig:battery}
- \end{minipage}\hfill{}
- \begin{minipage}{0.49\columnwidth}
- \centering
- \pgfplotsset{width=0.9\columnwidth,height=7cm}
- \inputtikz{joint-temp-LKneePitch}
- \caption{The temperature of the (knee pitch) motor in the simulation and the real NAO robot. The green background is the electric current in the real robot. Note that the temperature of real NAO has accuracy of 1 $^{\circ}$C.\newline
- }
- \label{fig:joint-temperature}
- \end{minipage}
-\end{figure}
+% \begin{figure}
+% \centering
+% \begin{minipage}{0.49\columnwidth}
+% \centering
+% \pgfplotsset{width=0.9\columnwidth,height=7cm}
+% \inputtikz{battery}
+% \caption{Power consumption of the real and the simulated NAO robot in action.
+% The electric current is the summary of all motors.
+% In this example, the robot turns left for 5 minutes, then
+% stands for 1 minutes and then turns right for 5 minutes. This is shown by the change of electric current.}
+% \label{fig:battery}
+% \end{minipage}\hfill{}
+% \begin{minipage}{0.49\columnwidth}
+% \centering
+% \pgfplotsset{width=0.9\columnwidth,height=7cm}
+% \inputtikz{joint-temp-LKneePitch}
+% \caption{The temperature of the (knee pitch) motor in the simulation and the real NAO robot. The green background is the electric current in the real robot. Note that the temperature of real NAO has accuracy of 1 $^{\circ}$C.\newline
+% }
+% \label{fig:joint-temperature}
+% \end{minipage}
+% \end{figure}
\paragraph{Temperature Regulation}
We model the temperature and heat of the motor with the following equations:
@@ -255,27 +251,28 @@
\Delta{}Q &= C\Delta{}T
\end{align}
where $T$ is the temperature of the motor, $T_e$
-is the temperature of the environment, but it is the internal temperature
-of motor, so it is higher than outside and differs from motor to
-motor, $\Delta{}Q^+$ is the heat produced by the motor, $\Delta{}Q^-$ is
-the heat transferred from the motor to the environment, $\Delta{}Q$ is the
-heat changing, $\lambda$ is thermal conductivity which indicates the
-ability of a motor to conduct heat, and $C$ is the heat capacity of
+is the environment temperature inside the motor, so it is higher than outside and differs from motor to motor, $\Delta{}Q$ is the
+heat changing, $\Delta{}Q^+$ is the heat produced by the motor, $\Delta{}Q^-$ is
+the heat transferred from the motor to the environment, $\lambda$ is thermal conductivity which indicates the ability of a motor to conduct heat, and $C$ is the heat capacity of
the motor, which can be seen as constant. Finally, the temperature of
the motor at time $t+\Delta{}t$ can be solved as:
\begin{equation}
\label{eq:motor-temp}
T_{t+\Delta{}t} = T_t + \Delta{}T = T_t + \frac{[I^2R-\lambda(T_t-T_e)]\Delta{}t}{C}
\end{equation}
-In this model, we need to determine $T_e$, $\lambda$, and $C$ by experiments. It can be formulate as a classic linear regression problem.
+In this model, we need to determine $T_e$, $\lambda$, and $C$ by experiments.
+% It can be formulate as a classic linear regression problem.
A sequence values of $\Delta{}t$, $T_t$, and $I^2R$ can be measured by experiment, therefore the optimum parameters of \cref{eq:motor-temp} is determined.
-After determining the parameters in the \cref{eq:motor-temp}, we can use this model to simulate motor temperature. In \Cref{fig:joint-temperature}, the simulated temperature is compared with data from the real robot.
+% After determining the parameters in the \cref{eq:motor-temp}, we can use this model to simulate motor temperature.
+% In \Cref{fig:joint-temperature}, the simulated temperature is compared with data from the real robot.
The whole process of joint simulation is summarized in
-\Cref{fig:joint}: stiffness $k_s$ is simulated by setting the maximum torque
-of the motor $\tau_{max}$; the final maximum torque $\tau_m$ used by simulation engine is calculated by temperature regulation; and the simulation engine computes the resulted angle
-and torque applied; in the end, the consumed power and temperature are
-computed by \cref{eq:motor-power,eq:motor-temp} respectively. When the battery is empty, the maximum torque $\tau_{max}$ is set to 0 to turn off the motor.
+\Cref{fig:joint}.
+% stiffness $k_s$ is simulated by setting the maximum torque
+% of the motor $\tau_{max}$; the final maximum torque $\tau_m$ used by simulation engine is calculated by temperature regulation; and the simulation engine computes the resulted angle
+% and torque applied; in the end, the consumed power and temperature are
+% computed by \cref{eq:motor-power,eq:motor-temp} respectively.
+When the battery is empty, the maximum torque $\tau_{max}$ is set to 0 to turn off the motor.
\begin{figure}
\centering
\inputtikz{joint}
@@ -340,37 +337,34 @@
Currently, an initial version of agent proxies is under development outside SimSpark
project using Java.
-\subsection{SimSpark GUI}
-\todo{SimSpark GUI: \url{http://simspark.sourceforge.net/wiki/index.php/Graphical_User_Interface}}
+% \subsection{SimSpark GUI}
+% \todo{SimSpark GUI: \url{http://simspark.sourceforge.net/wiki/index.php/Graphical_User_Interface}}
-NOTE: It will be merged to trunk soon. So it is almost complete.
+% NOTE: It will be merged to trunk soon. So it is almost complete.
-The main goal of this project is to provide a flexible and extensible User Interface and Simulation Development Environment, that can be used to start, control and monitor different simulations using the Simspark server, agent and monitor processes, as well as incorporate several additional tools like for example a visual editor for robot models (like RsgEdit) or a debugging monitor for agents (like RoboViz).
+% The main goal of this project is to provide a flexible and extensible User Interface and Simulation Development Environment, that can be used to start, control and monitor different simulations using the Simspark server, agent and monitor processes, as well as incorporate several additional tools like for example a visual editor for robot models (like RsgEdit) or a debugging monitor for agents (like RoboViz).
\section{Applications}
+As a powerful robot simulator, SimSpark is gaining popularity in RoboCup, including Standard Platform League and Humanoid League. It is also widely used to teach artificial intelligence and robotic lectures.
+
\label{s:application}
-\paragraph{RoboCup Soccer Simulation League}
-In RoboCup 2004, SimSpark was successfully used for the first official competition in RoboCup Simulation 3D League. Since then, it is used as a standard research platform and test bed\todo{How many teams in last RoboCup?}.
-Simulation teams also developed useful research tools based on SimSpark. Some of these tools are also released as open source.
-For example, RoboViz\cite{Stoecker2012} is designed to assess and develop agent behaviors in SimSpark,
-it facilitates the real-time visualization of agents running concurrently on the SimSpark simulator,
-and provides higher-level analysis and visualization of agent behaviors.
-Combined with these tools, SimSpark becomes a good platform to develop and test new algorithms for multi-robot systems.
-It is also widely used to teach artificial intelligence and robotic lectures.
+% \paragraph{RoboCup Soccer Simulation League} Simulation 3D League. Since 2004, SimSpark has been used as a official competitions environment. Since then, research teams have developed useful research tools based on SimSpark. Some of these tools are also released as open source.
+% For example, RoboViz\cite{Stoecker2012} is designed to assess and develop agent behaviors in SimSpark.
+% Combined with these tools, SimSpark becomes a useful platform to develop and test new algorithms for multi-robot systems.
\paragraph{RoboCup Soccer Standard Platform League}
-As one of the long term goals of the soccer simulation is to aim for realism the long term objective are realistic humanoid players in a physical environment.
-These players should one day challenge the champion of the most recent World Cup.
-The SimSpark is also used by teams in RoboCup Standard Platform League and Humanoid League.
+% As one of the long term goals of the soccer simulation is to aim for realism the long term objective are realistic humanoid players in a physical environment.
+% These players should one day challenge the champion of the most recent World Cup.
+% The SimSpark is also used by teams in RoboCup Standard Platform League and Humanoid League.
The special situation between Standard Platform League and 3D Simulation League is that both leagues use the same robot model — NAO from Aldebaran.
-So it appears to be natural to reuse the work which has already been done in Simulation League and make SimSpark usable in Standard Platform League.
-Nao Team Humboldt developed their software architecture\cite{SCPR2010} which enables their control software can run both in real NAO and simulated NAO with SimSpark. This helps them to achieve some good results in both Simulation League and Standard Platform League.
-Furthermore, Nao Team Humboldt also promotes the usage of SimSpark in the Standard Platform League by implementing its rules. \Cref{f:simspark-spl} is the snapshot of the extended SimSpark for Standard Platform League.
+So it appears to be natural to reuse the work which has already been done.
+Nao Team Humboldt developed a software architecture\cite{SCPR2010} which enables their control software can run both in real NAO and simulated NAO with SimSpark. This helps them to participate in both Simulation League and Standard Platform League, and achieve some good results.
+Furthermore, Nao Team Humboldt also promotes the usage of SimSpark in the Standard Platform League by implementing its rules, see \Cref{f:simspark-spl}.
\begin{figure}
\centering
- \includegraphics[width = 0.75\columnwidth]{simspark-spl}
+ \includegraphics[width = 0.6\columnwidth]{simspark-spl}
\caption{Prototype of the extended SimSpark for Standard Platform League.
The bottom of screen are images of robot cameras.}
\label{f:simspark-spl}
@@ -387,40 +381,47 @@
\section{Conclusion and Future Work}
\label{s:conclusion}
SimSpark is a powerful tool to state different multi-robot researches.
-The introduction of a humanoid robot model to the simulation gave another perspective to the league.
-The interest in the 3D simulation competition is growing fast and research is slowly getting back to the design and implementation of multi-agent higher-level behaviors based on solid low level behavior architectures for realistic humanoid robot teams.
+The introduction of a humanoid robot model increase the realism of SimSpark, and gains popularity in research teams who have real robots.
+The increased number of players per team makes research slowly get back to the high level behaviors based on solid low level behavior for realistic humanoid robot teams.
-SimSpark has undergone continuous development driven by the requirement of continues research in multi-robot system.
-
-\paragraph{Integration With Existing Robotic Frameworks}
-To enhance the usability of SimSpark for wider usage, and also to make it easier
-for developers to develop and test their robotic software on SimSpark and to
+SimSpark has undergone continuous development driven by the requirement of continuous research in multi-robot system. The following approaches are planned:
+\begin{description}
+\item[Integration With Existing Robotic Frameworks]
+To enhance the usability of SimSpark for wider usage, and also to make it easier to develop and test their robotic software on SimSpark and to
use the same code on real hardware, we aim to integrate SimSpark to an
-existing robotic framework. Player is a well-known robotic framework which
-can be used to control both real and simulated robots. We planned to integrate
-SimSpark with Player so that people can develop agents for SimSpark using
-Player interfaces. It has the additional benefit of using Player's network
-protocol which is much more efficient than the current network protocol used
-in SimSpark. It is also a good opportunity to enhance the multi-threaded
-capabilities of SimSpark given the asynchronous nature of using Player with
-different robot sensors.
+existing robotic framework, such as Player and ROS.
-Recently, another robotic framework called ROS is gaining popularity and is in
-active development. Therefore, we will reconsider our planning and might decide
-to integrate SimSpark with ROS instead. However, considering that Player itself
-is integrated into ROS, integrating with Player still might make sense.
+% Player is a well-known robotic framework which
+% can be used to control both real and simulated robots. We planned to integrate
+% SimSpark with Player so that people can develop agents for SimSpark using
+% Player interfaces. It has the additional benefit of using Player's network
+% protocol which is much more efficient than the current network protocol used
+% in SimSpark. It is also a good opportunity to enhance the multi-threaded
+% capabilities of SimSpark given the asynchronous nature of using Player with
+% different robot sensors.
-If SimSpark is integrated into an existing robotic framework, it is possible
-for researchers to develop a single program to control both a simulated
-robot inside and the same real robot given that the robot itself is also
-supported by the framework. It will be also much easier to attract people
-who have developed programs for real robots using the framework to experiment
-with SimSpark.
+% Recently, another robotic framework called ROS is gaining popularity and is in
+% active development. Therefore, we will reconsider our planning and might decide
+% to integrate SimSpark with ROS instead. However, considering that Player itself
+% is integrated into ROS, integrating with Player still might make sense.
-\paragraph{physics simulation engine abstraction / Bullet}
-\paragraph{more robot models, formate?}
+% If SimSpark is integrated into an existing robotic framework, it is possible
+% for researchers to develop a single program to control both a simulated
+% robot inside and the same real robot given that the robot itself is also
+% supported by the framework. It will be also much easier to attract people
+% who have developed programs for real robots using the framework to experiment
+% with SimSpark.
+
+\item[Abstract Physics Layer]
+Relying on a single physics engine, i.e. ODE, hampers Simspark's flexibility.
+Thus, an abstract physics layer was development\cite{Held2010}, ODE and Bullet can be used as plugins with the abstract physics layer. However, current implementation has many drawbacks and difficult to maintenance.
+
+\item[Robot Model Importers]
+The usage of SimSpark will be extended when it has more robot models, however creating robot models is a time consuming task. The idea is to create model importers for different model format, so SimSpark will be able to use the robot model which is available in other simulators.
+\end{description}
+
\section*{Acknowledgments}
-We wish to thank other members in in the Maintenance Committee of the RoboCup Soccer Simulation League, especially the original authors of SimSpark: M. K\"ogler, M. Rollmann, and O. Obst. Furthermore, thanks go to J. Boedecker for introducing us to the SimSpark project.\todo{other names here...}
+We wish to thank other members in the Maintenance Committee of the RoboCup Soccer Simulation League, especially the original authors of SimSpark: M. K\"ogler, M. Rollmann, and O. Obst. Furthermore, thanks go to J. Boedecker for supporting us to work in the SimSpark project.\todo{other names here...}
\bibliographystyle{splncs03}
\bibliography{reference}
\end{document}
Modified: trunk/spark/doc/papers/2013/reference.bib
===================================================================
--- trunk/spark/doc/papers/2013/reference.bib 2013-03-29 21:11:54 UTC (rev 346)
+++ trunk/spark/doc/papers/2013/reference.bib ...
[truncated message content] |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X