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 <[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] > >>>>> 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.-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: [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] > 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
