This action might not be possible to undo. Are you sure you want to continue?
The wireless ghost writer is a robot that draws what the user draws with a connected mouse.
Robot in shoe-box ready to be demoed later in the day. Summary We used two stepper motors to drive a steel ball scavenged from a ball-bearing. These motors were controlled by a PS/2 mouse wirelessly using the RCR-433 and RCT-433 receiver/transmission combination mentioned in lecture. We then took the PS/2 protocol, made it compact, modified existing transmission code and deduced a way to control the robot via the mouse. We also mounted a solenoid which raises and lowers a writing instrument. The device is meant to write on a sheet of paper. By using a mouse to control the robot, anyone can sit down and doodle remotely with it. This was done since we wanted to create a project that could be used intuitively by anyone and be fun, yet useful in some applications. Also, we wanted to build a robot
since robots are interesting. We chose the spherical drive since it was a novel approach that we had only seen a few times on the internet (http://www.ri.cmu.edu/pubs/pub_5457.html). We made the design wireless to allow the robot to move unopposed in any direction. High Level Design Rationale We were trying to figure out what to do for our final project when we came across the idea of creating something we could entertain and scare people with. After some research online we were determined to make the ghost writing robot. We wanted to be able to put the robot in a room and from another room get it to draw messages and images wirelessly. We also wanted to create a system for easily blowing up or shrinking what someone draws while maintaining accurate drawing scale. We chose the spherical drive train since that most accurately mimics the mouse movements and would allow for drawings that did not have unnecessary curves due to rotation of a conventional drive train (like 2 or 4 drive motors controlling wheels that are parallel to each other). In determining the motors to use, we chose stepper motors since they were small in size yet had a sizeable amount of torque, which we felt would be necessary for driving the robot, the electronics, and batteries. By using this drive train we also simplified the amount of software needed to translate the mouse input into stepper motor control since both would now be on a similar Δx and Δy coordinate system. Background Math Most of the mathematics behind this project dealt with timing. The mouse defaults to 100 packet updates per second. However, we found that with a maximum baud rate of 4800, the wireless link can only send 480 bytes per second or at most 160 mouse packets. Additionally, running the wireless at maximum speed caused a couple of dropped packets, whereas running it at around 4300 baud provided near flawless communication; so we did. With the overhead on the packets however, we were only able to transmit 4300/10 = 430/15 = about 27 mouse packets per second. We reduced the overhead on the wireless link and were able to transmit 430/5 = 86 packets per second. Since the mouse can only deal with certain discrete values, we had to settle for 80 updates per second, which is more than enough to report apparently smooth motion.
or about 2. and we essentially buffer anything beyond this limit using the xmov and ymov variables in rx. .The motors also have timing issues. given the slippage of the ball. Theoretically. Each unit of mouse movement translates to one half tick of the motor. We find that as long as the mouse is moved fairly slowly (which is pretty essential if you want to draw accurately with the mouse). The timing we ended up going with was 313 overflows of timer 0. The limit on the motors (tested by trial and error) seemed to be about one update (motor tick) every 2 ms. one full tick per 4 ms. we switched to a half-step drive for the motors.5 ms = 60 mm per second. It is illustrated in the following diagram. this causes no overflow problems with the motors. although this can be changed by sending a command to the mouse. (One unit of mouse movement = ¼ mm. this means that each ¼ mm of mouse movement translates to pi * ¾ in = roughly .5 inches per second. However. Logical Structure The high level structure follows a simple scheme of taking input from the PS/2 mouse. We figured that this would be ok.c. We actually wanted to keep the drawings small for the safety of the robot and for simplicity‟s sake. which cuts the max speed to one half motor ticks per 2 ms. one update reaches the receiver every 12.5 ms. the mouse would theoretically only be able to move 3 spaces per update. or 313 * 16 us = 5 ms per half tick. Therefore. This would mean that given a perfect drive train the drawing would be scaled up. Assuming 80 updates occur per second. Additionally.6 mm after unit conversions.) ¾ mm per 12. so this works out. the drawing comes out to be much closer in size to the mouse movement. or ¾ mm. since we don‟t really want the robot to be made to move too fast anyway. sending it wirelessly from one Atmega32 to the Atmega32 onboard the robot and then driving the motors and solenoid.
limitations. Of these were speed of the motors—if the motors ran too fast they slipped on the sphere and the robot would just jerk and not move. In order to account for this.Hardware/software tradeoffs In the creation of the robot. we ended up hitting quite a few snags due to physical. in software we slowed down the maximum operating speed . as well as hardware.
-y).computer-engineering.access. The limitations of the wireless transmitter and receiver meant that we had to eliminate bytes of overhead from the transmission as well as package the PS/2 mouse output to take up less room in order to increase the data rate from the mouse.org/ps2protocol/). The goal was for the mouse to be the limiting factor in precision for the project. we were able to get smooth updates from the mouse. By reducing the updates/second to 20 and gradually increasing it from 20 to 80 while removing a lot of overhead bytes (as discussed in the software section). Patents. it should be acknowledged that the full protocol was developed by IBM. not the wireless or the robot.gpo. Trademarks Since we used the PS/2 mouse protocol (somewhat reversed engineered). Standards Our robot‟s wireless transmitter and receiver combination complies with FCC standards since it does not interfere with licensed transmitters and it transmits in the acceptable range of frequencies found in Part 15 of the FCC rules (http://www. We also used a 6-pin mini-DIN connector as per required by the PS/2 protocol.-x and +. We also had to sacrifice accuracy of the robot due to inability of the design to drive the sphere straight in the cardinal directions (+. We have not used any other patented or potentially patented hardware or software in the design of this project. Our code has been modified from other code released under the GNU Public License and the authors have been acknowledged in this report. Program/Hardware Design Software Details PS/2 Interface The interface to the PS/2 mouse is located on the transmitter chip and in tx. This is evident in that initially the 100 updates/second from the mouse was producing a massive amount of packet loss due to wireless overhead constraints. Due to this.gov/nara/cfr/waisidx_01/47cfr15_01.of the stepper motors. The . Copyright.html). any mouse that complies with the standard can be used with our project. Since we used a PS/2 mouse we had to develop a way of conforming to the PS/2 mouse protocol (http://www.c.
This number can be 10. When the mouse communicates to the host. 60. Due to the timing issues described above. and represents the number of mouse updates per second (we use 80. then releases control of the clock back to the mouse. Mouse packet format is given by the following table: Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Byte 1 Y overflow X overflow Y sign bit X sign bit Always 1 Middle Btn Right Btn Left Btn X Movement Byte 2 Y Movement Byte 3 Wireless Link The wireless code is present on both chips. The send() function allows for host-to-mouse communication. then an odd parity bit. which brought the allowable sampling rate of the mouse from 20 packets/second to 80 . or 200. then 8 data bits. it must first turn receiving off in order to prevent that interrupt from firing.c. The other functions used are init_receive() and disable_receive(). while mouse-to-host communication is triggered by an external interrupt (using PORTD. 40. then sends a 0 over the data line. data and clock. we first send a reset command (0xff) to verify that the mouse is connected properly and is working. a 0xf4 command is sent to enable mouse data reporting. 20. In order for the MCU to send a command to the mouse. Both lines are defaulted to high but can be pulled low by either the host (the microcontroller) or the device (the mouse). the protocol had to be modified somewhat. it drives the clock line itself and sends data in the same format as described above. which turn that external interrupt on and off. 100. and also in txrx. First a start bit (0) is sent. 80. The mouse then sends a clock signal allowing the host to send a data packet. however. The mouse then sends an acknowledgement bit (0) and will follow that up with its own communication. We then send 0xf3 followed by a decimal number to set the mouse sampling rate. and the mouse will then send updates in the form of packets. To set up the mouse for our purposes. Finally. and finally a stop bit (1). Communication with the mouse is initiated when the MCU pulls the clock low (inhibiting mouse communication to the MCU).2) that fires when the start bit is sent from the mouse. We attempted to cut back as much overhead as possible from the packets and were able to reduce amount of overhead from 12 bytes to 1 byte. a header file originally written by Meghan Desai that provided a protocol for wireless transmission. as it is the fastest we can go without exceeding the baud rate of the wireless transmitter).PS/2 protocol allows 2-way communication with a keyboard or mouse using only 2 electrical lines.
0011. 0100. to cause an overflow. In addition. the first half of the start byte is overhead. The interrupt had to be modified to continuously clear the USART whenever a packet was not being transmitted. this proved irrelevant. our link rarely if ever dropped a packet. (The overflow bits are barely physically relevant. and the necessary data is extrapolated from the packet. In order to produce more torque out of the motors. etc. but it wouldn‟t work). since the robot itself refused to move at speeds that fast. While the encoding scheme used by Meghan Desai is useful for reliability.) The last two bytes contain the X and Y movement. respectively. The middle mouse button is not present on the mouse. and so on. 0010. since the user would have to move the mouse about 3 inches in 12.c) which is scheduled by Timer 0. 0110. 1001. a virtual timer is decremented. and thus does not need to be sent. 0001. When a packet is ready to transmit. so they were removed as well. to make the motor move). the USART is first cleared with 0x00. then the next. a packet comes in and is decoded using the RXC interrupt (RX complete). the robot itself can‟t handle this as it is. Although half stepping effectively halves the top speed of the motors (the motors we used cannot handle signal changes quicker than one every 2 ms or so). so there is no need for an end byte or transmitting the length of the packet. we found that without it. 0100.5 ms. do nothing to prevent physical collisions of packets. 0100. but only sends 1 byte of 0xaa for calibration/synchronization of the two units (we tried getting rid of this too. or about 20 feet per second. When Timer 0 overflows. Our wireless uses the same functions as the original code. Essentially. then the packet is sent using the tx_me() function. This function will place the mouse packet into a transmittable packet (with a synch byte and “start nibble”) and send it using the UDR Empty interrupt. while originally present. one must first power one wire. and since higher sampling rate was of greater priority. Motor Control The two stepper motors are controlled using 4 wires that go to 2 coils. 0010. always on. to control a stepper motor. and the second half contains the mouse button info and sign bits for the movement. When the timer . and the “Always On” bit is. 1000. We had to drive the motors at a speed that would be slow enough to drive the robot without tons of slipping yet would be quick enough to preserve the accuracy of the drawing. 0001.packets/second.e. send 1000. we used a “half-stepping” method of driving (send 1000. On the receive side. When a packet is fully received. The motor is controlled by task1 on the receiver chip (rx. Channel ID‟s. (i. and repeat). well. we discarded it. then the next. rx_done() is set. Packet length for our purposes is always 3 (4 including overhead). 1100. the start byte is now compressed with part of the mouse data.
To do this. Hardware Details The hardware for the project was mostly borrowed from previous projects and then modified to suit our needs. It is wired to be active low: it raises the pen when the port pin (D. However.hits 0. lowers it when the pin is set low. the motors‟ positions are updated based on the values of xmov and ymov. two variables that accumulate based on the data packets that come in. this was not just a straight-forward task as the circuits provided on some project pages had key elements poorly labeled or missing and thus we had to research how these circuit exactly worked to implement them correctly.3) is set high. Solenoid Control The solenoid is controlled by the left mouse button. it takes the last bit from the first data byte whenever a packet is received by the MCU mounted on the robot. Transmitter and Receiver Circuits .
” PS/2 Mouse Communication Circuit .The circuits for the RCT-433 transmitter and the RCR-433 receiver were taken from Tytus Mak and Daniel DiBernardo‟s “Touch Screen Controlled R/C Car.
we chose 18V as it provided enough power to lift the writing instrument as well as it was easy to generate 18V by putting two 9V batteries in series. This was possible since the PS/2 mouse never exceeds the 5V or 50mA limits on the inputs of the Atmega32. Solenoid Control Circuit To drive the solenoid we used two transistors and a resistor to allow the microcontroller to power and control the solenoid.2 and D. .3. the ground of the 18V power supply (two 9V batteries in series) is common with the ground of the microcontroller.The mouse control hardware involved using two NPN transistors (2N3904) two drive the mouse whereas the inputs from the mouse were connected directly to ports D. The solenoid can operate between 12V and 24V. With this circuit. The two NPN BJT transistors allow the microcontroller to drive the solenoid with is much higher in current ~250mA than the ports of the Atmega32 can handle as well as being at a higher voltage (18V).
Overall the hardware design is straightforward. which was supplied by a 9V battery connected to the ULN2003 and the stepper motors (the green and red wires). Voltages were chosen that corresponded to real voltages that could be easily generated from 9V batteries. Luckily all of the components.Solenoid mounted on robot with Sharpie for drawing. save for the solenoid. considerations were taken for ease of building as well as availability of parts. were available in lab. Stepper Motor Driver Circuit The stepper motor circuit uses two ULN2003 Darlington arrays to isolate the voltages of the stepper motors from the Atmega32 microcontroller. Mechanical Design Details . The stepper motors took 9V to drive.
the sphere is secured in three dimensions which aids in transferring power from the motors to the sphere to the paper effectively.625” diameter opening failed to adequately move the robot. By having the motors and the L-brackets provide the tension. We used 1. Switching to a larger sphere—1” as opposed to 7/8”—as well as different material—steel as opposed to rubber coated iron—allowed the robot to carry the weight of the portable circuitry as well as the four 9V batteries to power the electronics. we needed to add a collar to hold the sphere to a specific location in space and move the L-brackets in to provide additional tension on the ball. Lexan was chosen as a base since its clear.The robot was initially designed in Pro/Engineer and was based on initially using a mouse ball of 7/8” diameter. We decided upon this after initial testing with the 7/8” ball on Lexan with a . as well as strong and Matt had experience in machining it before.5” aluminum L-brackets which were machined to accurately and securely mount the stepper motors. which would aid in seeing what the robot had already drawn. . The Lexan was machined to create a diameter of 1. The robot design needed a way of mounting the stepper motors to the lexan base.1” to allow the sphere to freely move around. however. Ultimately.
The epoxy was used since there was no room for a screw and nut to be put through the Lexan and aluminum brackets. his/her . These variations are due to the mounting of the motors on the robot as when it pulls the ball it has all of the power from the motor going in the downward rotational direction as opposed to pushing the ball where the power is lost in the transition of going up to down rotationally. but due to physical limitations of the robot‟s design. due to slippage of the motors on the sphere at higher speeds. after about 4-5 seconds of turning the solenoid on-and-off at the maximum human button frequency of 5Hz. This will not prevent drawing as the solenoid in its de-energized state has the writing instrument touching the surface of the paper. The transmission is very accurate and during the testing of the wireless communication in lab with an oscilloscope we noticed no dropped packets while others were not transmitting. since we were able to get the updates of the mouse to 80 per second. there is no aliasing between movement of the mouse and movement of the robot. However. we had to limit the speed of the stepper motors. Results of the Design Speed of Execution As mentioned above. Since the user is only moving and clicking a mouse. the solenoid needs to rest for a few seconds before being active again (able to lift). Safety Enforcement We enforced safety by allowing the robot to operate wirelessly without direct physical interaction from the user. the robot‟s movements seem fluid with the motion of the robot. Since 80Hz is above the Shannon-Nyquist frequency of human vision (> 2*~15-20Hz).The material is held together with epoxy with the exception of the motors to the brackets which are held with one screw each. Accuracy We aimed to have the robot create drawings that are pretty accurate to the mouse movements. Due to physical limitations of the solenoid (it is continuous-duty). we saw in testing that the robot had slightly different speeds for different directions (reverse is slightly faster than forward for the robot as well as left is slightly faster than right for the robot). save for a small delay from the wireless transmission.
If we ever were to commercialize our project. We aimed to have a collar holding the ball in the robot to prevent the ball from falling out when transporting it. physical interference would still occur. the channel ID‟s didn‟t actually do anything for physical interference. it‟s recommended to lift the robot on its side. Originally. we found that we had to sacrifice this overhead in the packets to allow for faster communication. Interference The PS/2 mouse and the motors should not cause any interference because they are wired and fairly self-contained. Also. the same hazards exist when dealing with batteries for this device as any other—handle the batteries with care. storing it).primary safety concern is fatigue in the wrist/hands. then move the robot to prevent and unforeseen injury due to the ball dropping on something or someone. Usability Since the project uses a mouse input. and caused fewer than 10% (likely around 5%) of the packets to be dropped. believing that it would prevent interference from occurring. Conclusions . remove the drive ball. We found that on our end. secure it. but due to changes in the design. We also found that our transmissions caused even less interference to other groups since we were not continuously transmitting. Since the robot is wireless and battery driven. and would use a packet system with ID‟s to prevent logical interference. To maximize safety. However. This allows people who don‟t have the dexterity to hold a conventional writing instrument and/or draw for long periods of time to use this device to overcome those obstacles. any interference that was caused by other groups was minimal. and would only help if we ended up receiving someone else‟s packet who is using the same packet system. however. the possibility of carpel tunnel syndrome after prolonged use of the mouse as well as discomfort due to the lack of effective ergonomics in most modern mouse‟s. we would find faster wireless hardware. We avoided electrical hazards by using relatively low voltage and low current devices. don‟t bang them and dispose of them properly. it is usable by anyone able to use a PS/2 mouse device. The 433 MHz transmitter is likely to interfere with other groups receiving on the same frequency. but only transmitted after a mouse update. we used packets with a set channel ID. this was omitted. The robot is made of Lexan with burred edges which would prevent cutting the user during direct interaction with the robot (moving it.
we would recommend to any group in the future to be prepared for the worst and try to pick a project that is within your realm and field of interest as an engineering student. We cited other groups who code we reused and modified as well as circuit designs we borrowed. Electronically and software-wise the project was completed to our standards and expectations. but we didn‟t get the accuracy or precision out of the robot that we wanted. Aside from this. We strived for safety throughout the development of this project by accepting “responsibility in making decisions consistent with the safety. Mechanically. If we could do this project in a different way we would design a more constrained platform for the robot with a larger sphere. We adhered to the Code of Ethics by always paying attention to what we were using. innovating applications. Our requirements for the project: -Must accept input ONLY from PS/2 mouse -PS/2 mouse MUST control robot WIRELESSLY -Robot MUST be able to move in almost any direction -Robot MUST be able to draw to a sheet of paper what is being done with mouse We satisfied all of the requirements. we were able to eliminate many mechanical issues and get the robot working decently well. the design had problems that were unforeseen in the development stage since neither project member is a mechanical engineer. Thanks to the lab operators in the Hollister CEE machine shop. which was necessary for getting the mouse signal correct.Design Analysis Overall we were impressed that we were able to use this novel drive approach to create a fun and useful device for drawing and writing. and to disclose promptly factors that might endanger the public…” We also helped other . how we used it and why. gear drivers instead of the grommets we used and supporting spheres to aid in sliding the robot around. Ethical Considerations The IEEE Code of Ethics establishes a guideline to adhere to for the development of safe. Applicable Standards We didn‟t really follow any „applicable standards‟ aside from the PS/2 mouse protocol. health and welfare of the public.
if any. Transmitter and Receiver Circuits . We presented what we expected to happen and what did and show the data that supports our claims as well as data that contradicts them. We didn‟t pressure companies to donate parts or other people and we did not engage in bribery or anything of the like at anytime. We could have cherry-picked data to present our project in a more favorable view. but we didn‟t. Legal Considerations Our project complies with FCC standards since it does not interfere with licensed transmitters and it transmits in the acceptable range of frequencies found in Part 15 of the FCC rules (http://www.groups when they needed aid and never tried to work that angle to get help in return. We did not lie about what we did/didn‟t do for the project and we tried to adhere to reasonable goals and not make false claims in this document. We believed in doing this project for us and as such we did not want to do anything unethical or lie to ourselves or anyone else involved in the creation or demonstration of this project.html).gov/nara/cfr/waisidx_01/47cfr15_01.gpo.access.
PS/2 Mouse Communication Circuit .
Solenoid Control Circuit .
85 (All Electronics) PS/2 connector: $1 PS/2 mouse: Free (old mouse) Steel ball: Free (scavenged from old bearing) Aluminum: $1 (1/12 of $12 piece) Lexan: free (found in machine shop) .Stepper Motor Driver Circuit Cost Details STK500: $15 DIP socket(2): $1 Atmega32 : 8 = $8 Atmega32 (second): Sampled. Atmel RCT-433 Transmitter: $4 RCR-433 Receiver: $4 Max233: $7 Power supply: $5 custom PC board: $5 Stepper motor (2) (35T-48):: $2 GUARDIAN A420-067074 Solenoid: $3.
Screws & nuts: free (found in house) Grommets: free (found in machine shop) Battery(4): $8 Small solder board (4): $4 Assorted capacitors.85 . and resistors: free (from lab) 2N3904 (3): Free (from lab) TIP31: Free (from lab) ULN2003AN (2): Free (from lab) 9V connectors (3): Free (from lab) Cable ties: Free (Matt purchased before Spring 2007) Pen/Sharpie: Free (found around house) Epoxy: Free (from machine shop) Total: $68. LEDs. inductors.
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue reading from where you left off, or restart the preview.