Report all bugs, problems, and errors occurring from any use of the simulator.

If possible, try to include all the information below:
How is simulator being used (manual/autonomous mode)
Steps to duplicate problem (if consistent)
Observed trends in problem occurance (if intermittent)
Error output (from command window)
MATLAB version
Operating System

If the error occurs during autonomous code execution, send your Autonomous Control Program to CreateMatlabSim@gmail.com.
If the error depends on map or configuration files being loaded, send them as well.

Thank you.

When simulator is in autonomous mode and given a drive command with 0 radius (i.e. turn in place), the robot disappears from the screen.

SetFwdVelRadiusRoomba(serialObject, 0.3, 0);

This happens every time - Matlab version is R2009b and OS is Windows XP.

The version 1.0 release fixes this bug. Thank you for your help in reporting this, and sorry about the long response time.

ReadSonar does not function properly in 1.1. Returns the same sonar reading for all 4 sensors.

Line 3312 of CreateRobot.m
Line read:                     distance= distSonar(1);
Should read:                 distance= distSonar(varargin{1});

• Michael Goetz

Just released version 1.2 to fix this bug. Thank you for letting me know.

Another change, sorry that this didn't make it into Version 1.2; but the comments on line 3273-3276 and 3351-3354of CreateRobot.m should read

        %       1 - Front
        %       2 - Left
        %       3 - Back
        %       4 - Right

rather than

        %       1 - Right
        %       2 - Front
        %       3 - Left
        %       4 - Back

This also means that for the Cornell MAE4180/5180 blankprogram.m file in pre-lab 1, the sonar sensor reading code should read:

        sonarF = ReadSonar(serPort,1);
        sonarL = ReadSonar(serPort,2);
        sonarB = ReadSonar(serPort,3);
        sonarR = ReadSonar(serPort,4);

• Mike

The Creates in the lab at Cornell are set up such that the sonar_num argument used in ReadSonar or ReadSonarMultiple is:
1 - Right
2 - Front
3 - Left

…at least as I heard last. I changed the original implementation of SonarSensorCreate to ReadSonar and switched the order up to deal with the real Create's setup. Was there some documentation or code somewhere that I missed that still indicates a sonar_num = 1 argument will return a reading from the front sonar?

I know this doesn't apply to this question, but hopefully this can answer some potential questions:
For other schools that may want to implement sonar, I realize this system is somewhat inconvenient. I am working on a new version of configuration files that will make the sensor setup more modular, but this may take a while to implement.

My bad, I checked the code and realized I was indeed calling incorrectly in ReadSonar, but calling correctly in ReadSonarMultiple. I can't believe I missed that after the last error I fixed. The comments themselves are accurate for Cornell's setup, but ReadSonar has now been modified. Version 1.3 will be up as soon as I double-check everything so I hopefully don't screw up again.

Thanks, Mike for bringing this up.

This question seems to come up a lot so I figured I'd make a post and put it on the listserv. If you are at Cornell and are using a control program with the simulator that is outputting a message along the lines of:

Error retrieving or saving <sensor name> data.

This is not from the simulator program itself. This message is being output by the control program. This is because the function call to read the sensor is surrounded by a try-catch statement that looks something like:

try
    [output variables] = sensorFunction(serPort);
    datastore.sensorName = [datastore.sensorName ; toc output variables];
catch
    disp('Error retrieving or saving <sensor name> data.')
end

Now in general, this is a good thing to have. This will provide a description of where the problem occurred, but it will not interrupt the program every time an error occurs. If it is a one-time or infrequent error, the program could still work fine. However, if this error occurs every time or most of the time, something needs to be fixed.

Usually in the case of frequent errors, the real error message will be a lot more helpful than "Error retrieving or saving…". There are many ways to have the error message show up, but here are two:
One: Comment out or delete the try statement and everything in the catch block. It should look like:

% try
    [output variables] = sensorFunction(serPort);
    datastore.sensorName = [datastore.sensorName ; toc output variables];
% catch
%     disp('Error retrieving or saving <sensor name> data.')
% end

Two: Add a statement to rethrow the error inside the catch block. It should look like:

try
    [output variables] = sensorFunction(serPort);
    datastore.sensorName = [datastore.sensorName ; toc output variables];
catch me
    disp('Error retrieving or saving <sensor name> data.')
    rethrow(me)
end

