Robo TX Controller mit Android?

[ulib]

Sehr geehrte Damen und Herren von Fischertechnik,

in der aktuellen Ausgabe der Computer-Zeitschrift c't wird auf S. 42 ein CubeSolver vorgestellt, der ...
"... besteht im Wesentlichen aus vier Lego-Mindstorms NXT-Bricks, die per Bluetooth mit einem Android-
Smartphone Samsung Galaxy II kommunizieren."

Auf diese Art und Weise (Android-Smartphone + Bluetooth) würde ich gerne meinen
Robo TX Controller im online-Modus steuern.

Besteht Hoffnung?
Beschäftigt sich jemand mit diesem Thema?

Viele Grüße,
Uli.

[Dirk Haizmann ft]

Hallo Uli,

zunächst möchte ich festhalten: es besteht IMMER Hoffnung !

Dass die Steuerung von ft-Modellen mit Handys, Smartphones o.ä. eine tolle Sache wäre haben wir schon
öfters diskutiert. Das Thema steht also durchaus auf unserer Entwicklungsliste... diese ist aber sehr lang.

Für die nächsten Tage, Wochen und Monate kann ich dir daher nichts versprechen.

Schaun mer mal...

ft

[vleeuwen]

Andriod has been design for other classes of use, see for example:
http://users.ece.gatech.edu/~vkm/Android_Real_Time.pdf.
The same for BlueTooth, this is also design for use in relation with streaming protocols.
For control engineering Zigbee and RF offers better performances.
See for example the Microchip website under wireless.
The basic issue for the general purpose fischertechnik interfaces is controlling actuators with the use of sensors and not playing with phones and streaming audio/video.
Maybe a good well documented RTOS (real-time operating system) suitable for control engineering could be a better alternative.
By the way, the original development board for this processor offers already two different and well documented OS’s.

[Ad2]

Hi,

The TX can be controlled over Bluetooth only in online mode, hence the program must be running on the phone and a kind of ftMscLib must be available for Android, also the Bluetooth RFCOMM layer mst be present but that is probably the case. At the moment there is no ftMscLib for Android, in fact there is no ftMscLib for the present FW (1.24) at all but I think it is possible to make one. Offline mode with the program on the TX and control by means of bluetooth messages (like RoboPro messages), is next to impossible because in that mode TXs will only communicate among each other. This has to to with MAC filtering and is not so easy to circumvent.

[vleeuwen]

For controlling a TX-C application you only need a application on your mobile that is able to deal with the BT-messages (radio calls).
That works in the on-line and off-line mode.
So you need an App that can act as node in the TX-C BT message network (start topology)

The problem is that the BT protocol for the BT-message is not public.

[Ad2]

A TX can communicate over bluetooth with a PC and with other TX's. For communication it uses the X1 protocol (described in the ftMscLib documentation). For communication to other TX's it uses a different protocol (both are embedded in the RFCOMM protocol). A TX discriminates between the two modes of connection based on MAC address. I found this out by experimentation so it's hard to know what exactly is going on, but it seems that all participants need an address in the range assigned to MOVON Corporation or an even more restricted range. When you contact a TX from an address outside this range it will enter X1, console or X-modem mode, depending on what you send. So at the very least you will have to spoof the BT MAC address.

[ft-ninja]

Another solution to control ROBO TX with handy: http://robotxcontrol.sourceforge.net/

[Dirk Fox]

Hi Gregory,

Another solution to control ROBO TX with handy: http://robotxcontrol.sourceforge.net/

three downloads and the hint "Take notice that this is a pre-alpha release, so it isn't perfect yet." - It seems that the solution needs some more pre-alpha-testers?

Regards, Dirk

[Defiant]

It looks like the sourceforge link is doing exactly what Ad2 wrote. Main stuff is written in robopro while the mobile phone is just sending commands. In this case the numbers pressed?

[ft-ninja]

Hi Gregory, three downloads and the hint "Take notice that this is a pre-alpha release, so it isn't perfect yet." - It seems that the solution needs some more pre-alpha-testers?

3 downloads for the last week and 279 for the last year. Pre-alpha-testers are welcomed.

It looks like the sourceforge link is doing exactly what Ad2 wrote. Main stuff is written in robopro while the mobile phone is just sending commands. In this case the numbers pressed?

Yes. The Midlet sends commands to remote shell when you press the number keys or tilt the joystick.

[Ad2]

Hi,

I was not aware of the solution found by ft-ninja. I see this as a viable alternative to my own solutions that do not work at the moment. ft-ninja stores compiled robopro programs on the TX which are loaded and started by the java applet running on the phone, the TX works offline. I don't have an android phone so I cannot experiment with it but the same can be done with a PC and a bluetooth connection. What it proves is that it is possible to run JAVA applets with Bluetooth connection on an Android phone and to connect over Bluetooth with the TX. This is very good! I am a bit worried about the response time because for each simple command a robopro program must be loaded and started. Furthermore, because the programs are independent it is very difficult to maintain a state. For example the TX cannot detect that key "1" followed by "0" actually means "10", this has to be resolved in the JAVA program. Another problem is that there is no return path.
What I was thinking about was also having the (java) program running on the phone but sending X1 commands instead of remote shell commands. There is no need to load programs but the X1 protocol is more complicated than the remote shell protocol and normally requires the ftMscLib. That lib is not available in JAVA but implementing a few basic commands should not be that hard. The TX would run in online mode.
The other alternative that I was thinking about was to have the TX in offline mode running a single RoboPro program that would respond to messages (send/receive blocks, radio call mechanism). The problem here is that a TX will only exchange these messages with another TX, not with a PC or a phone. Putting another TX in between will just shift the problem. So the challenge here is to mimic a TX with a phone.
At Schoonhoven I saw another interesting solution where an iPod was connected to a PC over WiFi which in turn controlled a TX over Bluetooth. Unfortunately I have no technical details about that solution.
At the moment it seems that ft-ninja has the best solution in the sense that it is relatively easy and it works. I think the online solution could also work and may be superior in some respects but it requires a lot of java programming and there is no support (yet) in the form of a library.

