Version Control

This week didn’t start out the way I had planned, but it did teach me a valuable lesson about the significance of version control! I was working on adding gazebo to the exercise when I came upon this. I realised that the existing exercises didn’t seem to work properly. The reason for this is yet unknown, although it was most likely caused by two or more exercises requesting the same port in the websocket server. And things became even worse when I realised I hadn’t been committing to my changes for a few days. As a result, I had to restart the work from the begining.

As I was going through the process of creating a new exercise, I figured out the solution for the problems that we were having with exercise connectivity and dockerfile. Previously, when I mounted the container’s repository with a local repository, the exercises weren’t unable to connect. The reason for this was due to the change in structure of repository caused by usage of RUN rsync -a --exclude 'ace-builds' /RoboticsAcademy/exercises/static/exercises/* /RoboticsAcademy/exercises command used in the dockerfile. A temproary solution which I earlier went with was to change the path of each exercise manually in the instructions.json but this might create merge conflicts. A better way of resolving this is to just use the same rync command after bind mount in the local repository. This will change the directory structure according to the paths in the instruction.json file. The same command can be used after the exercise has been created to structure according to the original repository.

Launch file for Gazebo

I started working on our launch file after studying other exercises. Except for the point where the Kinematic Widget was called, this was going to be largely similar to the launch file of the ROS Node template. So I decided to include this widget in the html page and semd the commands to gazebo using roslibjs. This way, I’ll have to rewrite all of the interface functions, including GUI and HAL. However, it appears that I do not need to perform all of this and that simply using rqt will suffice. I’m not sure about this method, and we’ll talk about it in the next meeting.

Set Up Automated Build on Docker Hub

Following discussions with mentors, we decided to use automated build for the industrial robots repo, so that the Docker hub can automatically generate images from source code in the pick & place branch and push the finalized image to the Docker repo. Others will be able to readily access the images with the most recent modifications in the exercise.

However, there isn’t any official documentation on multi-stage builds on Docker Hub. I tried a few different approaches, such as using ./build.sh or building both images separately, but none of them worked. So we still have to figure out a way to get this working.