Mindboards

Posted: **06 Jun 2011, 11:27**

Hello,

After posting over at the aforge forums about precise motor positioning with C# & direct commands, Linus came to my aid and suggested I look into his MotorControl system. It seemed to do exactly what I needed and so I set about expanding on the great work Andrew had done with aforge to provide MotorControl commands. Everything now works great except for one thorny issue .. the IsMotorReady command seems to have a very severe lag.

At first I thought it could be down to my lack of C# experience and so I hacked apart the bluetooth testing software found here : http://www.codeproject.com/KB/cs/nxtBluetooth.aspx to make a little test program so I could be sure that it wasn't anything I'd broken in aforge.

However I see exactly the same behaviour, I send a MotorControl command .. the motor starts spinning, I then manually send a series of IsMotorReady commands and I initially get a positive response (whilst the motor is moving), I keep sending IsMotorReady commands and eventually get a negative response, the motor stops I get a few more false responses followed by positive. It's as though IsMotorReady is offset by at least 2 seconds. I'm leaving all the 30ms (and more) pauses that Linus recommends in his documentation.

I've packaged up the source and compiled program here:

MotorControl_Communication.zip: c# source & application; (96.69 KiB) Downloaded 248 times

The MotorControl command in the text box will move Motor B and the IsMotorReady command will check if Motor B is ready. A response of 31 31 means the motor is ready whilst 31 30 means the motor is currently moving.

I wonder if anyone else with MotorControl installed on their NXT would be able to try and repeat these results or has seen similar behaviour in the past ?

Many thanks,
ben

Posted: **06 Jun 2011, 13:03**

Hi Ben,

glad you found your way to these forums

Unfortunately I don't have an NXT brick atm, so I can't test your program. I can however help you debugging a bit...

If you've got MATLAB, you can use the RWTH toolbox and use the command "DebugMode on" (but not before the call to "clear all"). This should display all binary packets that are sent to the NXT (and I think also the answers collected). You can also issue commands from the MATLAB command window via the console. Then you could make sure that your binary packets are exactly the same packets that we send and receive.
The NXC MotorControl program has many debug options. Unfortunately they are not documented, and I forgot which ones can be used in combination with each other. They can be enabled here: http://www.mindstorms.rwth-aachen.de/tr ... r.nxc#L110 . Then you need to to re-compile and re-transfer to the NXT brick, of course. You could search all the NXC source files for the debug options (like ENABLEDEBUGGING_LCD_SLOW_ANTIBUG) and see where they have an effect. I remember that some of them show timing and/or packet infos.
I particularly remember the ENABLEDEBUGGING_REMOTELOGGING option. It then works together with a remote logging server. The very simple core program (MATLAB) is here: http://www.mindstorms.rwth-aachen.de/tr ... ngServer.m . Since MATLAB doesn't support multi-threading, I started this remote logging server via a GUI (the GUI has callbacks, so this feels like multi-threading). The GUI is here: http://www.mindstorms.rwth-aachen.de/tr ... ngServer.m . The fig-file is also in that folder. This whole thing should show a log of all communication with the NXT, including msg numbers and timestamps, that you can analyze.
General (simple) benchmarks to test the speed of the NXC <-> PC message queue interface are available here: http://www.mindstorms.rwth-aachen.de/tr ... munication . If they have the same lag, then your problem is not with MotorControl.
From the commit-messages I conclude that nxt-python has support for MotorControl. http://code.google.com/p/nxt-python/. Maybe grab a copy and see if it works as expected...
If nothing else helps, here are generic tips for debugging NXC-programs: http://sourceforge.net/apps/phpbb/mindb ... ?f=3&t=182

I had a quick look at your source, but I can't spot anything obviuosly wrong (and unfortunately, my Visual Studio only likes C++, no C# projects). But are you sure about this:

Code: Select all

        private void buttonIsMotorReady_Click(object sender, EventArgs e)
        {
            byte[] NxtMessage = { 0x00, 0x09, 0x00, (byte)3, 0x00, 0x00, 0x00};

If this is the ISMOTORREADY command from the MotorControl documentation, then remember that the port number has to be a CHAR, not an INT. So if you want to ask for the status of motor A, use 0x30 or 48, i.e. ASCII code for '0'. But this is just a first quick guess...

Posted: **06 Jun 2011, 13:25**

Hi Linus,

I'll look into those debugging options tonight, thank you.

I think that (byte)3 code is left over from my messy debugging, that byte code is overwritten by the text input box .. which is currently "33" for the IsMotorReady command and then "31" for motor B.

thanks
ben

Posted: **06 Jun 2011, 13:43**

mrbencowell wrote: which is currently "33" for the IsMotorReady command and then "31" for motor B.

Ok, just to make sure: I can understand the "31" for motor B, but what about "33"?

Posted: **06 Jun 2011, 13:48**

33 being the "3" for the IsMotorReady command .. or do I have that wrong :/

Posted: **06 Jun 2011, 13:58**

Just checking through, the 3 was the length of the message that I'm writing to the NXT. Sorry .. I'm confusing myself !.

Mindboards

Communication with MotorControl

Communication with MotorControl

Re: Communication with MotorControl

Re: Communication with MotorControl

Re: Communication with MotorControl

Re: Communication with MotorControl

Re: Communication with MotorControl