[Rock-dev] CopterCommand to base/types

[Felix Rehrmann]

For sure there is no point in cluttering base/types with a diversity of 
command types.

But on the other hand if there are general types to be reused by a 
number of packets it would
be nice to have them in a central place. Example: Definig some command 
type in a Quadrocopter
driver and then the use the type in an airplane driver later,  would 
feel not so organized, too.

I think a generic command type is not the right thing to do 
(Circle-Driving could be given as radius and speed).
And for safety reasons it might be good to have command types that 
really fit the system, so that a command cannot
exchanged with another command that is not meant for it.

So command-type packets would be nice. In addition we could define 
command types in the specific packet. And if it is about
to become more generic, it could be moved to a generic command-type packet.

Felix

Am 29.05.2012 22:12, schrieb Matthias Goldhoorn:
> What about designing an ONE DataItem like the rbs?.
>
> could be:
>
> double[3] translation_velocity;
> double[3] position;
>
> double[3] rotation_velocity;
> double[3] target_orientation;
>
> this should cover all cases... (setting nan/inf simliar to the rbs)
>
> Otherwise we should move all types to specialized classes like
> RoverCommands, WaterVehicleCommands etc...
> I'm against real System specific commands, i vote for generic vehicle
> topic based packages, that should be part of rock (but not of base).
>
> Matthias
>
>
> Am 29.05.2012 17:33, schrieb Jakob Schwendner:
>> On 05/29/2012 05:22 PM, Leif Christensen wrote:
>>> On 29.05.2012 17:10, Matthias Goldhoorn wrote:
>>>> I also need an ASV Motion Command like:
>>>>
>>>> double translation[2];
>>>> double heading;
>>>>
>>>> We should discuss about generalize "motion commands"
>>>>
>>>>
>>>> Matthias
>>>>
>>>> On 29.05.2012 16:58, Jakob Schwendner wrote:
>>>>> On 05/29/2012 04:44 PM, Felix Rehrmann wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I would like to add a type CopterCommand to base/types.
>>>>>> It is to give commands to flying machines and will have 3 axis commands
>>>>>> and one thrust command:
>>>>>>
>>>>>> struct CopterCommand {
>>>>>>           double axis_command[3];
>>>>>>           double thrust;
>>>>>> };
>>>>>>
>>>>>> The value range would be from -1.0 to 1.0 for the axes and from 0.0 to
>>>>>> 1.0 for the thrust. Any opinions?
>>>>>>
>>>>> seems very system specific to me. Any reason this couldn't be defined in
>>>>> the module that requires it?
>>>>>
>>>>> Jakob
>>> I think I would not try to generalize motion commands at all, because of
>>> the wide range of inputs even for vehicles of similar classes. Think for
>>> example of all the different possible inputs for a quite narrow
>>> specified class of planar ackerman vehicles. Specifying such classes +
>>> deriving from them seems more work to me than directly define it in the
>>> vehicle specific modules.
>> +1 even the ones that are currently there could probably go into vehicle
>> class specific modules.
>>
>


-- 

  Felix Rehrmann
  Researcher

  DFKI Bremen
  Robotics Innovation Center
  Robert-Hooke-Straße 5
  28359 Bremen, Germany

  Phone: +49 (0)421 178 45-4129
  Fax:   +49 (0)421 218-64150
  E-Mail: felix.rehrmann 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
  -----------------------------------------------------------------------