Thema: ball mouse modified for distance input

Hallo

Unglaublich was der Kleine aus mir raussaugt, mein Adapter ist fertig. Und er funktioniert auch fast perfekt:

Bild hier   Bild hier   Bild hier   Bild hier  

Stückliste:

1 asuro
1 asuro/yeti RS232-Transceiver
1 serielle Maus (mit 1200,7,2,none)
2 9-polige Sub-D Stecker (Vater)
1 9V-Akkublock
1 Anschlussclip für den 9V-Block
etwas Schaltdraht
Lötkolben und etwas zum Kabelabzwicken

Oki, alles nicht wild, die große Frage war: "Wie versorge ich das ganze mit Spannung". Der Adapter sollte völlig unabhänging vom asuro sein, aber dennoch so leicht, dass man ihn auf den asuro binden kann. Die Lösung:

Der Tripol-9V-Block

Bild hier   Bild hier   Bild hier  
Nachdem ich etwas im Netz gestöbert hatte, fand ich einen (eigentlich nicht ernst gemeinten) Tip: "Mach doch eine Mittelanzapfung dran". Mmmmh, wie sieht den ein 9V-Block von innen aus? Ich habe dann vorsichtig einen aufgehebelt und siehe da, 7 kleine Akkus sind da drin. Prima. Ich habe oben ein kleines Loch gebohrt und den Akku mit einem zusätzlichen Draht zwischen der vierten und fünften Zelle abgezapft. Aufbau:

+(Plus) | 4 Zellen(4,8V) | Anzapfung | 3 Zellen(3,6V) | -(Minus)

und das ergibt eine +4,8V/-3,6V Versorgungsspannung. Sieht wenig aus, aber mein Notebook (IBM) liefert auch nur 5.irgendwas Volt an der RS232-Schnittstelle)

Der Anschluß des Maussteckers:

Pin2: Leitung zum Pin3 des Tranceiver-Steckers
Pin3: -3.6V (Minus des Tripol-Blocks)
Pin4: +4.8V (Plus des Tripol-Block) verbunden mit Pin7 des Maussteckers
Pin5: 0V (Anzapfung des Tripol-Blocks) verbunden mit Masse
Pin7: +4.8V (Plus des Tripol-Block) verbunden mit Pin4 des Maussteckers
Steckergehäuse: 0V (Anzapfung des Tripol-Blocks) verbunden mit Pin5 des Maussteckers

Der Anschluß des Transceiver-Steckers:

Pin3: Leitung zu Pin 2 des Maussteckers
Pin4: +4.8V (Plus des Tripol-Block)
Pin5: 0V (Anzapfung des Tripol-Blocks)

Das war's auch schon, Besitzer eines USB-Transceivers (oder eines zweiten RS232-Transceivers) können das ganze jetzt schon mal testen. Wenn alles funktioniert, sollte im Terminal-Programm etwa das erscheinen, :

Code:

