[Rock-dev] Joystick and twice a std vector in RawCommand
Sylvain Joyeux
bir.sylvain at gmail.com
Tue Apr 8 16:21:37 CEST 2014
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)
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 ?
Sylvain
On Tue, Apr 8, 2014 at 4:13 PM, Alexander Duda <Alexander.Duda at dfki.de>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
> >>>>> 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.-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
> Zentrale: +49 421 178 45-0
> Fax: +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
> E-Mail: Alexander.Duda at dfki.de
>
> 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
> Rock-dev at dfki.de
> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140408/8428f483/attachment.htm
More information about the Rock-dev
mailing list