<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 09/27/2012 09:55 AM, Matthias
Goldhoorn wrote:<br>
</div>
<blockquote cite="mid:5064067B.50102@dfki.de" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
On 27.09.2012 09:50, Alexander Duda wrote:
<blockquote cite="mid:50640559.40904@dfki.de" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 09/27/2012 09:04 AM, Matthias
Goldhoorn wrote:<br>
</div>
<blockquote cite="mid:5063FA88.1080808@dfki.de" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
On 27.09.2012 08:51, Jakob Schwendner wrote:
<blockquote cite="mid:5063F75F.8050409@dfki.de" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
On 09/26/2012 04:59 PM, Alexander Duda wrote:
<blockquote cite="mid:5063183D.90000@dfki.de" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 09/26/2012 04:24 PM,
Matthias Goldhoorn wrote:<br>
</div>
<blockquote cite="mid:5063100D.60801@dfki.de" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
On 26.09.2012 16:22, Javier Hidalgo Carrió wrote:
<blockquote cite="mid:50630F89.9020605@dfki.de"
type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 09/26/2012 03:33 PM,
Matthias Goldhoorn wrote:<br>
</div>
<blockquote cite="mid:5063042B.7070602@dfki.de"
type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Hmh, <br>
<br>
i think we should add base::Temperature analog to
base::angle WITHOUT an timestamp, becasue the
temperature can then be added to any class without
duplicate the time field.<br>
<br>
</blockquote>
In this case we will not be able to log the
temperature alone in a port with a timestamp. We will
need to use the timestamp from other port.<br>
</blockquote>
Thats the reason why you should add also the
"base::TemperatureReading" type, which includes the time
and the base::Temperature ;).<br>
<br>
In general in the past i was for an generic data type
Stamped<T> which is in general for this kind of
thinks, but there was some points against this, but i
would like to point to it again ;).<br>
</blockquote>
<br>
I do see Matthias point but I would rather go for:<br>
base::Temperature <br>
and<br>
struct base::samples::Temperature <br>
{<br>
base::Time time;<br>
base::Temperature temperature;<br>
}<br>
<br>
Alex<br>
<br>
</blockquote>
This seems to be most consistent with what we already have.
Come to think of it I wouldn't even mind having an origin
string field in the base::samples::Temperature type, as
Matthias suggested.<br>
</blockquote>
One addition why i would like to have an origin field, the
origin field could be used for some user GUIs, that can be
created automatic an overview over all system temperatures,
without needing the gui-creation-user to know where
temperature sensor is located, and from what task they came
and where the device for the task is located inside the
system. (for manual connecting gui-parts with tasks)<br>
</blockquote>
<br>
I am against adding a description field as this is doubling the
mechanism of the transformer.<br>
In general the transformer stack knows where each temperature
sensor is located if the frame and static transformation is
correctly set. Furthermore sending the same string over and over
again, filling up our log files, has a bad taste.<br>
<br>
see <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://www.rock-robotics.org/stable/documentation/data_processing/transformer.html">http://www.rock-robotics.org/stable/documentation/data_processing/transformer.html</a>
for more informations.<br>
<br>
<br>
Alex<br>
</blockquote>
<br>
But where is the association between the transformer and the
base::samples::temperature reading, there is no connection between
then.<br>
</blockquote>
Yes, there is. Just like every other sensor the temperature sensor
belongs to a certain frame which can be set with the help of the
transformer stack.<br>
<br>
<blockquote cite="mid:5064067B.50102@dfki.de" type="cite"> In case
for the imu you could _assume_ that the temperature sensor is in
the imu. But i have other components that are spread over the
system, and can multiple temperatures. So i don't see the
relationship to the transformer. Okay you could use an
transformation description to that you can display the temperature
sensor inside of your system in vizkit3d,</blockquote>
You can use whatever widget you like to display the information. You
could even display/plot just the associated frame nam and the
temperature values.<br>
<br>
<blockquote cite="mid:5064067B.50102@dfki.de" type="cite"> but the
transformer also uses only strings, so if you add an string the
transformer could be used for this. But i don't see the point that
the string duplicates information....<br>
</blockquote>
<br>
The transformer uses port annotations to define the frame of each
port. It does not add any string to a sample. It also gives you a
mechanism to easily change the frame of your sensor without touching
the component. <br>
<br>
Alex<br>
<br>
<pre class="moz-signature" cols="72">--
Dipl.-Ing. Alexander Duda
Unterwasserrobotik
DFKI Bremen
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany
Phone: +49 (0)421 178-456620
Fax: +49 (0)421 178-454150
E-Mail: <a class="moz-txt-link-abbreviated" href="mailto:alexander.duda@dfki.de">alexander.duda@dfki.de</a>
Weitere Informationen: <a class="moz-txt-link-freetext" href="http://www.dfki.de/robotik">http://www.dfki.de/robotik</a>
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3 </pre>
</body>
</html>