Robotics StackExchange | Archived questions

Rospy and os.mkdir() issue - unable to create a directory

Hi guys!

I have posted on Stackoverflow this question however since it's also ROS-related I've decided to do that here too. My original post is located here.

I have created a dashboard (inheriting from the Dashboard class based on rqt). I have followed the source code from PR2 and COB in order to populate my widget. In addition some of my toolbar entries also open views containing one or multiple widget (subclassing QWidget) of the same type. Each widget is bound to a ROS process that is taken from a configuration loaded on the parameter server. The purpose of the widget is to allow basic control (start,stop) as well as monitoring of the ROS process status (inactive, running, finished, failed). In the image below you can see more or less how things are connected internally:

image description

There are several goals that the launched bash script (in the image noted as Bash (detached)) has to fulfill are as follows:

This solution allows me to continuously monitor a ROS process even if my dashboard stops working (breaks down or is stopped intentionally). Both the .bash and .proc files are further used to restore the state of the application upon relaunch. More on this design can be seen here.

Now I'm currently facing a strange problem (as described in the first link in this post) - whenever I call os.mkdir() following doesn't happen:

Here is the code that I use to create the directory:

def checkRootDirExists(self):
    '''
    Check if the process folder is present and create it if not
    '''
    if not exists(self.dir_name): # Using os.path.exists()
      rospy.loginfo('SR2: Process directory "%s" doesn\'t exist and therefore will be created', (self.dir_name+'/'))
      try:
        mkdir(self.dir_name)
      except OSError as e:
        if e.errno != errno.EEXIST:
          rospy.logerr('Directory exists')
        elif e.errno != errno.EACCES:
          rospy.logerr('Access violation')
        else:
          rospy.logerr('Something else happened')
    else:
      rospy.loginfo('SR2: Process directory "%s" already exists', (self.dir_name+'/'))

I have tried simply using except Exception in order to cover all the exception types that can be raised when executing mkdir() since I'm not sure which ones it is possible to raise) along with OSError and several other types that I thought may have some relation to mkdir().

Is it possible that rospy's logging is hiding something from me in this case?

Asked by rbaleksandar on 2016-02-20 12:37:33 UTC

Comments

The only case that you don't have a log statement for is success. Why not add a log statement immediately after mkdir to confirm that it's succeeding?

Asked by ahendrix on 2016-02-20 13:54:42 UTC

No need for that. A success would be a created directory. Since no directory is created it is obviously failing. :P That said I added a loginfo() entry right after calling mkdir() and I got its output on my screen. This would mean no exception has been raised, right?

Asked by rbaleksandar on 2016-02-20 14:28:33 UTC

I just want to exclude ROS as the reason for this strange behaviour.

Asked by rbaleksandar on 2016-02-20 14:28:57 UTC

It looks like os.mkdir is succeeding. If you're running your node through roslaunch, it will change the working directory. Are you sure you're passing an absolute path to os.mkdir() ?

Asked by ahendrix on 2016-02-20 14:48:39 UTC

I am getting close to the source of the problem. os.mkdir() is succeeding but for some reason it does that to a much later point. I do believe that the problem is the whole multiprocess/multithreading model I have. It may be due to delays in the processing of the events that I have.

Asked by rbaleksandar on 2016-02-20 15:17:26 UTC

Sadly due to the fact that I am starting detached processes the ouptut (errors etc.) for the ROS processes that I am launching comes at a much later point in time - after they get killed. This is...terrible. LOL I have no idea how to fix all that.

Asked by rbaleksandar on 2016-02-20 15:18:37 UTC

Answers