These will do essentially the same thing, except the second one will also output "Error retrieving…". In either case, you can look at the normal MATLAB error message output and at least get an idea of where it's coming from. If you still don't know how to fix it or what it means, then you should post in this forum with the contents of that message.

A couple of common errors that occur can mostly be ignored. Firstly, if you tend to get "Overhead localization lost the robot" when you first run the control program, but not after that (on the simulator), this is probably caused by you starting the robot at the default position of (0,0,0). For some reason, the function OverheadLocalizationCreate for the real robot outputs  when it does not see the robot. Cornell's control programs have the statement:

[px, py, pt] = OverheadLocalizationCreate(tagNum);
if (px == 0 && py == 0 && pt == 0)
    % Only display if not just starting program at origin
    disp('Overhead localization lost the robot!')
    norobotcount = norobotcount + 1;

So when you start out at the default position of (0,0,0), it thinks the sensor can't see the robot. You can fix this by setting the robot position somewhere else (even just off by a little), or by changing the if statement to the following, assuming your robot starts moving right away:

if (px == 0 && py == 0 && pt == 0 && toc > 0.01)

Another common thing is to get all of the messages "Error retrieving of saving …" for each of the sensors once when you hit the Stop button to cease execution of the autonomous control program. This is because the simulator will deliberately throw an error when you hit the stop button to quit the control program, and then catch the error within itself before it displays. You can avoid outputting the "Error retrieving or saving…" messages by making all of your catch blocks look like:

catch me
    % Don't display error from quitting control program in simulator
    if ~strcmp(me.identifier,'SIMULATOR:AutonomousDisabled')
        disp('Error retrieving or saving <sensor name> data.')
    end
end

Or, better yet, you can allow the error to propagate through so it quits the control program earlier by doing:

catch me
    % Propagate the error used by the simulator to quit the control program
    if strcmp(me.identifier,'SIMULATOR:AutonomousDisabled')
        rethrow(me)
    else
        disp('Error retrieving or saving <sensor name> data.')
    end
end

Other than that, a couple other fixes to try against repetitive errors are first restarting the simulator. If you accidentally run two versions of SimulatorGUI at once it does funky things. Next try restarting MATLAB. This should also take case of the socket error when getting overhead localization data on the real robot. Finally restarting the computer. I'm not sure what that might do for you though, other than making it run a little faster by freeing up memory.

Sorry for such a long post, but hopefully this proves helpful. Let me know if anything seems to be incorrect, if you have a better method for dealing with stuff like this, or if there are any other common errors that I should address.

Simulator is in manual mode

Steps to duplicate the problem:
1) Load the map file, ExampleMapFile2.txt, in iRobot Create Simulator Toolbox (ver 1.3)

2) Set iRobot's position as shown in the image below.

3) Set the Cliff sensors visible

4) Let iRobot move straight forward to touch the intersections of the two lines, which is shown in the image below.

Error output (from MATLAB command window):
An error regrading "CAT arguments dimensions are not consistent." is displayed in MATLAB Command Window as shown in the image below.

MATLAB version: 7.14.0.739 (R2012a)
Operating System: Microsoft Windows XP Version 5.1 (Build 2600: Service Pack 3)

Possible solutions:

In CreateRobot.m, change the code at line #728 and #729,

x_int= ;
y_int= ;

into

x_int= [x_int ; x_posInt'];
y_int= [y_int ; y_posInt'];

Then, the simulator may work smoothly in this scenario.

Simulator is in manual mode

Steps to duplicate the problem:
1) Load the map file, ExampleMapFile2.txt, in iRobot Create Simulator Toolbox (ver 1.3)

2) Set iRobot's position as shown in the image below.
     image: https://picasaweb.google.com/lh/photo/YioExNg-c4vu5BbsDgAy12rzyQw1mxFkyiiDwmom_CA?feat=directlink

3) Set the Cliff sensors visible

4) Let iRobot move straight forward to touch the intersections of the two lines, which is shown in the image below.
     image: https://picasaweb.google.com/lh/photo/12T7aAfeEsfgUiD1znHwamrzyQw1mxFkyiiDwmom_CA?feat=directlink

Error output (from MATLAB command window):
An error regrading "CAT arguments dimensions are not consistent." is displayed in MATLAB Command Window as shown in the image below.
image: https://picasaweb.google.com/lh/photo/0XqzlUo-ZsmueaMUQP5yM2rzyQw1mxFkyiiDwmom_CA?feat=directlink

