[Rock-dev] Joystick and twice a std vector in RawCommand

Matthias Goldhoorn matthias.goldhoorn at dfki.de
Tue Apr 8 15:15:22 CEST 2014


I completly don't understand sorry
Let's choose a minimal RC-Control:

This have 2 major input devices (left and right stick), each stick can 
control 2 axis, this results in a array of [2][2].

The Logitech freedrom joystick has one "joystick" and one slider

[0].size() == 3 (3 axis for joystick itself)
[1].size() == 1 (because it's simply a slider)

this is really more straight forward instead of mixing controlling inputs...

Matthias

On 08.04.2014 15:10, 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?
>
> 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
>>>> Rock-dev at dfki.de
>>>> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
>>
>> _______________________________________________
>> Rock-dev mailing list
>> Rock-dev at dfki.de
>> 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:  matthias.goldhoorn at informatik.uni-bremen.de

  Weitere Informationen: http://www.informatik.uni-bremen.de/robotik



More information about the Rock-dev mailing list