<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 08.04.2014 16:21, Sylvain Joyeux
wrote:<br>
</div>
<blockquote
cite="mid:CAKDpF4QLVgNH+5Zg+9zTtr=13FAb4jcHwbE9ty_6P-kiksjCrg@mail.gmail.com"
type="cite">
<div dir="ltr">In addition to making the controldev component
simpler, having a 1D vector would allow to have more
straightforward generic conversion components (e.g. a
rawcommand-to-motioncommand would only need two axis IDs instead
of 4 to convert from rawcommand to forward/rotation)</div>
</blockquote>
There were two different things in this discussion:<br>
- using the controldev to directly output MotionCommands<br>
--- I removed this feature because it's not generic doable to create
motion commands from joysticks.<br>
- Using 1D vs. 2D arrays<br>
Even a conversion might be more complicated. We now using a
RC-Control and it's really horrible to have only one 1D array.<br>
It produces more faults in the usage from my experience.<br>
<br>
To create a conversion-component. This Conversion component must be
able to handle ALL Joints, and use-cases for ALL possible systems.
We could start a basic one. But from my point of view this would get
messed up.<br>
Nevertheless if someone would like to write a component, the 2D
version is more complex but from my point of view the way to go. The
Mapping could be done in a yaml file to for 2d arrays.<br>
<br>
The Controldev is a DRIVER, not a motor or system controller by
default. I understand the intention to use this as a controller, i
would point out that this driver isn't a controller and therefore
only should write outputs in a most-generic and understandable way.<br>
<br>
<blockquote
cite="mid:CAKDpF4QLVgNH+5Zg+9zTtr=13FAb4jcHwbE9ty_6P-kiksjCrg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<br>
</div>
<div>I definitely +1 the 1D vector in principle, now I do
understand that we don't necessarily want to update the type.
That being said, did you guys not start to create a process to
deprecate types ?<br>
</div>
</div>
</blockquote>
<br>
It's started but not completely tested:<br>
<a class="moz-txt-link-freetext" href="http://rock.opendfki.de/ticket/419">http://rock.opendfki.de/ticket/419</a><br>
<br>
<blockquote
cite="mid:CAKDpF4QLVgNH+5Zg+9zTtr=13FAb4jcHwbE9ty_6P-kiksjCrg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<br>
</div>
<div>Sylvain</div>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Tue, Apr 8, 2014 at 4:13 PM,
Alexander Duda <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:Alexander.Duda@dfki.de" target="_blank">Alexander.Duda@dfki.de</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">On 04/08/2014 03:55 PM, Javier Hidalgo Carrió
wrote:<br>
> On 04/08/2014 03:10 PM, Alexander Duda wrote:<br>
>> On 04/08/2014 03:04 PM, Javier Hidalgo Carrió
wrote:<br>
>>>> The reason is that each axis could
control several sub-axes.<br>
>>> How many axis go to each sub-axes
(sub-joystick)? How do you map then?<br>
>>> ... The first two one, the first three
ones...<br>
>> I would say, the naming is really bad. In
general, an axis is defined<br>
>> as a 1D line.<br>
>>>> The idea behin is that one
one-dimensional arrays does not scale very<br>
>>>> whell with different kind of
input-devices.<br>
>>>> In the past it was one 1D array. We
decided to change this.<br>
>>> Actually I think that 1D array scale better
with different kind of<br>
>>> input<br>
>>> devices just because it is a plain 1D.<br>
>> Yes, the mapping could also be done with a single
std::vector which<br>
>> would at least to me more natural. But the
question is is, it worth<br>
>> to change everything?<br>
> I also asked myself this question. In that case it is
not worthy but<br>
> in reality it doesn't seem to be that much.<br>
</div>
> n/scale<br>
<div class="">> Only two things so far:<br>
> 1) Change the RawCommand struct which is NOT a base
type<br>
> 2) The method in JoystickTask.cpp to map from
RawCommand to<br>
> MotionCommand2D (rotational and translation
velocity).<br>
><br>
> Also... there is a property in the current version of
the controldev<br>
> component:<br>
> property("axisScale","/std/vector<double>")<br>
> which is a std::vector (not a
std:vector<std::vector> ). Therefore it<br>
> will play nicer with 1D array.<br>
> I don't want to pollute the mailing-list with this
topic. My<br>
> suggestion: I could make the changes in a different
branch and in case<br>
> it is not the way of going we could always go back or
find a merge<br>
> point. Do you agree?<br>
><br>
> Javier.<br>
</div>
I would always try to avoid branching away. Therefore, the
best think<br>
would be to convince Matthias as he is the guy maintaining
condrolDev.<br>
Personally, I would like to see the proposed change because
like you<br>
said it would have the same syntax like axisScale.<br>
<br>
In any case, you have to do some kind of mapping insight the
component<br>
to get a proper motion command.<br>
<br>
Greets Alex<br>
<div>
<div class="h5"><br>
>><br>
>> enum Axes<br>
>> {<br>
>> axis1_x<br>
>> axis1_y<br>
>> axis2_x<br>
>> ..<br>
>> };<br>
>> a[axis1_x] = 123<br>
>><br>
>> Alex<br>
>><br>
>>>> If you have multiple input deviced, the
mapping should be done by a<br>
>>>> conversion component. There could be no
generic rule how to apply<br>
>>>> RawCommands to something else.<br>
>>>><br>
>>>> You joystick-driver should output the
values from the Joysticks as<br>
>>>> they<br>
>>>> are. The mapping for your rover's
should be done in a specialized<br>
>>>> component.<br>
>>> Therefore the especialized component should
compute e.g.: 2D commands<br>
>>> from a common RawCommand.<br>
>>> From my point of view the RawCommand
should be generic and therefore<br>
>>> raw (plain). Unless there is a way of
asking to the Linux api:<br>
>>> number of<br>
>>> sub-joysticks to create this 2D array. I
still don't see it.<br>
>>><br>
>>> Javier.<br>
>>>> So no i'm against a change here.<br>
>>>><br>
>>>> Best,<br>
>>>> Matthias<br>
>>>><br>
>>>> On 08.04.2014 14:32, Javier Hidalgo
Carrió wrote:<br>
>>>>> Hi rocks!<br>
>>>>><br>
>>>>> Is there any particular reason why
the axisValue is a 2D array?<br>
>>>>><br>
>>>>> /* Index 1: num-of input axis,
//index 2: dimensions of this<br>
>>>>> axis<br>
>>>>> * If you have an
gamepand which has 2 2Dknops you<br>
>>>>> have an [2][2]<br>
>>>>> * size'd array for an
3D Mouse you could have [1][6]<br>
>>>>> */<br>
>>>>>
std::vector<std::vector<double> > axisValue;<br>
>>>>><br>
>>>>> Why not to create a plain
std::vector<double> instead?<br>
>>>>><br>
>>>>> I am controlling with a joystick
the ESA rover and there are several<br>
>>>>> types of joysticks. They do not all
have 4 axis in the main/principal<br>
>>>>> joystick.<br>
>>>>> Therefore, I do not see the benefit
of having a std::vector inside<br>
>>>>> another std::vector.<br>
>>>>> My suggestion is to change it to a
plain (1D array) std::vector<br>
>>>>> and use<br>
>>>>> the first 4 axis as it is now but
without a 2D structure.<br>
>>>>><br>
>>>>> Javier.<br>
>>>>><br>
>>>>><br>
>>>>>
_______________________________________________<br>
>>>>> Rock-dev mailing list<br>
>>>>> <a moz-do-not-send="true"
href="mailto:Rock-dev@dfki.de">Rock-dev@dfki.de</a><br>
>>>>> <a moz-do-not-send="true"
href="http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev"
target="_blank">http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev</a><br>
>>><br>
>>><br>
>>>
_______________________________________________<br>
>>> Rock-dev mailing list<br>
>>> <a moz-do-not-send="true"
href="mailto:Rock-dev@dfki.de">Rock-dev@dfki.de</a><br>
>>> <a moz-do-not-send="true"
href="http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev"
target="_blank">http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev</a><br>
>><br>
>><br>
><br>
><br>
<br>
<br>
--<br>
</div>
</div>
<div class="">Dipl.-Ing. Alexander Duda<br>
Unterwasserrobotik<br>
Robotics Innovation Center<br>
<br>
</div>
<div class="">Hauptgeschäftsstelle Standort Bremen:<br>
DFKI GmbH<br>
Robotics Innovation Center<br>
Robert-Hooke-Straße 1<br>
28359 Bremen, Germany<br>
<br>
</div>
Tel.: <a moz-do-not-send="true"
href="tel:%2B49%20421%20178%2045-6620"
value="+49421178456620">+49 421 178 45-6620</a><br>
<div class=""> Zentrale: <a moz-do-not-send="true"
href="tel:%2B49%20421%20178%2045-0" value="+49421178450">+49
421 178 45-0</a><br>
Fax: <a moz-do-not-send="true"
href="tel:%2B49%20421%20178%2045-4150"
value="+49421178454150">+49 421 178 45-4150</a> (Faxe
bitte namentlich kennzeichnen)<br>
</div>
E-Mail: <a moz-do-not-send="true"
href="mailto:Alexander.Duda@dfki.de">Alexander.Duda@dfki.de</a><br>
<div class="im HOEnZb"><br>
Weitere Informationen: <a moz-do-not-send="true"
href="http://www.dfki.de/robotik" target="_blank">http://www.dfki.de/robotik</a><br>
-----------------------------------------------------------------------<br>
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz
GmbH<br>
Firmensitz: Trippstadter Straße 122, D-67663
Kaiserslautern<br>
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang
Wahlster<br>
(Vorsitzender) Dr. Walter Olthoff<br>
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A.
Aukes<br>
Amtsgericht Kaiserslautern, HRB 2313<br>
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)<br>
USt-Id.Nr.: DE 148646973<br>
Steuernummer: 19/673/0060/3<br>
<br>
</div>
<div class="HOEnZb">
<div class="h5">_______________________________________________<br>
Rock-dev mailing list<br>
<a moz-do-not-send="true" href="mailto:Rock-dev@dfki.de">Rock-dev@dfki.de</a><br>
<a moz-do-not-send="true"
href="http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev"
target="_blank">http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Rock-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Rock-dev@dfki.de">Rock-dev@dfki.de</a>
<a class="moz-txt-link-freetext" href="http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev">http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev</a>
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Dipl.-Inf. Matthias Goldhoorn
Space and Underwater Robotic
Universität Bremen
FB 3 - Mathematik und Informatik
AG Robotik
Robert-Hooke-Straße 1
28359 Bremen, Germany
Zentrale: +49 421 178 45-6611
Besuchsadresse der Nebengeschäftstelle:
Robert-Hooke-Straße 5
28359 Bremen, Germany
Tel.: +49 421 178 45-4193
Empfang: +49 421 178 45-6600
Fax: +49 421 178 45-4150
E-Mail: <a class="moz-txt-link-abbreviated" href="mailto:matthias.goldhoorn@informatik.uni-bremen.de">matthias.goldhoorn@informatik.uni-bremen.de</a>
Weitere Informationen: <a class="moz-txt-link-freetext" href="http://www.informatik.uni-bremen.de/robotik">http://www.informatik.uni-bremen.de/robotik</a></pre>
</body>
</html>