Remote controll NXT with Bluetooth and GUI

[jonasbg]

Afters hours spending reading the API, and tutorials, example, I've finally given up on trying to understand how the bluetooth communication class in leJOS 0.85 works.

Prior to 0.85 as I understand, the iCommand class was used and lejos.pc.comm. But the API refers to lejos.nxt.comm class for bluetooth connection.

We're a group who would like to remotely controll our NXT robot with a nice GUI on our computers with the bluetooth protocol.
The aim is to controll three motors, and thereby enable the NXT to drive forward, backwards, swinging left and right and start/stop.

With example shipped with the NXT 0.85 (BTSend and BTRecieve) we're able to send a stream of int. So we're now at a point of knownledge where all we can do is sending stream of int's, and the have switch() cases to controll the robot.
My suspicion is that this will not be achieveable due to delays over bluetooth.



So in simple turms, how do one remotely controll an NXT unit with bluetooth from PC in leJOS 0.85?

[DerSani]

Hey,

Have a look at the TachoCount Project in pcsamples, run it and play with it.

It's LEGO, the only way to learn something is to do it. If you only read Tuts, docs and whatever, you get a mass of stupid knowledge, you must go wrong to make it right.

If you have a problem with explicit code, you may post it and you would get help.

DerSani

[burti]

With example shipped with the NXT 0.85 (BTSend and BTRecieve) we're able to send a stream of int. So we're now at a point of knownledge where all we can do is sending stream of int's, and the have switch() cases to controll the robot.
My suspicion is that this will not be achieveable due to delays over bluetooth.

So in simple turms, how do one remotely controll an NXT unit with bluetooth from PC in leJOS 0.85?

You are wrong. You can even exchange strings between pc and nxt!
By the way, I tried something like that out with ints.
Have a look on:
http://www.youtube.com/watch?v=JDNDCYFOr5w.
I can publish you the code if you want. It's very easy

[kellogg]

With example shipped with the NXT 0.85 (BTSend and BTRecieve) we're able to send a stream of int. So we're now at a point of knownledge where all we can do is sending stream of int's, and the have switch() cases to controll the robot.
My suspicion is that this will not be achieveable due to delays over bluetooth.

So in simple turms, how do one remotely controll an NXT unit with bluetooth from PC in leJOS 0.85?

You are wrong. You can even exchange strings between pc and nxt!
By the way, I tried something like that out with ints.
Have a look on:
http://www.youtube.com/watch?v=JDNDCYFOr5w.
I can publish you the code if you want. It's very easy

Could you please publish your code. thnx -k

[SpikeT]

So in simple turms, how do one remotely controll an NXT unit with bluetooth from PC in leJOS 0.85?

I posted a code on how to do it via USB over here
viewtopic.php?t=1723

You can easily make it to work over the bluetooth but first make sure that
your windows did recognize NXT.

[burti]

sorry. I had a lot to do the last weeks.
Here you are:
http://www.cip.ifi.lmu.de/~mirwaldt/Nxt_RemoteControl.zip
http://www.cip.ifi.lmu.de/~mirwaldt/PC_RemoteControl.zip.

Some remarks:

Compile and upload the project Nxt_RemoteControl to your nxt-brick.
The main-method is in the class BTServerCarSteer).
Default setting: LeftMotor=Motor.A, RightMotor=Motor.B.
You can increase the speed up to 800 (default is 400).
The Nxt_RemoteControl used a state machine to coordinate the movements. You can find 2 UML-diagrams in the doc-folder which give you detailed information which states are used and how (=which methods)

Compile and run the project PC_RemoteControl on your pc.
Pay attention that bluecove.jar and pccomm.jar are in your classpath. They are used to establish the bluetooth connection. You can find them in your lejos folder. As soon as you run it, it will automatically look for the nxtbrick.
How do you steer your car?
> Pay attention the focus is set on the focus button (you do it just by clicking on it). Then you can use you num pad on your keyboard.
7=>left
8=>forward
9=>right
5=>backward

