Department of Engineering

IDP: Computing FAQ

  1. When I 'Make' I get an error message saying something about recipes. What's wrong? - Try removing spaces and brackets from file and folder names
  2. When I use the geany icon, the compiler complains about the robot commands - make sure you're using the IDPgeany icon, not the geany icon left over from the 1st year. The IDP icons appear when you start a session using the 1BRobot option
  3. When I use the geany IDP icon it doesn't work - you need to use Make in the Build menu: clicking on the Brick icon isn't enough.
  4. What files do I drop into the compiler icon? - all the files that comprise the project except files that you have #included. You need to drop them in all at the same time. Alternatively, have all (and only) the project's files in a folder, and drop the folder onto the compiler icon.
  5. I've created a file in geany, but I can't compile it - Quit from geany, then drop the source file(s) into geany
  6. When I drop files on the compiler icon, an error window appears saying "Error launching application" - refresh the desktop icons by clicking on the Applications/CUED 2nd year/ Start 1BRobot" menu item.
  7. Do I have to keep selecting and dropping my files into the geany icon? - No. If you do it once and don't create any new files (or add any #include lines) then you can repeatedly Save and Make. If you quit geany and run it again, it should resume from its previous state.
  8. I've been developing code on windows. Now I've copied it onto the CUED machines it doesn't compile - use dos2unix to convert the file's line-endings.
  9. I've a comment on the same line as an #include and my code doesn't compile - It's CUED bug. For now, remove the comment
  10. I'm using cout but the output's not appearing - Make sure you're using endl (this is because of the way geany buffers output)
  11. I'm having trouble with extern - If you have
       int speed=3;
    
    in a file outside of all functions, then this variable can be accessed from other files as long as the other files have
       extern int speed;
    
    but if instead of int speed=3; in the first file you have
       const int speed=3;
    
    the variable isn't visible from other files. Here's a table showing some examples of how the contents of 2 files can interact.
    File 1File 2Outcome
    int i;
    int main()
    {
      i=5;
    }
    
    extern int i;
    Compiles. There's only one variable called 'i'.
    int i;
    int main()
    {
      i=5;
    }
    
    int i;
    Fails (multiple definition of 'i') because when the 2 compiled files are linked together they each have an 'i' that is visible to the other.
    extern int i;
    int main()
    {
      i=5;
    }
    
    int j;
    Fails (undefined reference to 'i') because File 1 expects an 'i' variable to be available from another file.
    extern int i;
    int i;
    int main()
    {
      i=5;
    }
    
    int j;
    Compiles. The int i; line takes precedence over the extern int i; line.
    static int i;
    int main()
    {
      i=5;
    }
    
    int i;
    Compiles. File 1's 'i' is private - there are 2 variables called 'i' but they don't clash
    const int i=5;
    int main()
    {
      ;
    }
    
    int i;
    Compiles. File 1's 'i' is private (const vars are static by default) .
    extern const int i=5;
    int main()
    {
      ;
    }
    
    int i;
    Fails (multiple definition of 'i') because when the 2 compiled files are linked together they each have an 'i' that is visible to the other. Why? Because if a variable is declared as extern and it's initialised, then memory for that variable will be allocated. So in this situation there's an 'i' in each file.
    extern const int i=5;
    int main()
    {
      ;
    }
    
    extern const int i;
    Compiles. There's only one 'i' variable in the resulting program - the 'i' in file 2 refers to the 'i' in file 1. If the line in file 2 was extern const int i=2;, linking would fail
  12. What is the default ramp period? If you don't know, set the ramp period explicitly.
  13. My robot's not responding to my program any more - This may be because previous instances of the program are still running and still connected to the robot. Open a Terminal window and type
      ps -u yourID
    
    You will get a long list of programs that you're running, looking a bit like the following
     2048 ?        00:00:02 gnome-terminal
     2052 ?        00:00:00 gnome-pty-helpe
     2053 pts/0    00:00:00 bash
     2071 pts/0    00:00:00 man
    
    If you see your program in this list, you can kill it by doing
       kill PID
    
    where PID is the number in the first column of the row where your program's mentioned. If your program's called test-robot you can list only the processes involving this file by typing
      ps -u yourID | grep test-robot
    
  14. How can I comment out a region of code? - you can enclose the code with /* and */ but if the enclosed code already uses such comments, you'll have trouble. An alternative is to use the "Conditional Compilation" idea you met earlier. If you enclose the code with
    #ifdef USETHISCODE
     ...
    #endif
    
    (what you use instead of USETHISCODE is up to you) the enclosed code will only reach the compiler if earlier you have
    #define USETHISCODE
    
  15. When I read input the values are wrong. - An input value is low if the reading is low or if 0 was the last value written. So write 1 to each of the input bits before reading any input.
  16. My control box is turning itself off - It will do so to protect itself.
    • Maybe something's dodgy with the power cable (short circuits in the red connector)
    • Maybe long instead of short screws have been used to connect the motor to the chassis, thus partly jamming the motor.
    • Maybe too much power is being drawn through the students' own circuits (try removing the circuitry and seeing if problems persist).
    • Maybe a too-rapid change of motor speed is creating back-EMF. Is the WiFi card hot?
  17. Why don't the motors work in my test program? - the motors stop when the program ends. Perhaps you're sending commands to the motors without using the sleep or delay functions at the end to give the motors a chance to respond to the commands.
  18. I can link to the robot ok, but it doesn't respond - the problem could be that you're trying to have more than one link to the robot. If for example you have
       robot_link rlink;
    
    in several files, the robot will be confused, because only one of the rlinks can be connected to the robot - the one that you first successfully initialised. Another way to have more than one robot_link is to pass a robot_link by value to a function - doing so creates a copy. Use "call by reference" or make the variable a global.
  19. Now that we've put everything together it's not working properly but we don't know whether the problem is with the hardware, software or electronics - It helps to do as much pre-testing ("unit testing") as possible. If the symptoms are repeatable, identifying the trouble shouldn't be too hard. Simplify the code and hardware as much as possible (if, for example, sensors aren't working properly, disconnect the motors and run a dedicated sensor-testing program). Check the return values of the functions you call. It may be possible to swop a piece of hardware (a WiFi card, maybe) for test purposes.
  20. scp doesn't work - Here's a step-by-step guide to running a cross-compiled program.
    • Produce an executable program that will run on the robot. You can do this by using the IDPgeany-arm icon. The resulting program will have the suffix .arm. Let's suppose that you have a program called hello.arm
    • Copy the file to the robot. To do this you need to use the unix command line to run a program called scp (SecureCoPy). Use the Terminal program.
    • A short Unix crib is online, telling you about 3 useful unix commands: ls (to list files), pwd (to see which directory (aka folder) you're in) and cd (to change directory). It's useful to go to the directory (aka folder) where your program is. You can do this by typing
       
         cd directory-name
      

      but there's a short cut. Using the File Viewer, display the folder where hello.arm is (in this example it's in tpl's IDP/python2 folder). In the Terminal window, type cd followed by a space, then with the mouse drag the folder's name (in this case python2) into the Terminal window. You should get something like this.

      Press the Enter key to change directory.
    • Now use the scp command from the Terminal window, replacing 100 in the example below by the number on the WiFi card.
      scp hello.arm team@wlan-robot100.private:hello.arm
      
      • scp - scp is the program you're running. It's not in the current folder (it's a system command) so you don't need an initial ./
      • hello.arm - the name of the file you're copying over.
      • team - the name of the user on the robot. It's always team
      • wlan-robot100.private - the name of the robot you're using. Don't use 100. Use the number on the WiFi card.
      • hello.arm - the name the file will have on the robot. It needn't be the same as the original file-name
      scp might print messages about authenticity. Don't worry - just say yes. It will then prompt for the team's password: enter the password printed on the side of the microcontroller box. When you type the password nothing appears on screen.
    • Run the program. First log into the robot, replacing 100 in the example below by the number on the WiFi card.
        ssh team@wlan-robot100.private
      
      After typing the password correctly you'll be logged into the robot and you'll be given a Unix prompt . You can type ls to list the files on the robot. You should see hello.arm there. To run it, type
         ./hello.arm
      
      (the '.' means the 'current folder' - by default, the system doesn't look in the current folder for programs, so you need to make it look there)
  21. Emergency stop isn't working for motors 3 and 4 - it's a bug. It works for motors 1 and 2.
  22. The motors aren't taken any notice of the program. They don't even stop when the program stops - Make sure that you've plugged the motor lead into the MOTORS socket rather than the ANALOGUE socket
  23. How do we use the Sensor Simulator PCB? - Connect the transformer to the I2C box with the power cable, and connect the Sensor Simulator PCB to the I2C box with the grey ribbon cable. Then power-up and wait a couple of minutes until the WiFi card's lights briefly flash. Your I2C box might eventually use a few ports to communicate with the robot. Each port can handle 1 byte of data (8 bits; a value in the range 0-255). The Sensor Simulator PCB can be used to simulate one port at a time - don't change port while the power's on. Set the port address to a value in the range 0-7 (the yellow switch with a 4 on it isn't used). If for example you set it to 3 (by setting the brown and red switches to 1), then you'll need to use WRITE_PORT_3 when you send data, and READ_PORT_3 to get input.
    • Testing output - Set all the data switches to 1 (the switches will otherwise override the chip's outputs). In your program, put something like
        
        rlink.command(WRITE_PORT_3, 64+16+4+1);
      
      When you run the program, the LEDs corresponding to the bits set in the transmitted data will be lit. Try writing a program to set the LEDs on one at a time at half-second intervals.
    • Testing input - Set the data switches to a value of your choice. This simulates a value that your robot's sensors might be returning. Note that this value should also be indicated on the LEDs (on = 1). If the LEDs for bits which should be high are not on, this is likely to be because the corresponding bits in the chip's output port have not been set high and are overriding the switch value, so run a program with rlink.command(WRITE_PORT_3, 255); in it. If you then have
        int v=rlink.request (READ_PORT_3);
        cout << "Value="  <<v << endl;
      
      you should see the value that you set the data switches to.