[ft-ninja]

What I was thinking about was also having the (java) program running on the phone but sending X1 commands instead of remote shell commands.

As I know the description for X1 protocol isn't released for public access at this moment. If it will be opened then it will be not a problem to port this protocol to the java on the handy.

Also I've tested robotxcontrol on several android smartphones and I've found that realization of the BT stack on these phones isn't compatible with TXC BT module.

[Ad2]

The X1 protocol is 'half open'. The general structure is disclosed the documentation that comes with the ftMscLib. What that document does not say is that the payload is a direct copy of a specific part of the TA. These parts themselves however are disclosed (TA_OUTPUT, TA_CONFIG etc.). Also the values of the command word that identifies the type of payload are not disclosed but they are easy to discover. The real problem is that ft changes the TA at almost every FW release.

Also I've tested robotxcontrol on several android smartphones and I've found that realization of the BT stack on these phones isn't compatible with TXC BT module.

That's a bummer, I had the impression that it was working. Any idea why not? When Android supports the SPP (Serial Port Profile) it should just work. Does the pairing work?

[ft-ninja]

That's a bummer, I had the impression that it was working. Any idea why not? When Android supports the SPP (Serial Port Profile) it should just work. Does the pairing work?

The pairing between TXC and Android works well. The main problem arises when you trying to get a BluetoothSocket by calling createRfcommSocketToServiceRecord(UUID). This method uses SDP lookup of uuid, but it seems that the TXC BT module does not support SDP as well

Tested devices: HTC Legend (OS version 2.2) and HTC Desire S (OS version 2.3.3).

[Ad2]

Hmmm, that is surprising. I have tested the SDP of the TX extensively (because I wrote an SDP client for MBED (Cortex M3)). On SDP requests it responds with the standard L2CAP, RFCOMM (port 1) reply. I'm pretty sure the UUID was the standard UUID mentioned in the assigned numbers. When I have time I will try to repeat the experiment and maybe, just maybe, I kept a logfile from some of the experiments. That would tell us at least what the TX expects and what it replies. The second slightly more difficult question is: What does Android ask and what does the TX reply (if at all). For this we may need to tap the communication between Bluetooth module and ARM processor.

[Ad2]

Couldn't find a logfile and unfortunately I don't have an android device. I found this link though http://developer.android.com/reference/ ... util.UUID) It states that you should use an InSecure connection.

[vleeuwen]

Is it possible that a mobile device with BT act as a node in the ft message system?
This will be the most simple way to use a mobile device as console for a TX-C application.
Sending/receiving ft-messages is a feature of RoboPro and the FtMscLib.
The only need to write a application for his mobile that can handle this messages.

The big advantage is that end user is able to use the TX-C in the online or offline mode and using RoboPro.

Ad implemented a similar solution for the Robo Interface to extend the RoboInterface with an internet connection (webserver).
The FT-message can be send on that Robo Interface over RS232.

[Ad2]

I agree that a phone or tab as a node in the messaging system would be the most elegant solution. But I fear that it is not possible because these messages (I call them BEEF messages because they all start with 0xBE 0xEF) can only be exchanged between one TX and another. A PC application can send an X1 message (14) to a TX telling it to send a BEEF message to another TX but it cannot send the message itself because the TX will not connect to the PC in BEEF mode. When a PC connects to a TX it establishes a virtual COM channel that allows communication in X1, remote shell or Xmodem 1K mode. When a TX connects to another TX it also establishes a virtual COM channel but there is a kind of handshake, the remote TX replies with a BEEF message containing CONN_ACK. There some other (probably flow control messages) as well but in the end the TX's exchange BEEF messages containing the usual 6 byte robopro messages (hwid, subid, cmd, msg). When a PC sends a BEEF message directly to a TX, the remote shell will just return something like <???> and ignore the message. So how does a TX know whether it is a PC or another TX at the other end of the BT connection. I'm pretty sure that this is based on the BT address. When I used a dongle with a spoofed BT address (in the same range as the TX BT addresses), it did start the handshake (I received the CONN_ACK) but the remote TX disconnected soon afterwards so there is more to this protocol than what I have discovered so far. So even if we reverse engineer the protocol we still have to deal with the address range. Spoofing a BT address is not always possible or easy.

[vleeuwen]

Thanks Ad,

Fischertechnik models controled by mobiles.

Lovely.
Here is a very big challenge for fischertechnik to make this possible.
This is something that end-user will like very much.
This will add something valuable for the "normal" fischertechnik target groups.
Very motivating for children.

A nice spin off will be that the PC can also be a node in the FT-message infrastructure.

[vleeuwen]

This brings me on a new suggestion.
The creation of a small WIFI +webserver plugin.
This in a way that the FT-messages are transfered to XML level.