As long as you hold the key pressed, your nxt moves into that direction. As soon as you release the key it the nxt stopps moving into that direction. You can press 2 keys at the same time, too.
E.g. You can make the nxt moving forward and right at the same time by pressing the keys 8 and 9 at the same time. Just experiment.
Sometimes there can occur the situation that a message get lost.
In those cases you nxt moves further although you released the button. it is a strange bug. Be careful!

Just try it out and tell me if it works for you.
I just want to point out that it's just a prototype. Don't expect it to be much tested and commented. I really wrote that program for myself.

Have fun,
Michael

[BHCluster]

Hi there
I did my thesis on this subject and it is posted here on the forum (http://lejos.sourceforge.net/forum/viewtopic.php?t=840). It is worth a look and if you have any questions just ask. As you will see the application which I have developed runs of your PC and with it you send commands to NXT which is running leJOS. Simple and efficient.
Hope it helps.

[joerg04]

Afters hours [..] trying to understand how the bluetooth communication class in leJOS 0.85 works. Prior to 0.85 [..] ICommand [..]
[..]
The aim is to controll three motors, and thereby enable the NXT to drive forward, backwards, swinging left and right and start/stop.
[..]
So in simple turms, how do one remotely controll an NXT unit with bluetooth from PC in leJOS 0.85?

As far as I understand the original question the answer should go to LCP (LEGO communication protocol), which works without installing Lejos-Firmware on the brick.
Despite not using Lejos on the brick, you can use the lejos model classes on the PC to control the (remote) NXT. You should be able to bring that to life (lejos-pc-code):

Code: Select all

NXTComm nxtComm = NXTCommFactory.createNXTComm(NXTCommFactory.BLUETOOTH);
NXTInfo nxtInfo = new NXTInfo(NXTCommFactory.BLUETOOTH, "NXT", "00:16:53:00:xx:xx");
nxtComm.open(nxtInfo);

NXTCommand command = new NXTCommand();
command.setNXTComm(nxtComm);
RemoteMotor engine = new RemoteMotor(command, 0 /*Port.A*/);
engine.forward();


I didn't know anything about icommand, but this nxtcommand seems to be the appropriate successor.

[Rockmaninoff]

sorry. I had a lot to do the last weeks.
Here you are:
http://www.cip.ifi.lmu.de/~mirwaldt/Nxt_RemoteControl.zip
http://www.cip.ifi.lmu.de/~mirwaldt/PC_RemoteControl.zip.

[...]

Hi burti, I took a look at your code and have some questions.

What exactly does the SteeringOperations class do? Is this some sort of Java functionality I don't know about? It looks like it decodes the int you transfer to the NXT, but within the class it just uses getNextID()? Could you explain how that works?

Also, how does your state machine actually work? Is the robot in a standing state unless some button is pressed? If so, what happens when a button is released, does it return to the standing state?

Thanks.

EDIT: Wow, so I looked at the code and for SteeringOperations (if I'm looking at this correctly) it seems pretty simple: a 1 for forward, 2 for backward, and so on for the rest of the commands. So if you wanted your robot to go forward, you would transfer a 1 over Bluetooth?

If I understand that correctly, I guess I still have a couple more questions:

First, does the code dictate that the robot stands if nothing is being passed to it? I suppose this is more along the lines of describing your state machine. Second, why is there a need for the key_released check?

Thanks again.

[burti]

Hi Rockmaninoff,
some answers to your questions:

What exactly does the SteeringOperations class do? Is this some sort of Java functionality I don't know about? It looks like it decodes the int you transfer to the NXT, but within the class it just uses getNextID()? Could you explain how that works?

I guess the name "SteeringOperations" might be confusing.
It must be "TransferCodes". It's nothing special. It's only a container for all those transfer codes. Of course, I could have used strings as well but I just decided to use integers.
The operation getNextID() is just a counter which delivers unique IDs which also serve as transfer codes.
The PC and the Nxt share that file. Thus "SteeringOperations" represents the protocol for their communication.

Also, how does your state machine actually work?

Have you had a look on the diagrams which are in PC_RemoteControl.zip (Class_Diagram__StateAdministration.png,
State_Machine_Diagram__StateDiagramm1__StateDiagrammKeysPressedAndReleased.png)? "State_Machine_Diagram__StateDiagramm1__StateDiagrammKeysPressedAndReleased.png" is a state machine diagramm which shows the states. Its implementation is illustrated in the class diagram "Class_Diagram__StateAdministration.png").
I feel it is difficult to put the state machine in words in detail. You can say about the state machine that each movement is represented by a state in general. There are transitions (=state changes) which have an event and an action. The state pattern was applied for its implementation. The first state is "Standing".
I hope you understand the diagrams, don't you?

Is the robot in a standing state unless some button is pressed?

Yes. The robot initializes the state machine with the "Standing"-state. Whenever you release all keys you were pressing,
the state machine gets into the "standing" state.

If so, what happens when a button is released, does it return to the standing state?

That depends whether it is the only key pressed at that time.
Given two scenarios:
1) You are pressing "8". The robot is moving forward. Then you release it. The robot stops and then stands. As long as you are pressing "8", the state machine has the state "MovingForward". As soon as as you release, the state changes to "Standing".
2) You are pressing "8". The state machine has the state "MovingForward". The robot is moving forward. Then you additionally press "9" (=Right) now (so you are pressing "8" AND "9").The state changes to "MovingRightForward". The robot is moving forward and right at the same time. Now you release "9". The state changes back to "MovingForward". The robot stops moving right but it is still moving forward. Thus the second scenarios is about how two movements interfere with each other (=how they run at the same time).

