albintre / aforge

Automatically exported from code.google.com/p/aforge
Other
0 stars 0 forks source link

Added support for MotorControl #240

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Describe the fix or new feature which you would like to contribute to the 
project ...

I've added commands to support the MotorControl program running on the Lego NXT 
brick.

For more detailed info on MotorControl read here : 
http://www.mindstorms.rwth-aachen.de/trac/wiki/MotorControl

This gives two new commands :

SetMotorControlState() has four states : None, HoldBrake, SpeedRegulation, 
SmoothStart

GetMotorControlState() returns whether the motor is running or not. Currently 
this seems to have a 1 or 2sec delay and doesn't work as well as I'd like.

Original issue reported on code.google.com by wilmotst...@gmail.com on 10 Aug 2011 at 3:50

Attachments:

GoogleCodeExporter commented 9 years ago
To further elaborate on the commands

I've followed Andrew's lead throughout and so MotorControl Commands are 
implemented almost exactly as with the classic direct motor commands. The only 
real difference is that SetMotorControlState() also has an 'IsMotorReady' 
command send this to the brick and then use GetMotorControlState() to retrieve 
the response from the brick.

Original comment by wilmotst...@gmail.com on 10 Aug 2011 at 4:00

GoogleCodeExporter commented 9 years ago
The idea seems to be interesting, however did not try running it ...

Anyway, few comment about the code:

1) Personally I would prefer having additional class, which interfaces with the 
MotorControl application. This application is not standard and is not loaded 
onto NXT brick by default. So I would prefer keeping all custom stuff in a 
separate class. Plus it will increase maintainability of the code.

2) Documentation for new methods does not say anything about the fact that user 
must load additional RXE onto the brick to make those commands working.

3) Camel notation must be used and underscores should be avoided. Thing like 
CONTROLLED_MOTORCMD are not acceptable. It should be ControlledMotorCommand, 
for example.

4) Documentation like this is not acceptable, since it does not really tell 
much: "<returns>Returns Boolean result of Message.</returns>". If the intention 
was to write something like "/// <returns>Returns true if command was executed 
successfully or false otherwise.</returns>", then it must be written so.

5) 
/// <summary>
/// Not yet implemented.
/// </summary>
JUMBOPACKET = 0x35,

If it is not implemented, then why do we need it in documentation? It could be 
put as a comment in code, so developers could see it, but does not have much 
sense when exposed to user. Plus SetMotorControlState() does not throw 
exception or anything to tell about unsupported command.

6)
>> GetMotorControlState() returns whether the motor is running or not.
>>Currently this seems to have a 1 or 2sec delay and doesn't work as well
>> as I'd like.
Does not sound nice :(

Original comment by andrew.k...@gmail.com on 23 Aug 2011 at 1:19

GoogleCodeExporter commented 9 years ago

Original comment by andrew.k...@gmail.com on 8 Feb 2012 at 10:02