I have just completed a little project to simulate a Wii remote control with a Tilt (Acceleration) sensor and Bluetooth comms.

One NXT has the Tilt sensor attached pointing forwards and acts as the controller. You hold the NXT sideways at an angle to the vertical and use it as a steering wheel. Tilting away from you increases the speed. Tilting backwards decreases the speed and then goes into reverse.

I used the Mindsensors ACCL-Nx-3g3x sensor, but am only using the X and Y Tilt values. It should work with any of the mindsensors or HiTechnic acceleration sensors.

The other NXT uses a Pilot class to steer a wheeled vehicle. It works quite well, but it could do with a bit more work on the programs to achive finer contol.

Here is the controller program. You will need to change the name of your NXT, and make sure you have added it to the Bluetooth devices.

Yes, control of the steering could be better. I meant it mainly as a proof of concept. I am sure a real project could be made to work better by adjusting timings and values, and the Pilot methods used. It is not too bad at low speed but gets a bit out of control at higher speeds.

It is a good idea to acknowledge data that is sent, by sending an "Ack" message back to the sender. If you don't do this the sender is likely to send data faster than the receiver can process it, and comms buffers will fill up. I am not sure that the leJOS Bluetooth code copes with streaming data without acknowledgments to slow it down. You may lose data if you do not use acknowledgements or other replies.

I noticed that if you doesnt add another brick in Tilt NXT then Tilt NXT crash.

In BT methods it is neccesary to improve connect method, because if RemoteSteer doesnt run in NXT brick 2, TiltController BRICK think that it is connected with NXT brick 2.

I will try to improve method to turn bot in NXT Brick 2

You must run the receiver program (RemoteSteer) first. The leJOS menu program waits for a connection over Bluetooth and treats data that it receives as LCP commands. This is how it implements program upload etc. If you run TiltController when the receiver brick is running the menu, the connection will succeed, but the reeceiver brick will interpret all the data sent as LCP commands and will probably throw an exception.

This is a bug in Connect() which I plan to fix in the next release. Currently it interprets any replies it gets from a connect request as success - even failure replies. This means that if the target brick does not exist or if it has not been added to the Device menu on the sender machine, then successful connection will be reported, even when the connection has failed. I don't think this happens if the receiver brick is just switched off - in this case the sender just hangs trying to connect.

Lawrie, thanks for your advice with ack sentence. ack is used as flag to know that it is the moment to send another command.

I have tried my code, but I have noticed that in some moment the communication broke. I am going to test a timer thread that use a shared variable between timer thread and Tilt thread to maintain the communication.

If system detect that in 10 seconds, doesnt receive any communication, ack for example then close the communication and try to reconnect. this mechanics will try to do in receiver, in RemoteListener thread.