MATLAB version: 7.14.0.739 (R2012a)
Operating System: Microsoft Windows XP Version 5.1 (Build 2600: Service Pack 3)

Possible solutions:

In CreateRobot.m, change the code at line #728 and_ #729_,

x_int= [x_int ; x_posInt];
y_int= [y_int ; y_posInt];

into

x_int= [x_int ; x_posInt'];
y_int= [y_int ; y_posInt'];

Then, the simulator may work smoothly in this scenario.

In version 1.3, ReadSonar(obj) reads the distance returned by the front sonar sensor according to the function definition:

function distance= ReadSonar(obj,varargin)
        % distance = ReadSonar(obj)
        % Reads the distance returned by the front sonar sensor
        % Functionality has changed from the WOOSH software
        % ...

Therefore, the code between line #3308 and #3313 in CreateRobot.m:

% Generate reading for sensor
 distSonar= genSonar(obj);
                    
% Extract value for output
if isempty(varargin)
    distance= distSonar(2);

Should be changed into:

% Generate reading for sensor
 distSonar= genSonar(obj);
                    
% Extract value for output
if isempty(varargin)
    distance= distSonar(1);

The reason is due to the output of genSonar(obj) is :

function distSonar= genSonar(obj)
        % ...
        % ...
        % ...
        % Output:
        % distSonar - Vector of doubles [front left back right],
        %   distance along each line of sight to nearest obstacle
            
        % ...
            
            % Cycle through all sensors
            distSonar= obj.rangeSonar*ones(1,4);    % Preallocate for speed
            for i= 1:4
                % Calculate position and orientation of the sensor
                % Assume sensors are at the edge of the robot
                th_sensor= obj.thAbs+(i-1)*pi/2;
                x_sensor= obj.posAbs(1)+obj.radius*cos(th_sensor);
                y_sensor= obj.posAbs(2)+obj.radius*sin(th_sensor);
                
                % Get noise value to change reading of sonar
                noiseVal= noiseAvg+noiseStDev*randn;
                
                % Solve for distance using general function
                distSonar(i)= findDist(obj,x_sensor,y_sensor,...
                    obj.rangeSonar,th_sensor)+noiseVal;
            end
        % ...
        % ...

The four sonar sensor are cycled through in counterclockwise sequence, i.e. from Front, Left, Back, to Right.

The description of the function genSonar on the page #27 of Code Documentation (http://web.mae.cornell.edu/hadaskg/CreateMATLABsimulator/Code%20Documentation.pdf),

genSonar:
… Note the difference between the order of output of genSonar ([front left right front]), and the sonar sensors that ReadSonar (right) and…

should be,

genSonar:
… Note the difference between the order of output of genSonar ([front left back right]), and the sonar sensors that ReadSonar (front) and…

The CreateRobot.m in version 1.3 has three functions with a statement,

wheelLeft= min(max(wheelRight,-0.5),0.5);

The statement should be

wheelLeft= min(max(wheelLeft,-0.5),0.5);

These function are

 275      function manualKeyboard(obj,velChange)
2776      function SetFwdVelRadiusRoomba(obj,FwdVel,Radius)
3001      function SetFwdVelAngVelCreate(obj,FwdVel,AngVel)

In version 1.3, the result of the translator function SetLEDsRoomba is different from its counterpart in the MTIC toolbox from the US Navy Academy.

The SetLEDsRoomba in the iRobot simulator defines the LED input as follows:

% LED - Double, controls states of the Play and Advance LEDs
%   0 - Both off
%   1 - Advance on
%   2 - Play on
%   3 - Both on

However, the counterpart in the MTIC toolbox defines that,

Syntax

[ ] = SetLEDsRoomba(serPort, LED, Color, Intensity)

Description
Play and Advance LEDs are only on/off and are controlled by LED argument: LED = 0 (off), 1 to turn Play green or 2 to turn Advance green, and 3 to turn both green.

.

Therefore, the SetLEDsRoomba in the iRobot simulator should be re-defined as follows:

% LED - Double, controls states of the Play and Advance LEDs
%   0 - Both off
%   1 - Play on
%   2 - Advance on
%   3 - Both on

The code between line #2731 and #2743 in CreateRobot.m should be:

if LED == 0
    play= 0;
    adv= 0;
elseif LED == 1
    play= 1;
    adv= 0;
elseif LED == 2
    play= 0;
    adv= 1;
elseif LED == 3
    play= 1;
    adv= 1;