PtP@PtP@P@ttPtt@PhPtPtttP@P`P@P@tPtppppppppqpqabcdvwvw
cdcBcbcbcbÀbcbbcbÀbbbcbcbcbÀbÀbÀPQPQQPQPQOPOPOPOP ! ! ! ! ! !vwbcvwcdvwcdvwbdvwc
dvwcdvwcdvwcdvwcdvwcdvwcdvwcdPQ@APQ@APQ@APQ@APQbcvwbdvwcdxycdvwbcbcwdxy`rvsc`v
c`vsbvsc`rvssvsvsvsvsvs`s`srvs`vscrsrvsc`sc`vsc`vvsvsvssavsc`c`vscrvvv
vsdjajajaajaej}ajaea}}aj}jaaje}ja}j}j~jqj@jaj~jaj~h``h`tp`~fcf~fstg```P@P@`@`@`@
`@`@`@`@`@`@P@P@P@P@@C?@S>|@_@@@@@L?C?C?O>?O77O;;L?O76O6.O7-O<.O>3O?6O=:O?>C?L?@
@L?L?C?C:C4C3C;C=C:C4C6C>L?C6C4C<L;@@@@C?C)CC2C-C2C/C8O?;L/L+L-L*L.L4L8L;L?C?C=C
=C=C9C4C3C6O;?O49O04O31O91O;5O?7L5L5L:L:O><O??C?C:C-C6C<C?L?L?L7L3L8L;L;L<L;L6L7
L;L>C?C?@C?C?@@L=L>L?L?C?O5=C1C2C1C)C9C<C?L?L?O?<L:L6L2L2L6L8L8L?@@C?C:C:C:C6C4O
8?C7O:>O;<O;:O><@@L?L5L8O;6O>:O>8L9L8L;L?L?C?C9C3C8C:C6C6C:@@@@O?>@L?L?@<L8L:L=L
=L<L>L?L;L8L6L4L6L4@C?C;C3C+C-C3C3C,C+C6C;O<?O:=O87O:5O>6L7L4L

(Nicht vergessen, die Maus sendet mit 1200,7,2,none! Das selbe sieht man auch, wenn man die Maus direkt am Terminal einsteckt.)

Mein Testaufbau:

Bild hier   Bild hier   Bild hier   Bild hier  

Und noch ein kleines Filmchen:
Bild hier  

Leider wieder unscharf und die Farbe ( Bit 0 des Zeichens) der StatusLED nicht erkennbar. Was man aber sieht ist die IR-Diode des asuros die das empfangene Zeichen+1 zurücksendet.

Leider hat das ganze noch einen Schönheitsfehler: Die vom asuro empfangenen Zeichen sind irgendwie Schrott. Ich weis noch nicht, ob das an meiner Empfangsroutine liegt, oder am Aufbau des Datenbytes oder sonstwas. Vielleicht weis ja einer von euch warum das noch nicht klappt.

Der Code meines kleinen Testprogramms:

Code:

#include "../inc/asuro.h"

#define FOSC 8000000// Clock Speed
#define BAUD 1200
#define MYUBRR FOSC/16/BAUD-1

void USART_Init( unsigned int ubrr)
{
/* Set baud rate */
UBRRH = (unsigned char)(ubrr>>8);
UBRRL = (unsigned char)ubrr;
/* Enable receiver and transmitter */
UCSRB = (1<<RXEN)|(1<<TXEN);
/* Set frame format: 8data, 2stop bit */
/*UCSRC = (1<<URSEL)|(1<<USBS)|(3<<UCSZ0);*/
UCSRC = 0x8A; //10001010 = 7bit, 2stop, kein parity
}

int main( void )
{
char data;

Init();
USART_Init ( MYUBRR );

while (0) {
	SerWrite("abcABC",6);
	Msleep(500);
}
// aus SerRead() kopiert
//data=' ';
//UCSRB = 0x10; // enable receiver
while(0) {
	if (UCSRA & 0x80) data = UDR;
	if (data == 'P') BackLED(OFF,ON);
	if (data == '@') BackLED(ON,OFF);
	data = ' ';
}
StatusLED(RED);
data=' ';
while(1) {
SerRead(&data,1,0);
	if (data == 'P') BackLED(OFF,ON);
	if (data == '@') BackLED(ON,OFF);
	if (data & 1) StatusLED(YELLOW); else StatusLED(RED);
data++;
SerWrite(&data,1);
}
return 0;
}

und für den schnellen Test noch das .hex im Anhang.

that's all

Gruß

mic

Hallo

Nun weis ich auch, warum meine empfangenen Zeichen nur Schrott waren. Eine serielle Maus sendet ihre Daten in Paketen, einfache Protokolle sehen dafür drei Bytes vor:

Code:

Data packet is 3 byte packet. It is send to the computer every time mouse state changes (mouse moves or keys are pressed/released). 
        D7      D6      D5      D4      D3      D2      D1      D0
 
1.      X       1       LB      RB      Y7      Y6      X7      X6
2.      X       0       X5      X4      X3      X2      X1      X0      
3.      X       0       Y5      Y4      Y3      Y2      Y1      Y0

Note: The bit marked with X is 0 if the mouse received with 7 databits and 2 stop bits format. It is also possible to use 8 databits and 1 stop bit format for receiving. In this case X gets value 1. The safest thing to get everything working is to use 7 databits and 1 stopbit when receiving mouse information (and if you are making mouse then send out 7 databits and 2 stop bits). 
The byte marked with 1. is send first, then the others. The bit D6 in the first byte is used for syncronizing the software to mouse packets if it goes out of sync. 

LB is the state of the left button (1 means pressed down)
RB is the state of the right button (1 means pressed down)
X7-X0 movement in X direction since last packet (signed byte)
Y7-Y0 movement in Y direction since last packet (signed byte)

Graphical description how the data is contained in the packet
              1st byte        2nd byte         3rd byte
          ================  ===============  ================
           - 1 ? ? Y Y X X  - 0 X X X X X X  - 0 Y Y Y Y Y Y
          ================  ===============  ================
               | | \ / \ /      \---------/      \---------/
               | |  |   |            |                |
               | |  |   \----\       |                |
               | |  \--------|-------|--------\       |
               | |          / \ /---------\  / \ /---------\
               | |         ================ =================
               | |          0 0 0 0 0 0 0 0  0 0 0 0 0 0 0 0
 Left Button --/ |         ================ =================
Right Button ----/            X increment      Y increment

Mouse identification
When DTR line is toggled, mouse should send one data byte containing letter 'M' (ascii 77).

(gefunden bei: http://users.tkk.fi/~then/mytexts/mouse.html)

Das "M" zur Identifikation der Maus kann man im Terminalprogramm schön erkennen, die Datenbytes dann schon eher nicht (manche sollen ja auch Graycode "lesen" können).

Mein einfaches Testprogramm sieht nun so aus:

Code:

#include "../inc/asuro.h"

#define FOSC 8000000// Clock Speed
#define BAUD 1200
#define MYUBRR FOSC/16/BAUD-1

void USART_Init( unsigned int ubrr)
{
/* Set baud rate */
UBRRH = (unsigned char)(ubrr>>8);
UBRRL = (unsigned char)ubrr;
/* Enable receiver and transmitter */
UCSRB = (1<<RXEN)|(1<<TXEN);
/* Set frame format: 8data, 2stop bit */
/*UCSRC = (1<<URSEL)|(1<<USBS)|(3<<UCSZ0);*/
UCSRC = 0x8A; //10001010 = 7bit, 2stop, kein parity
}

int main( void )
{
char data;

Init();
USART_Init ( MYUBRR );
StatusLED(RED);
data=' ';

/*  Aufbau der Datenbits (Startbyte mit gesetztem D6!)
        D7      D6      D5      D4      D3      D2      D1      D0

1.      X       1       LB      RB      Y7      Y6      X7      X6
2.      X       0       X5      X4      X3      X2      X1      X0
3.      X       0       Y5      Y4      Y3      Y2      Y1      Y0

Quelle: http://users.tkk.fi/~then/mytexts/mouse.html
*/

while(1) {

SerRead(&data,1,0);
	if (data & 0x50) BackLED(OFF,ON);
	if (data & 0x60) BackLED(ON,OFF);
	if (data & 1) StatusLED(YELLOW); else StatusLED(RED);
SerWrite(&data,1);
}
return 0;
}

Die Maustasten steuern nun die BackLEDs, Bit 0 der Daten weiterhin die StatusLED. Der SerWrite-Befehl dient nur zur Kontrolle ob sich was tut. Man könnte auch z.B. den Inhalt der Bytes 2+3 senden.

Gruß

mic

toll.find ich echt klasse. scheint ja irgendwie einfacher als gedacht zu sein. ein hochinteressantes projekt!
vor allem klasse, dass das mit dem ir-transceiver geht =)

bring den asuro mal dazu, dass er deiner mausbewegung folgt =)
maus nach vorn=asuro nahc vorn
maus nach links=asuro dreht nach links
usw.
meinst du das geht?

Hallo

bring den asuro mal dazu, dass er deiner mausbewegung folgt =)

Bin ich schon dabei.

So nebenbei fällt dabei auch einiges für andere Projekte/Probleme ab:

Die Spannungsversorgung der IR-Transceivers kann man auch bei schwachbrüstigen USB-RS232-Wandlern einsetzen. Eventuell sogar mit vollen 9V zwischen Pin4 und Pin5.

Die Änderung der Baudrate sollte auch in die andere Richtung funktionieren. Dann kann man Programme, die eine Ausgabe zum Terminal schicken, deutlich beschleunigen. Eventuell muss man die Verzögerungsschleifen bei SerWrite ändern/löschen um das voll zu nutzen.

Ich hab's zwar noch nicht versucht, aber wenn man in meinem Testprogramm eine andere Baudrate (z.b. 9600) angibt und das Terminalprogramm anpasst, sollte das auch funktionieren. Dann versteht der asuro zwar die Maus nicht mehr, aber bei anderen, teilweise schnellen Funktionen wie Odometrie oder Linienfolgen, könnte man so schneller Daten senden.

Gruß

mic

das ist eigentlich richtig... evtl wird es dann fehleranfälliger, aber ist sicher einen versuch wert.

Hallo

Jetzt habe ich mal wenigstens eine einfache Funktion realisiert:

asuro fährt an der Leine und wird von der Maus gesteuert. Mit einer Maustaste kann das jeweilige Rad gebremst werden. Im Film fährt er mit MotorSpeed 200 und bremst mit 125. Die BackLEDs zeigen an, welcher Motor gebremst wird.

Bild hier   Bild hier   Bild hier  
Bild hier   Bild hier   Bild hier  

Bild hier  
http://youtube.com/watch?v=8seKhScQ8S8

Der Kleine quält sich merklich bei dem Ballast und mit den Riesenrädern. Später, wenn wir den Weg mit der Maus messen, wird das Kabel fehlen und der Adapter schlanker sein.

Die Ladung des 9V-Blocks wird wohl recht lange reichen. Sowohl der IR-Transceiver als auch die Maus selbst dürften auf geringen Stromverbrauch getrimmt sein, weil sie normalerweise ihre Power aus einem schwachbrüstigen v24-Anschluß beziehen. Trotzdem braucht das Teil unbedingt einen Ausschalter, der Batterieclip hält das häufige Ausstöpseln auf die Dauer nicht aus.

Mit diesem Aufbau ist sogar ein Akkuwechsel möglich. Allerdings nur, wenn man den orginalen, großen Kabelbinder gegen einen qualitativ besseren ersetzt hat.

Gruß

mic

klasse! gibts wieder was neues?

Hallo damaltor,

warst du krank? Wir haben lange nichts mehr von dir gelesen.

Nein, es gibt leider nichts neues. Ich habe mir zwar inzwischen ein paar Teile für den schlankeren Adapter besorgt, bin aber nun beim Liniensuchen und Geschwindigkeit erhöhen hängengeblieben.

Das Erhöhen der Baudrate über 2400 funktioniert wohl doch nicht so einfach wie ich dachte. Im Terminal kommt nur Schrott an. Ich hab's aber nur kurz getestet.

Gruß

mic