fixed all relevant (for now) rel links

docs/com2009/assignment1/part1/subscriber.md

@@ -29,7 +29,7 @@ Copy **all** the code below into your `subscriber.py` file and (again) *make sur
 6. Finally, the code is executed by again performing a `__name__` check, creating an instance of the `Subscriber()` class and calling the `main()` method from that class.
 
 !!! warning "Fill in the Blank!"
-    Replace the `{BLANK}` in the code above with the name of the topic that our [`publisher.py` node](../publisher) was set up to publish to!
+    Replace the `{BLANK}` in the code above with the name of the topic that our [`publisher.py` node](./publisher.md) was set up to publish to!
 
 ## Don't Forget the Shebang! {#dfts}
 

docs/com2009/assignment1/part2/move_square.md

@@ -26,7 +26,7 @@ Moving in a square can be achieved by switching between two different movement s
 
 1. Import the `Twist` message for publishing velocity commands to `/cmd_vel`.
 2. Import the `Odometry` message, for use when subscribing to the `/odom` topic.
-3. Import the `euler_from_quaternion` function to convert orientation from quaternions (as provided in the `Odometry` message) to Euler angles (about [the principal axes](../../part2/#principal-axes)).
+3. Import the `euler_from_quaternion` function to convert orientation from quaternions (as provided in the `Odometry` message) to Euler angles (about [the principal axes](../part2.md#principal-axes)).
 4. Finally, import some useful mathematical operations (and `pi`), which you may find useful:
 
     | Mathematical Operation | Python Implementation |
@@ -53,7 +53,7 @@ Moving in a square can be achieved by switching between two different movement s
 
 6. Here we obtain the robot's **current** position coordinates.
 
-7. And here we obtain the robot's current orientation (in quaternions) and convert it to Euler angles (in radians) about [the principal axes](../../part2/#principal-axes), where:
+7. And here we obtain the robot's current orientation (in quaternions) and convert it to Euler angles (in radians) about [the principal axes](../part2.md#principal-axes), where:
     * "roll" = <code>&theta;<sub>x</sub></code>
     * "pitch" = <code>&theta;<sub>y</sub></code>
     * "yaw" = <code>&theta;<sub>z</sub></code>

docs/com2009/assignment1/part2/twist-tips.md

@@ -4,7 +4,7 @@ title: Working with Twist Messages in Python
 
 # Working with Twist Messages in Python
 
-From [the Part 1 publisher exercise](../../part1/#ex5), we know how to publish a `String` type message to a topic in Python, but how do we apply the same principles to a `Twist` message (on the `/cmd_vel` topic)? Let's have a look at this... 
+From [the Part 1 publisher exercise](../part1.md#ex5), we know how to publish a `String` type message to a topic in Python, but how do we apply the same principles to a `Twist` message (on the `/cmd_vel` topic)? Let's have a look at this... 
 
 First, you need to import the `rospy` library, as well as the `Twist` message type from the `geometry_msgs` library:
 

docs/com2009/assignment1/part4/move_client.md

@@ -48,7 +48,7 @@ Copy **all** the code below into your `move_client.py` file and review the annot
 10. To finish off, we print the response to the terminal to give the user some feedback. Job done!
 
 !!! warning "Fill in the Blank!"
-    Consider the `import` statement for [the service *Server* that we created earlier](../move_server)... Which part of the `SetBool` Service message was imported here? Now consider that you need to build a client to call this service... which part of the `SetBool` Service message is needed in order to *call* a service? 
+    Consider the `import` statement for [the service *Server* that we created earlier](./move_server.md)... Which part of the `SetBool` Service message was imported here? Now consider that you need to build a client to call this service... which part of the `SetBool` Service message is needed in order to *call* a service? 
 
     **Note:** the same `{BLANK}` appears in two places in the code above - *the answer is the same in both places!*
 

docs/com2009/assignment1/part4/move_server.md

@@ -83,7 +83,7 @@ Copy **all** the code below into your `move_server.py` file and review the annot
 17. The `rospy.spin()` function keeps our node running indefinitely (so that the callback function can continue to execute, whenever the service is called). 
 
 !!! warning "Fill in the Blank!"
-    Which message package does [the `Twist` message](../../part2/#twist-py) belong to?
+    Which message package does [the `Twist` message](../part2/twist-tips.md) belong to?
 
 <p align="center">
   <a href="../../part4#ex1_ret">&#8592; Back to Part 4 - Exercise 1</a>

docs/com2009/assignment1/part5/action_client.md

@@ -6,7 +6,7 @@ title: Part 5 Camera Sweep Action Client
 
 Copy **all** the code below into your `move_client.py` file.  Then, review the code annotations to understand how it all works.
 
-(Oh, and [DFTS](../../part1/subscriber/#dfts)!)
+(Oh, and [DFTS](../part1/subscriber.md#dfts)!)
 
 ```py title="action_client.py"
 --8<-- "snippets/action_client.py"
@@ -55,7 +55,7 @@ Copy **all** the code below into your `move_client.py` file.  Then, review the c
 !!! warning "Fill in the Blank!"
     Which attribute of the `feedback_data` object tells us how many images have been captured over the course of the *Camera Sweep* Action? There are a number of ways we can work this out:
 
-    1. You could use the same approach as we used [earlier](../#camera_sweep_msg_params). 
+    1. You could use [the same approach as we used earlier](../part5.md#camera_sweep_msg_params). 
     1. You could run `rosmsg info tuos_msgs/CameraSweepFeedback` in a terminal.
     1. You could use the autocomplete/variable suggestions provided in VS Code!
 

docs/com2009/assignment1/part5/preemptive_action_client.md

@@ -45,7 +45,7 @@ Copy **all** the code below into your `preemptive_action_client.py` file and the
 11. **Fill in the Blank!**
 
 !!! warning "Fill in the Blank!"
-    We have contained all our code inside a nice Python Class now, but how do we actually instantiate it and invoke the Action Call? (We've been doing this from [the very beginning](../../part1/publisher), and the process is very much the same here!)
+    We have contained all our code inside a nice Python Class now, but how do we actually instantiate it and invoke the Action Call? (We've been doing this from [the very beginning](../part1/publisher.md), and the process is very much the same here!)
 
 <p align="center">
   <a href="../../part5#ex3_ret">&#8592; Back to Part 5 - Exercise 3</a>

docs/com2009/assignment1/part6/object_detection.md

@@ -6,15 +6,15 @@ title: "Part 6 Object Detection Node"
 
 Copy **all** the code below into your `object_detection.py` file, and **make sure you read the annotations**!
 
-.. oh, and I'm sure I don't need to say it by now, but... [DFTS](../../part1/subscriber/#dfts)!
+.. oh, and I'm sure I don't need to say it by now, but... [DFTS](../part1/subscriber.md#dfts)!
 
 ```py title="object_detection.py"
 --8<-- "snippets/object_detection.py"
 ```
 
 1. Of course, we always need to import `rospy` so that Python can work with ROS. What we're also importing here is the Python `Path` class from [the `pathlib` module](https://docs.python.org/3/library/pathlib.html), which will be used to do a few file operations.
 
-2. Then, we're importing the OpenCV library for Python (remember the Python API [that we talked about earlier](../part6/#opencv)), which is called `cv2`, and *also* that ROS-to-OpenCV bridge interface that we talked about earlier too: `cv_bridge`.
+2. Then, we're importing the OpenCV library for Python (remember the Python API [that we talked about earlier](../part6.md#opencv)), which is called `cv2`, and *also* that ROS-to-OpenCV bridge interface that we talked about earlier too: `cv_bridge`.
 
     From `cv_bridge` we're importing the `CvBridge` and `CvBridgeError` classes from the `cv_bridge` library specifically.
 

docs/com2009/assignment1/part6/object_detection_complete.md

@@ -4,7 +4,7 @@ title: "Part 6 Object Detection Node (Complete)"
 
 # Part 6 Object Detection Node (Complete)
 
-Here's a full example of the `object_detection.py` node that you should have developed during [Part 6 Exercise 2](../#ex2).  Also included here is an illustration of how to use the `cv2.circle()` method to create a marker on an image illustrating the centroid of the detected feature, as discussed [here](../part6/#image-moments).
+Here's a full example of the `object_detection.py` node that you should have developed during [Part 6 Exercise 2](../part6.md#ex2).  Also included here is an illustration of how to use the `cv2.circle()` method to create a marker on an image illustrating the centroid of the detected feature, as discussed [here](../part6.md#image-moments).
 
 ```py title="object_detection_complete.py"
 --8<-- "snippets/object_detection_complete.py"

docs/com2009/assignment2/README.md

@@ -16,10 +16,10 @@ There are **four tasks** in total that you must complete for this Assignment. Ea
 
 | Task | Details | Marks |
 | :---: | :---   | :---: |
-| 1 | [Velocity Control](../task1) | 20/100 |
-| 2 | [Avoiding Obstacles](../task2) | 20/100 |
-| 3 | [Navigation](../task3) | 25/100 |
-| 4 | [Search & Explore](../task4) | 35/100 | 
+| 1 | [Velocity Control](./task1.md) | 20/100 |
+| 2 | [Avoiding Obstacles](./task2,md) | 20/100 |
+| 3 | [Navigation](./task3.md) | 25/100 |
+| 4 | [Search & Explore](./task4.md) | 35/100 | 
 
 </center>
 

docs/others/amr31001/README.md

@@ -6,5 +6,5 @@ title: AMR31001 Industry 4.0
 
 As part of this module you will take part in two lab sessions in the Diamond, where you will learn about how ROS can be used to program and control robots. You'll do some Python programming and look at how sensor data can be used to control a robot's actions. 
 
-* [Lab 1: Mobile Robotics](./lab1)  
-* [Lab 2: Feedback Control](./lab2)
+* [Lab 1: Mobile Robotics](./lab1.md)  
+* [Lab 2: Feedback Control](./lab2.md)

docs/others/amr31001/lab1.md

@@ -13,7 +13,7 @@ ROS is an open-source, industry-standard robot programming framework, used in a
 
 ROS allows us to programme robots using a range of different programming languages (including C++, Java, MATLAB etc.), but we'll be using Python for these labs. In addition to this, ROS runs on top of a Linux operating system called *'Ubuntu'*, and so we'll also learn a bit about how to use this too.
 
-We'll be working with robots called *'TurtleBot3 Waffles'*, which you can [find out a bit more about here](../../../about/robots). 
+We'll be working with robots called *'TurtleBot3 Waffles'*, which you can [find out a bit more about here](../../about/robots.md). 
 
 !!! warning "Pre-Lab Work"
     You **must** have completed the Pre-Lab Test before you can make a start on this lab. This is available on the AMR31001 Blackboard Course Page.

docs/others/amr31001/lab2.md

@@ -214,7 +214,7 @@ In the previous lab we used some ROS commands to identify and interrogate active
     ```
 
     !!! info "Post-lab Quiz"
-        What does all this mean? We discussed this [last time (in relation to the `/cmd_vel` topic)](../lab1/#rostopic_info_explained), and you may want to have a look back at this to refresh your memory! 
+        What does all this mean? We discussed this [last time (in relation to the `/cmd_vel` topic)](./lab1.md#rostopic_info_explained), and you may want to have a look back at this to refresh your memory! 
     
     One of the key things that this does tell us is that the `/odom` topic transmits data using a `nav_msgs/Odometry` message. All topics use standard message types to pass information around the ROS network. This is so that any node on the ROS network knows how to deal with the data, if it needs to. `nav_msgs/Odometry` is one of these standard message types. 
     
@@ -295,7 +295,7 @@ You should have noticed that (as the robot moved around) the `x` and `y` terms c
 
 #### :material-pen: Exercise 2: Odometry-based Navigation {#ex2}
 
-Now that we know about the odometry system and what it tells us, let's see how this could be used as a feedback signal to inform robot navigation. You may recall that [last time](../lab1/#ex6) you created a ROS Node to make your robot to follow a square motion path on the floor. This was time-based though: given the speed of motion (tuning or moving forwards) it was possible to determine the time it would take for the robot to move by a required distance. Having determined this, we then added timers to our node, to control the switch between moving forwards and turning on the spot, in order to generate the square motion path. 
+Now that we know about the odometry system and what it tells us, let's see how this could be used as a feedback signal to inform robot navigation. You may recall that [last time](./lab1.md#ex6) you created a ROS Node to make your robot to follow a square motion path on the floor. This was time-based though: given the speed of motion (tuning or moving forwards) it was possible to determine the time it would take for the robot to move by a required distance. Having determined this, we then added timers to our node, to control the switch between moving forwards and turning on the spot, in order to generate the square motion path. 
 
 In theory though, we can do all this with odometry instead, so let's have a go at that now...