Unreliable Bluetooth direct commands with NXT 2

[barbolani2]

Hello, all.

I thought it could be fun and nice to have a radio control style car, with one motor driving the rear train, regulating speed, and another driving the front wheels for direction. It would be a nice toy that could engage my kids into this fascinating world. My plan was to add another model to what is already supported by the "Mindroid" Android app (see https://github.com/NXT/LEGO-MINDSTORMS-MINDdroid), which allows robot control by tilting the Android device. The existing Mindroid developers were enthusiast and supportive of the idea. Since all the current Mindroid models have one motor attached to one wheel and control robot direction by varying the speed of each motor, I assumed that I had to introduce some changes, refactor, etc.

So I created the simplest Lego model that could work borrowing ideas from everyere and finally had a very simple car design. Then it came the time to change the Mindroid application. After some refactoring and clean up, I was ready to add my model to the Mindroid app. Basically the front motor handling the driving wheels only needs to turn left or right a few degrees (never more than 45º) according to the tilt of the Android device. My plan was to use the SetOutputState command with TachoLimit and Power values accordingly. Docs and searches both pointed out to the overshoot problem when turning the motor, so I anticipated some problems when the tablet was not tilted and the motor did not return to the exact center position. I assumed that I could solve the problem somehow, but for the first version I was aiming for something that I could understand.

(by the way, has anyone noticed the bug in the LEGO docs about the TachoLimit being in bytes 8-12 of the command packet? It is supposed to be a 4 byte value, not 5 byte value)

This is when I ran into the problem: the front wheel did not work as it should. I created a toy Android app to send discrete SetOutputState commands with different parameter values. To my surprise, I found that the SetOutputState command is plainly ignored about 4 out of 5 times. I've also found that there is a higher chance of the command being executed when TachoLimit<>0 if you use lower power levels (below 50%) than with higher ones. In higher power levels the "overshoot" can amount to a few extra complete turns even if you ask for a 10 degree rotation. Even so, I never get an error on command result regardless of using the response required option or not. And the TachoLimit parameter behaves in a weird way when you reverse the direction of the motor between one command and the following (it seems to turn into the complement of the angle you request)

About the only thing that gives the appearance of reliability is what the Mindroid app does, sending a few times per second a SetOuputState command with the motor power values and hoping that if you do that fast enough some of these messages will not be dropped, creating the illusion of continuous movement.

I did a few Google searches and found that there are all sorts of firmware replacements for the NXT, even some of them add a "MotorControl" program running in the brick that provides precise motor movement control. Maybe by using one of these I'll get the results I want, but I'm afraid that flashing firmware falls outside the scope and skill set of a 10-12 year kid.

My question is, Is this protocol really so unreliable? Or is there something wrong with my approach? I'm not aiming for high precision here, anyone can tolerate a small error when returning to neutral. Granted, NXT is a toy. But I find hard to believe it has such a flawed implementation, especially if you have relatively high reliable movement using the LEGO LabView-like software.

So where you'd start looking?

(oh, apologies, it has turned into a rather long post after all)

[HaWe]

hi,
to my experiences BT communication ever was an issue for the Lego compatible firmwares, e.g. there have been lot of reports about data loss, data collision, and data corruption.
As once a Labview user explained to me, Labview is supposed to use intergrated send-and-return-acknowledge-message-schemes which make BT communication a little more reliable (but admittedly also slower).
For a VERY slow communication (send+receive acknolwlege, maybe up to 4 messages per second) it might work more or less (actually just for 1 slave, problems increasing with the increasing number of slaves)
A reliable BT (and rs485) communication protocol ever was missing in the standard and the enhanced firmware, no transmission control protocol so far, AFAIK just Lejos got simple but in some degrees more reliable BT protocols (e.g., nxj-chat, bitbus protocol).
I personally once suggested (at least for small nets) to set up sth like a Aloha protocol or a TokenRing, but unfortunatley it found no positive echo.

[barbolani2]

Thanks for your response, Helmut

Are you saying essentially that I should forget about my goal of a simple car robot remotely controlled via Bluetooth? If so, do you think it can be done by using alternative implementations of the brick's firmware?

I can always convert the design to something like the Race Car here http://www.nxtprograms.com/NXT2/race_car/ , although it is obviously less attractive. We'll miss the party trick of saying to your friends that you can control with your hand motions your Lego car (while holding the Android remote control with the other hand on your back, of course )

[HaWe]

no, I won't recommend to give it up, slow remote controlling (not actually in real-time) should be possible in some degree...
but it still is a challenge and not quite trivial upon the given shaky fw groundwork...