<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>
<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>
<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 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 href="mailto:Rock-dev@dfki.de">Rock-dev@dfki.de</a><br>
>>>>> <a 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 href="mailto:Rock-dev@dfki.de">Rock-dev@dfki.de</a><br>
>>> <a 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 href="tel:%2B49%20421%20178%2045-6620" value="+49421178456620">+49 421 178 45-6620</a><br>
<div class=""> Zentrale: <a href="tel:%2B49%20421%20178%2045-0" value="+49421178450">+49 421 178 45-0</a><br>
Fax: <a href="tel:%2B49%20421%20178%2045-4150" value="+49421178454150">+49 421 178 45-4150</a> (Faxe bitte namentlich kennzeichnen)<br>
</div> E-Mail: <a href="mailto:Alexander.Duda@dfki.de">Alexander.Duda@dfki.de</a><br>
<div class="im HOEnZb"><br>
Weitere Informationen: <a 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 href="mailto:Rock-dev@dfki.de">Rock-dev@dfki.de</a><br>
<a 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>