On 08.04.2014 16:21, Sylvain Joyeux wrote:
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)
There were two different things in this discussion:
- using the controldev to directly output MotionCommands
--- I removed this feature because it's not generic doable to create
motion commands from joysticks.
- Using 1D vs. 2D arrays
Even a conversion might be more complicated. We now using a RC-Control
and it's really horrible to have only one 1D array.
It produces more faults in the usage from my experience.
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.
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.
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.
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 ?
It's started but not completely tested:
http://rock.opendfki.de/ticket/419
Sylvain
On Tue, Apr 8, 2014 at 4:13 PM, Alexander Duda <[email protected]
<mailto:[email protected]>> wrote:
On 04/08/2014 03:55 PM, Javier Hidalgo Carrió wrote:
> On 04/08/2014 03:10 PM, Alexander Duda wrote:
>> On 04/08/2014 03:04 PM, Javier Hidalgo Carrió wrote:
>>>> The reason is that each axis could control several sub-axes.
>>> How many axis go to each sub-axes (sub-joystick)? How do you
map then?
>>> ... The first two one, the first three ones...
>> I would say, the naming is really bad. In general, an axis is
defined
>> as a 1D line.
>>>> The idea behin is that one one-dimensional arrays does not
scale very
>>>> whell with different kind of input-devices.
>>>> In the past it was one 1D array. We decided to change this.
>>> Actually I think that 1D array scale better with different kind of
>>> input
>>> devices just because it is a plain 1D.
>> Yes, the mapping could also be done with a single std::vector which
>> would at least to me more natural. But the question is is, it worth
>> to change everything?
> I also asked myself this question. In that case it is not worthy but
> in reality it doesn't seem to be that much.
> n/scale
> Only two things so far:
> 1) Change the RawCommand struct which is NOT a base type
> 2) The method in JoystickTask.cpp to map from RawCommand to
> MotionCommand2D (rotational and translation velocity).
>
> Also... there is a property in the current version of the controldev
> component:
> property("axisScale","/std/vector<double>")
> which is a std::vector (not a std:vector<std::vector> ).
Therefore it
> will play nicer with 1D array.
> I don't want to pollute the mailing-list with this topic. My
> suggestion: I could make the changes in a different branch and
in case
> it is not the way of going we could always go back or find a merge
> point. Do you agree?
>
> Javier.
I would always try to avoid branching away. Therefore, the best think
would be to convince Matthias as he is the guy maintaining condrolDev.
Personally, I would like to see the proposed change because like you
said it would have the same syntax like axisScale.
In any case, you have to do some kind of mapping insight the component
to get a proper motion command.
Greets Alex
>>
>> enum Axes
>> {
>> axis1_x
>> axis1_y
>> axis2_x
>> ..
>> };
>> a[axis1_x] = 123
>>
>> Alex
>>
>>>> If you have multiple input deviced, the mapping should be
done by a
>>>> conversion component. There could be no generic rule how to apply
>>>> RawCommands to something else.
>>>>
>>>> You joystick-driver should output the values from the
Joysticks as
>>>> they
>>>> are. The mapping for your rover's should be done in a specialized
>>>> component.
>>> Therefore the especialized component should compute e.g.: 2D
commands
>>> from a common RawCommand.
>>> From my point of view the RawCommand should be generic and
therefore
>>> raw (plain). Unless there is a way of asking to the Linux api:
>>> number of
>>> sub-joysticks to create this 2D array. I still don't see it.
>>>
>>> Javier.
>>>> So no i'm against a change here.
>>>>
>>>> Best,
>>>> Matthias
>>>>
>>>> On 08.04.2014 14:32, Javier Hidalgo Carrió wrote:
>>>>> Hi rocks!
>>>>>
>>>>> Is there any particular reason why the axisValue is a 2D array?
>>>>>
>>>>> /* Index 1: num-of input axis, //index 2: dimensions of
this
>>>>> axis
>>>>> * If you have an gamepand which has 2 2Dknops you
>>>>> have an [2][2]
>>>>> * size'd array for an 3D Mouse you could have
[1][6]
>>>>> */
>>>>> std::vector<std::vector<double> > axisValue;
>>>>>
>>>>> Why not to create a plain std::vector<double> instead?
>>>>>
>>>>> I am controlling with a joystick the ESA rover and there are
several
>>>>> types of joysticks. They do not all have 4 axis in the
main/principal
>>>>> joystick.
>>>>> Therefore, I do not see the benefit of having a std::vector
inside
>>>>> another std::vector.
>>>>> My suggestion is to change it to a plain (1D array) std::vector
>>>>> and use
>>>>> the first 4 axis as it is now but without a 2D structure.
>>>>>
>>>>> Javier.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Rock-dev mailing list
>>>>> [email protected] <mailto:[email protected]>
>>>>> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
>>>
>>>
>>> _______________________________________________
>>> Rock-dev mailing list
>>> [email protected] <mailto:[email protected]>
>>> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
>>
>>
>
>
--
Dipl.-Ing. Alexander Duda
Unterwasserrobotik
Robotics Innovation Center
Hauptgeschäftsstelle Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 1
28359 Bremen, Germany
Tel.: +49 421 178 45-6620 <tel:%2B49%20421%20178%2045-6620>
Zentrale: +49 421 178 45-0 <tel:%2B49%20421%20178%2045-0>
Fax: +49 421 178 45-4150 <tel:%2B49%20421%20178%2045-4150> (Faxe
bitte namentlich kennzeichnen)
E-Mail: [email protected] <mailto:[email protected]>
Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
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
_______________________________________________
Rock-dev mailing list
[email protected] <mailto:[email protected]>
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
_______________________________________________
Rock-dev mailing list
[email protected]
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
--
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: [email protected]
Weitere Informationen: http://www.informatik.uni-bremen.de/robotik
_______________________________________________
Rock-dev mailing list
[email protected]
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
