search

magician-david / aforge

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

Provice additional (fast) methods to communicate with NXT brick (patch attached) #219

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
As you know I was working on my project. I came to an implementation which uses 
no reply when communicating with NXT brick which minimizes the communication 
delay between the PC and the brick. I hope you will find my patch useful.

Original issue reported on code.google.com by krzysztof.blacha on 16 May 2011 at 1:38

Attachments:

GoogleCodeExporter commented 8 years ago 
Added overloads for PlayTone(), SetMotorState(), ResetMotorPosition(), 
SetSensorMode(), ClearSensor() and LsWrite() methods of NXTBrick class, which 
can send commands without waiting for reply - faster versions.

Some improvements for serial communication with Lego NXT brick.

Committed in revisions 1488 and 1489. Will be released in version 2.2.0.

P.S. be careful with patches you sent
1)  A bug in Serial Communication
>> byte[] btRequest = new byte[message.Length + 2];
However the method receives offset and length parameters, so array’s Length 
must not be used.
2) In NXTBrick class you refer to SendCommandFast(), which was not provided in 
any of the patches.

Which tool did you use for creating these patches? TortoiseSVN refused to merge 
them.

Original comment by andrew.k...@gmail.com on 16 May 2011 at 8:29

GoogleCodeExporter commented 8 years ago 
Because I was a little out of sync with your sources (will try to catch up with 
2.2.0) and I needed to do some manual rewriting the patch. I probably did 
something wrong, sorry will try to avoid that.

My implementation of SendCommandFast looks like this:

/// <summary>
/// Send command fast
/// </summary>
private bool SendCommandFast(byte[] command, byte[] reply)
{
    lock (syncObj)
    {
        // check connection
        if (communicationInterface == null)
        {
            throw new NullReferenceException("Not connected to NXT brick");
        }

        // send message to NXT brick
        if (communicationInterface.SendMessage(command, command.Length))
        {
            // notifies clients if any
            if (MessageSent != null)
            {
                MessageSent(this, new CommunicationBufferEventArgs(command));
            }
            return true;
        } // if
    } // lock

    return false;
} // SendCommandFast

I was using WinMERGE but as I wrote it didn't broke the patch.

As for  1) I don't know what was the oryginal idea for offset and length but I 
remember they are always set to 0, and length and wasn't helpful when 
implementing this change. I could be wrong will check that. My idea was to 
eliminate two many port.Write to a single port.Write because this could 
generate some delays (I can imagine written data is encapsulated in some kind 
of frame and send via bluetooth). Of course you can and should customize this 
according to your requirements.

Original comment by krzysztof.blacha on 17 May 2011 at 9:14

GoogleCodeExporter commented 8 years ago 
By the way those fast commands helped me implement higher abstract interface 
(like move formward, turn, torate, coast, brake, etc.) which are working for 
both motors in sync. Would you like to see a patch with those changes as well? 
Maybe we could provide another class like "ExtendedNXTBrick" which could 
deliver them and not to mess up the oryginal class?

Original comment by krzysztof.blacha on 17 May 2011 at 9:18

GoogleCodeExporter commented 8 years ago 
Yes, it would be nice. I think new class, which an extension, would be better. 
However, we need to clarify the way to go. From the aforge.net forum it seems 
we may have different options …

Also, here is another thing to think about. As you said, you want to have an 
interface which says – turn robot 90 degrees left or right. How will you do 
it? As you know, it is possible to use gears while building NXT robot.  I did 
some work with it while building different robots … So, if people use 
different gears (or different amount of gears), it will take different number 
of tachos to rotate … So jus curious about your idea.

Original comment by andrew.k...@gmail.com on 19 May 2011 at 7:26

GoogleCodeExporter commented 8 years ago

Original comment by andrew.k...@gmail.com on 28 Jul 2011 at 9:48

GoogleCodeExporter commented 8 years ago

Original comment by andrew.k...@gmail.com on 10 Aug 2011 at 9:36