robot - Robotnacka control component ------------------------------------ version 09/02/2006 Introduction: robot.ocx is a universal loadable library that can be used with Imagine Logo version 2. It contains some procedures and operations for controlling the Robotnacka (or protocol-compatible) robot, and retrieving information from the robot. The component is linked also as a stand-alone executable (robot.exe), loadable library (robot.dll), and there is Java API that utilizes robotjava.dll JNI version provided. See ReadMe.txt files in the respective subfolders for more details, examples, and documentation. Where to get it: You can download latest release from the release folder at the following URL: http://www.microstep-mis.com/cgi-bin/cvsweb/robotika/robot Please visit the Robotnacka Software Project at: http://www.robotika.sk/projects/turtlesoft/ Requirements: * Bluetooth USB adapter that properly supports the virtual serial ports (for example MSI BT Dongle) installed -- for controlling local robot or Internet connection -- for controlling remote robot * on Linux: your USB adapter should be supported by Linux; bluez-utils package installed kernel supporting Bluetooth (standard Debian kernel does) CVS snapshot installation: * checkout or update the latest cvs snapshot (see http://www.microstep-mis.com/cgi-bin/cvsweb/~checkout~/robotika/readme.txt) * make sure ocx is registered: Start->Run: Regsvr32.exe ...\robotika\robot\robot.ocx (or whatever path you have) Release package Installation: * unzip the package to some directory (let's call it $INSTALL) * register the robot.ocx Start->Run: Regsvr32.exe $INSTALL\robot.ocx * alternately, please follow the installation instructions from Robotnacka Software Project page (http://www.robotika.sk/projects/turtlesoft/) Usage: This short usage manual is written for Imagine Logo, but the equivalent procedure and function calls can be made from any other application that loads this library. 1. CONNECTING THE ROBOT ----------------------- First create a new robot object, and name it for example r: new "oleobject [comname robot name r] The next step is to connect to a robot that is turned on, and communicates with the computer using the local communication serial port - for example through a cable, bluetooth serial port or infrared device. Please note that if your robot is connected through a bluetooth serial port, you have to find it first. That is, you have to "Explore your bluetooth places" while the robot is on, and then double-click the "Find Bluetooth Devices" icon. As a consequence, the "turtleN" robot will become visible, double-click that one too, so that you will see the "Serial on TurtleN" icon (and double-click also that icon). Great. This procedure is needed only once per reboot of your computer (or plugging in of the bluetooth module). Once the turtle serial port device is known, you can connect by: r'connect "com4 Where the first argument specifies the port, which was assigned to the TurtleN - you can find out which one it is by clicking with the right mouse button on the "Serial on TurtleN" icon when you explore your Bluetooth places. Other robots that are in reach will not respond to any activity with the object r. You can create a second (third...) object for a robot with a different name at the same time, for example: new "oleobject [comname robot name r2] r2'connect "com5 But let's turn to a more interesting part: 2. ROBOT NAVIGATION ------------------- You can make the robot move forward and backwards: r'fd 1000 r'bk 1000 where 1000 here means to move 1000 very small steps (for Robotnacka, it is a bit more than 0.2 mm). You can make the robot turn left and right at its current location: r'lt 720 r'rt 720 each of these two commands will turn Robotnacka by 90 degrees. Note that the robot will always move the same (maximum) speed. Also note that all four position commands return immediatelly, after the command is received and confirmed by the robot. The command is executed by the robot in the background, and it will not start executing a new command, before the issued command is completed. The operation: r'isdone can be used to see if the robot finished executing the command. It returns 0, if the robot has not finished the last command, and 1, if the command was successfully completed. If you are curious, r'isdone operation does not start any additional communication with the robot (contrary to r'getactivity - see below). If you want to wait until the position command is completed, you need to periodically call r'isdone until it returns 1. A preferred alternative is to use the operation r'wait 10000 where 10000 is the time this operation will wait (in milliseconds). After the position command will have finished, the operation will return. Otherwise, it will wait until the specified time elapsed. Use 0 if you want to wait infinitely. If you prefer to wait automatically after each position command, you can set automatic waiting by r'alwayswait "on or later turn it off (which is a default behavior) by: r'alwayswait "off More about alwayswait: The meaning of automatic waiting is that the position commands return only after the robot has completed them. For example, if alwayswait is on, the procedure r'fd 1000 returns only after robot has moved 1000 steps forward and stopped. Opposite, if alwayswait is off, the operation will return immediatelly, and if you issue another command (for example r'lt 720), the robot will start turning immediatelly after it completes the forward movement. However, you can send only one command in advance. If you send more commands, only the command sent last is kept in the buffer. It is recommended that you issue the r'alwayswait "on command, if you are starting with programming of the robot, even though it is not the default setting. You can switch the robot pen up and down with the commands: r'pu r'pd There is a second type of navigational commands. They regulate the current speed of the robot. These commands do not tell how much should the robot move, only how fast it should move. r'fdspeed 10 40 will start moving the robot forward, while its left wheel will be turning quater the speed (10) of its right wheel (40). In fact, this command will make the robot move along a circle, where the length of the circle completed by the right wheel will be 4-times the length of the circle of the left wheel - for Robotnacka, this means that the left wheel will move along a circle of radius approximately 60 mm: l1 = 2*pi*r l2 = 2*pi*(r + 180) l2 = 4*l1 -- 2*pi*(r+180) = 8*pi*r r+180 = 4*r r = 60 because the distance between the two wheels is 180mm. The robot's pen will thus draw a circle with radius (r1 + r2) / 2 = (60 + 60 + 180)/2 = 150 mm. Analogicaly, r'bkspeed 50 50 will make the robot go backwards half speed, and r'ltspeed 10 40 will cause Robotnacka start rotating along a circle with radius 54 mm, since the circles of the left and right wheels will be exactly concentric, and thus 180 = r1 + r2 r2 = 4*r1 -- 180 = 5*r1 r1 = 36, r2 = 4*36 = 144 r = (r2 - r1)/2 = (144-36)/2 = 54 And finally: r'rtspeed 0 50 will make the robot turn half speed backwards left around its left wheel. The four commands fdx, bkx, ltx, rtx combine the speed with precise number of steps. For example: r'ltx 60 90 500 will draw an arc, while the left wheel will move back with speed 60, the right wheel will move forward with speed 90 and the right wheel (the faster one) will make 500 steps. You can try to imagine other possible movements that can be achieved with these four speed commands, all of which require both their integer arguments in the interval 0 (no movement) to 99 (maximum robot speed). Robot keeps track of its location computed from its movements (odometry). Use the operation pos to retrieve the current position of the robot: pr r'pos 0 The operation returns a string with three double precision floating-point numbers "x y heading". The robot object assumes that it is connected to the robot when it is placed at coordinates [0 0] and heading towards point [0 1]. You can reset the current position to "0 0 0" again by calling: pr r'pos 1 If you wish to send your robot to certain point in the coordinate-space, you can use the following command (note that the result might differ by a point or so): r'moveto x y 3. OBTAINING INFORMATION FROM THE ROBOT --------------------------------------- The operation: r'getactivity can always be used to ask the robot what it is doing. The answer is a number 1, if the robot is executing a speed command, number 2, if the robot is executing one of the four position commands, number 3, if the robot is idle doing nothing, and -1 if there was a communication or another type of error. It is also possible to verify whether the robot is turned on, connected, and the communication is working fine using operation: r'isalive which returns 1, if the robot is reached, otherwise it returns zero. The robot battery power level in tenths of Volts can be obtained by: r'getvolage The robot starts generating long sound signal as soon as the battery power falls below the need-recharge voltage threshold. In that case, the battery must be recharged before further use, otherwise it would be damaged. If the robot is equipped with the 6 binary bottom light sensors, their readings can be retrieved using: r'getsensors The result is a 6-bit integer 0-63, where each bit corresponds to one of the binary sensors. The sensors bits are assigned as follows: (top view, Si corresponds to bit 2^i) front end S4 S3 S5 O S2 S0 S1 If the robot is equipped with the 5 ultrasonic distance sensors, their readings can be retrieved using: r'getdistances The result is a string containing 5 decimal values "D1 D2 D3 D4 D5", where the sensors are placed on the front of the robot as follows: D3 D2 D4 D1 D5 4. CONDITIONAL COMMAND EXECUTION -------------------------------- The sensors can be useful for making the movement commands conditional. At any time, the robot keeps in its mind one termination condition. As soon as this condition is satisfied, execution of any movement command is immediatelly terminated. The condition itself consists of three 6-bit numbers x,o,a, which specify XOR, OR, and AND sensor bitmasks respectively. If the current sensory reading is s, the condition is satisfied when ( (s XOR x) AND o > 0 ) OR ( (s XOR x) AND a == a ) AND (s + a > 0) To explain, the number 'x' specifies, which bits need to be negated before further processing - the operation XOR inverts bits of 's' where the corresponding bit in 'x' is = 1. The number 'o' specifies an OR mask - if ANY ONE of the bits that are set in 'o' is 1 in already partially inverted 's', the condition will be satisfied. The number 'a' specifies an AND mask - if ALL the bits that are set in 'a' are 1 in already partially inverted 's', the condition will be satisfied. If both 's' and 'a' are zero (thus s + a is nonzero), the condition is not used. In Robotnacka, the sensory bits are 0, if the robot sees a white paper below, and they are 1, if the robot sees a dark paper or reached above the end of table. For example, a condition that should be satisfied when any of the robot sensors will leave the white paper, would be: x = 0 o = 63 a = 0 If the robot is following a black line (indicated by 1 on the fifth sensor bit - 2^4), and we want it to stop when it leaves this line, we have to find a condition that will be satisfied when it leaves the line. Such condition would use: x = 16 o = 0 a = 16 For a more advanced example, a condition that should be satisfied when both of two binary sensors located in front of the wheels, i.e on 4th (2^3), and 6th (2^5) bits enter white paper, or when the 2nd (2^1) or 5th (2^4) binary sensors will enter black paper, would be: x = 101000 = 40 o = 010010 = 18 a = 101000 = 40 The last of the three examples would be used in combination with move forward 2000 steps command as follows: r'condition 40 18 40 r'fd 2000 The first command has no other effect than setting up the condition. If the condition occurs during the execution of the second command, the robot will be stopped immediatelly, and the forward movement will not be finished. It is possible to verify whether the condition has been satisfied by the operation: r'satisfied which returns the number of steps remaining to be made, when the robot the condition has been satisfied and the robot stopped executing the previous command. The operation returns 0, if the condition has not been satisfied. This operation does not initiate the communication with the robot and returns immediatelly. 5. USING ROBOT IN NETWORK ENVIRONMENT ------------------------------------- If the robot is connected to a computer in a TCP/IP network (Internet or intranet), it can be shared by all users that have access to that network. First, the robot must be connected locally using the connect command described above. Second, the user at the same computer must allow network users to access the robot: new "oleobject [comname robot name r] r'connect "com4 print r'server "on (you should see 1, if the operation is successful, and 0 otherwise) After this command, other network users can create their robot objects, introduce themselves (say their name and password), and connect to a network IP adress instead of local port: new "oleobject [comname robot name n] n'user "John "turtle print n'connect "192.168.145.146 (again, if you see 1, the connection is successfully established, otherwise, you see 0, and possibly some error message box) Now, all the commands and queries sent to object n will be sent to the remote robot through the remote object r. Note that the password is always "turtle (but see below, if you don't like that), and the user name is a word that does not contain spaces. Please note, that you will not be able to connect unless you say your name and password (that is you have to invoke the 'user' procedure first). Arbitrary number of users (as long as the computer and network resources allow) can connect to the robot, and all of them can issue any control command at any time, and this includes also the local user working on the server. Obviously, this can lead into possible conflicts, and the outcome in such cases is not predictable. Therefore, the users can lock the robot for an exclusive use: print n'exclusive "on The user with the exclusive access can control the robot. The commands from other users will be answered with a message box saying that the robot is currently used exclusively by (for example) John. The operation n'exclusive returns either "ok or the name of the user who is currently using the robot. When John is finished with using the robot, he can say: print n'exclusive "off and the robot is again shared by all connected users. To coordinate the exclusive mode, the users may send messages one to another using: print r'message "John "Please\ John\ I\ wish\ to\ access\ the\ robot which will display a message box at John's screen with a message from Fred. Otherwise you will see 0 printed, which means that the operation was not successful. For the case the messages would not help, the administrator can cancel the exclusive access of any user from any other connected computer: r'kickout "admin-password Where the password matters only if it was specified locally at the server by saying: r'password "admin-password Please note that the admin gains an exclusive access after cancelling the exclusive access of another user. Also note that the r'exclusive "off commands returns "err unless you are logged in as some user (r'user...) After you want to close the server and thus disconnect all connected users (but continuing to work with the robot object), you can call r'server "off Warning: some computers have more than one IP address - for example when they have multiple network cards, or a bluetooth device configured for TCP/IP network, etc. In such a case, the command server "on will start listening on all IP-addresses. If you wish to restrict this and listen only on some IP-addresses, you can do so by specifying IP address as an argument to server procedure, for example: server "192.168.145.146 To determine the ip-address(es) of your computer, run the ipconfig utility from the command prompt window. 6. LIMITING ACCESS TO KNOWN USERS --------------------------------- The above networking functions will make your robot vulnerable to arbitrary use by any user of your server's TCP/IP network. If you are on the Internet, you certainly wish to specify the admin-password, and you might want to restrict access only to specific users. As soon as you say: r'userfile "|path-to-your-user-file| the "turtle password will be disabled, and only valid users with correct passwords will be able to connect to your remote robot successfully. You setup these users by: r'adduser "name "password r'deluser "name and you can get a space-separated list of the users by: r'listusers After you say: r'userfile "off The user file will not be used, and the "turtle password will work again. 7. IMPROVING THE ROBOT PRECISION THROUGH CALIBRATION ---------------------------------------------------- The movements of the robot are imperfect due to very small differences of the wheel sizes. These errors accumulate and the mathematics of the mechanics is very cruel: a small error of 0.01 mm in the wheel size causes the robot to make error of more than 3 mm when drawing a square with the length of sides = 1 m. The error in the distance between the two wheels is causing further imprecisions. However, the error can be measured and compensated for, we call this process robot calibration. To calibrate your robot, place it ca. 25 cm from the corner so that the empty space will be in front and to the right of it, and type: r'drawcalib Please look at http://www.robotika.sk/projects/turtlesoft/images/robot_setup_calibration.gif to see how you should prepare the robot arena for calibration. The pen should be inserted in the robot. The robot will draw two angles, and a short line in between of them, and then two large almost-squares and two circles. Measure the following variables: d1 = distance in mm of the starting and ending point of the first angle (it is very narrow, this value will be around 3mm or even less) d2 = the length in mm of the short line between the two angles d3 = distance in mm of the starting and ending point of the second angle (this will be broader). Both d1 and d3 should be positive, if the robot "turned more", that is if it returned more to the left from its beginning of the drawing location. They should be negative, if the robot "did not turn enough", that is if it returned more to the right from its beginning of the drawing location. d4 = the distance in mm of the starting and ending location of the first drawn square d5 = the distance in mm of the starting and ending location of the second drawn square d6 = diameter in mm of one of the two circles d7 = diameter in mm of the other of the two circles Please look at http://www.robotika.sk/projects/turtlesoft/images/robot_calibration.gif for an example how the calibration picture might look like. Once you made your measurements, write them down. Each time you create a new robot object, you can calibrate it by calling: r'calibrate d1 d2 d3 d4 d5 d6 d7 using the above values. The robot will then compensate for the drawing errors. To cancel calibration, say: r'calibrate 0 0 0 0 0 0 0 8. RECORDING THE ROBOT TRAJECTORY --------------------------------- You can record the commands sent to the robot to the file or to the memory in order to replay the same sequence again. To start recording, say: r'logfile "|C:\robotnacka.log| where you can replace the file C:\robotnacka.log with whatever file you would like to use for logging. This file will be created anew at this moment. To stop recording, say: r'logfile "off You can then replay the sequence of commands by typing: r'replay "|C:\robotnacka.log| If you prefer to use the memory instead of files, you can achieve the same by the following three commands: r'logfile "memory r'logfile "off r'replay "memory The replay command returns 1, if the replay was started properly, otherwise it returns zero. In both cases, it returns immedialelly, however, you can monitor the progress of the replay sequence by two commands: r'replay "status will report how many commands are left to be sent to the robot, and r'replay "timeleft will report the remaining time of this replay sequence in milliseconds. Finally, you can skip over the next command to be replayed by saying r'replay "skip (you can issue this command multiple times in order to skip multiple replayed commands), and you can skip some time ahead in the sequence (which can in result skip zero or more commands) by saying: r'replay "1000 or another time in milliseconds (in this case 1 second). To stop the replay at any time, type: r'replay "stop 9. CONTROLING ROBOT GRIPPER ---------------------------- If your robot has a gripper manipulator installed, you can control it by the following commands: r'gripper "down ; move the robot gripper completely down r'gripper "up ; move the robot gripper completely up r'gripper "open ; open the gripper r'gripper "close ; close the gripper r'gripper "upwards ; move the gripper a little bit upwards r'gripper "downwards ; move the gripper a little bit downwards r'gripper "tighten ; close the gripper a little bit r'gripper "loose ; open the gripper a little bit r'gripper "fix ; stop moving the gripper now After the robot is turned on, the gripper automatically drives down and opens itself completely. 10. MISCELANEOUS FUNCTIONS -------------------------- If for any reason you need to change the default communication parameters (tuned for the bluetooth serial port device), you can issue command: r'setcomparam baud fparity ctsflow dsrflow dtrcontrol dsrsensitivity continueonxoff foutx finx rtscontrol bytesize parity stopbits where the meaning of these communication parameters is explained by Microsoft(TM) at: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/devio/base/dcb_str.asp Use -1 for those parameters that you do not wish to change. Use -2 for baud if you wish that no settings are modified after the port is open. This is required for some USB BT dongles on some systems. If you need to turn off all the messageboxes, you can issue command: r'messages "off and turn them on again by: r'messages "on This can be needed if your network robot server is not attended by any user. The current version of the robot firmware can be determined by: print r'getversion The name of the local communication port where the robot is connected (or IP address) can be obtained by print r'getport And the robot name (its number) can be determined by: print r'getnum If you want to change the network port where the server is listening, you can say: r'portnumber port-number to change it before you call r'server "on, or r'connect "ip-address (if you specify -1 as port, the default port will be configured). Sometimes it might be useful to keep track of the users logging into the server. To turn reporting on, use the command: r'netreport "|C:\netreport.log| or a different file. If you specify "off as the argument, the reporting will be disabled. The robot can draw text using various fonts. It recognizes the Borland CHR stroked font files which used to be packed with MS DOS versions of Borland development tools, such as TurboPascal 5.5 ;). "Stroked" means that the font is encoded as [absolute] movements of the pen and thus these fonts are suitable for a drawing robot, and they can be arbitrarily scaled, contrary to bitmap fonts. To draw text, enter command similar to this one: r'drawtext "Imagine 10 "|D:\TP\LITT.CHR| where the first argument specifies the text to be drawn, the second argument the text size, and the last argument contains the path to the font to be used to draw the text. The robot will start drawing text and the call will return only after the text is finished. If you prefer to spawn drawing in the background (note that unpredictable results can occur, if you try to send drawing commands while the text is drawn), you can add a minus sign in front of the text size. You might be interested in a shareware program EASY FONTS v3.0 for Windows for converting TrueType fonts to CHR fonts, (http://digilander.iol.it/pnavato/EasyFonts/) You might be satisfied just with the standard Borland fonts, which are available for free after Borland has released TP5.5 for free (http://community.borland.com/article/0,1410,20803,00.html) The robot can produce sound. Nomally, when the robot is on, it makes a short beep every 10 seconds. Even though you might think the sound is annoying, it is important to notify you to turn it off when you leave it. The robot can also play tones of a given frequency. The procedure r'tone 440 200 will start to play the tone A for 200 ms. You can specify any frequency between 0 and 20000 (even as a floating-point number). Note that if you send a new tone while another tone is being played, the new tone will start playing immediatelly even if the previous tone did not finish to play its whole duration. You can specify a minus sign before the frequency if you wish to turn the regular 10-second beeps of the turtle on again. Otherwise, the turtle will be quite after the first tone is played. Todo: * saving admin password to users file * auto pen up/pen down after 1 minute of inactivity * message boxes in separate thread? * encrypt/decrypt all passwords? maybe later... (currently only scrambled) Known issues: * If you look at the rotating robot when you are tired, the robot will seem to rotate in the opposite direction after it will have stopped. ;) Common problems: Problem: I am connecting to a remote robot server using r'connect "ip-address and I am getting a messagebox saying: "Failed to connect, Error=10061". Solution: This means that you either specified an incorrect ip-address, you are not connected to the same network, there is a firewall in between or the robot server was not started using r'server "on. Problem: When connecting to the robot on a local virtual serial port, the robot beeps, but the connect method returns 0, and the communication is not established. Solution: This might be a problem with some third-party BT software, which doesn't like any communication settings changed once the port has been open. Please call the method setcomparam with -2 in baud parameter before calling the connect method. Requirements: * Windows 98/2000 or newer * serial port connected to robot (Bluetooth serial port or special IR device) * robot communicating with Robotnacka protocol History of changes: * 16/02/2005 - Odometry, wait command * 18/01/2005 - Java API, stand-alone executable, and DLL versions * 11/01/2005 - mainly added networking functionality * first release 31/12/2004 Copyrights/Licences: * robot.ocx: Copyright (c) 2004, DAI, FMPhI Comenius University, ppetrovic@acm.org * Imagine: Logotron Ltd. & EDI FMPhI * robotnacka v2: Copyright (C) 2004 Microstep-MIS APPENDIX A - INTERNAL SERIAL COMMUNICATION PROTOCOL Condition setup(11B): !EaiijjkkYY - sensor condition: the position and speed commands will be executed only when ((s ^ ii) & jj != 0) && ((s ^ ii) & kk == kk) when satisfied, robot replies with: EaiiiiYY - remaining steps iiii Position command(10B): !PabxxxxYY xxxx-number of steps <0,9999> a-turtle number <0,9> b-direction: ‘f’’b’’l’’r’ = ‘forward’’backward’’left’’right’ YY=checksum Speed command(10B): !RabxxyyYY xxyy-speed of left wheel(xx) and right wheel(yy) from interval <0,99> a-turtle number <0,9> b-direction: ‘f’’b’’l’’r’ = ‘forward’’backward’’left’’right’ YY=checksum Position speed command(14B): !QabxxyyzzzzYY xx-speed of rigth motor, yy-speed of left motor zzzz-number of steps for the faster motor a-turtle number <0,9> b-direction: ‘f’’b’’l’’r’ = ‘forward’’backward’’left’’right’ YY=checksum Gripper commands(6B): !HabYY a-turtle number <0,9> b-operation: 'u'=up, 'd'=down, 'z'=close, 'o'=open, 'U'=upwards, 'D'=downwards, 'Z'=tighten, 'O'=loose Other commands, short(5B): !IaYY init - reset all buffers !DaYY pen down !UaYY pen up a-turtle number <0,9> YY=checksum Response(immediatelly after command is received): OK: XaYY checksum error: ZaKKYY, KK - correct checksum after command is finished (only position commands): WaYY Queries(5B): ?AaYY - alive reply: XaYY - alive ZaKKYY - checksum error ?SaYY - sensor state reply: SaxxYY - xx <0,64> - bit state of 6 sensors,1= black,0=white ZaKKYY - checksum error ?VaYY - batery voltage reply: VaxxYY - xx batery voltage (in deciVolts) 5.1V is critical low power and causes the robot to beep, must be recharged ZaKKYY - checkum error ?CaYY - current activity reply: YaYY - speed command NaYY - position command WaYY - idle ZaKKYY - checksum error ?FaYY - version of firmware Servis commands(use with caution): #Mabbbbbbbb - set turtle BT name (store to EEPROM), a - number of characters(max 8), bbbbbbbb new name, must be padded with junk to form 8 bytes Reply: BadName, LongName, or the new name. Applies after turtle reset. #Na - set turtle number (store to EEPROM) a - turtle number(0-9), Reply: BadNum, Num a Applies after reset. (in addition to usual robot commands, robot component exchanges internal packets that start with '/' - these are described in the file internal_protocol.txt) APPENDIX B - ROBOTNACKA TECHNICAL SPECIFIACTIONS * Stepper motors MICROCON SL17 * Solenoid with magnet * 6V lead maintenance-free accumulator, 3.3Ah * wheel radius: 25 mm * wheel base: 180mm * height: 70mm * base diameter: 210mm * weight: ca. 2kg * steps to turn 360 degrees: 2880 (=360 * 80) * controller: 8bit microcomputer AT89S8252 * infrared module mac SFH5110, HDSL4400 IR LED - direct visibility range: 2m * bluetooth module Infineon - range 10m First version of the robot is described at www.robotika.sk APPENDIX C - EXAMPLES 1. Robotnacka is moving along a circle and the logo turtle visualizes its movements ignore r'pos 1 pu setpos [0 0] pd r'fdspeed 10 30 repeat 3000 [ make "x r'pos 0 setpos se (first parse :x) / 8 (item 2 parse :x) / 8 setheading 180 * (item 3 parse :x) / 3.1415926536 wait 100 ]