By the way, the state machine makes the motors stop or move or change its speed whenever the state changes (that means the state machine gets a signal which is delegated to the current state, then the current state makes the motors stop or move or change its speed and then returns the new state which is the next state).

EDIT: Wow, so I looked at the code and for SteeringOperations (if I'm looking at this correctly) it seems pretty simple: a 1 for forward, 2 for backward, and so on for the rest of the commands. So if you wanted your robot to go forward, you would transfer a 1 over Bluetooth?

I wished it to be simple before I discovered it isn't (if you want support all basic movements.)
When you press "8" (so that your robot moves forward) then TRANSFER_CODE_KEY_FORWARD_PRESSED is transferred which took the first value of the counter which is 0. So 0 is transferred over Bluetooth.

If I understand that correctly, I guess I still have a couple more questions:

First, does the code dictate that the robot stands if nothing is being passed to it?

Be careful: The PC says only when to begin and when to end a movement into a direction.
Example:
When you press "8", your robot begins to move forward. As long as your key is pressed, the robot is moving forward. As soon as you release "8", your robot stops moving forward. If you haven't another key pressed then it stops moving forward in order to stand.

So as long as you don't have a key pressed, the robot stands (it should at least .
When I began to program that, I used the keys as switches (that means when I wanted to move my robot forward then I pressed "8". If I wanted it to stop then I had press it again. Releasing a key was ignored). I felt the controlling of the robot was clumsy and difficult that way. That's why I took this approach which it has now. I feel it's easier and better.

Second, why is there a need for the key_released check?

I discovered a problem: my keyboard was not precise.
When I pressed or released a key, then there sometimes were more than one key event triggered which was quite disturbing (I don't know the reason).
For example:
I pressed "8" and the keyboard triggered the "key pressed"-event twice instead of once (which means the key event handler was called twice).
When I released the key, then a lot of "key released"-events were triggered instead of only one (and each resulted in a call of the event handler). The results on the robot were disturbing . So I had to cache and check the inputs the key event handlers deliver and to ignore events which orcurred twice or even more instead of once by accident.

Thanks again.

You are welcome

[Derchara]

How do i Compile this?
How do i deal with the dependencies?
I mean for example: Standing calls MovingBackward, and MovingBackward calls Standing...
When i compile Standing it says "MovingBackward not found", and when i try to compile MovingBackward, it says "Standing not found"

Can Someone help me, please?