diff --git a/docs/media/IPG_carmaker/IPG_Carmaker.jpg b/docs/media/IPG_carmaker/IPG_Carmaker.jpg new file mode 100644 index 0000000..1a3cc6f Binary files /dev/null and b/docs/media/IPG_carmaker/IPG_Carmaker.jpg differ diff --git a/docs/media/IPG_carmaker/PEAK_to_PEAK.jpg b/docs/media/IPG_carmaker/PEAK_to_PEAK.jpg new file mode 100644 index 0000000..373e017 Binary files /dev/null and b/docs/media/IPG_carmaker/PEAK_to_PEAK.jpg differ diff --git a/docs/resources/ipg_carmaker.md b/docs/resources/ipg_carmaker.md index 27f5400..3b45f71 100644 --- a/docs/resources/ipg_carmaker.md +++ b/docs/resources/ipg_carmaker.md @@ -1 +1,37 @@ -Coming Soon.... \ No newline at end of file +## Requirements + +In order to use IPG Carmaker you need to obtain a licence: + +- If doing simulation with our main ROS2 stack: **IPG Carmaker for Linux** +- If using HiL: **IPG Carmaker for Windows** + +A limited number of these are provided to Formula Student teams free of charge. + +## Motivation: + +### Static presentations: + +Historically our simulation presentation has been one of our weaker static events. Fully integrating IPG carmaker would inevitably put us in the top 10 for simulation. +### Better than our current solution: + +As of writing this were currently still using EUFS sim, which does work, **but its not ideal**. We only test downstream with EUFS sim currently (i.e. state estimation, path planning, control) as **EUFS sim doesn't provide simulated camera or LIDAR data.** + +**IPG carmaker does!** + +Integrating IPG carmaker properly would mean **we can do full stack testing,** something we haven't done to date! + +### HiL testing + +The HiL (Hardware in Loop) simulator for FS-AI is still under development by Ian Murphy at the time of writing. It has been used at competition as part of static inspection for teams who are struggling to interface with the car (which included us for quite a while!). We got away without having to interact with HiL at all this year but it can still serve as a valuable tool in order to test how you interface with the ADS-DV car and whether or not you are sending the right signals to the car. + +As part of developing the PEAK-CAN interface for the car last year, a "PEAK-to-PEAK" wire was also constructed. It allows for the connection of two computers over CANbus. + +![PEAK-to-PEAK connector](../media/IPG_carmaker/PEAK_to_PEAK.jpg) + +## Overall structure for a FT-IPG simulator: + +**This diagram is incomplete.** There is strong likelihood you will need proxy nodes to handle some of the inputs/outputs to IPG carmaker e.g. PointCloud to PointCloud2 converter (since our current stack only accepts LIDAR data with the ROS2 msg type PointCloud2) + +![IPG simulator overview](../media/IPG_carmaker/IPG_Carmaker.jpg) + +People working in simulation will likely be focusing on the green and orange portions exclusively. \ No newline at end of file diff --git a/docs/tutorials/ASR.md b/docs/tutorials/ASR.md new file mode 100644 index 0000000..d514af7 --- /dev/null +++ b/docs/tutorials/ASR.md @@ -0,0 +1,67 @@ +# The ASR (Autonomous Systems Responsible) + +## Key Terms: + +| Term | Definition | +| --------------------- | --------------------------------------------------------------------------------------------------------- | +| **RES** | Remote Emergency Stop. The emergency stop device operated by the ASR. | +| **Dynamic Operation** | Use of the ADS-DV within an approved Dynamic Operating Area under the defined ASR and area-control rules. | + + +## Brief: + +According to the IMechE Documentation, the role of ASR is defined as follows: + +**"The responsible operator who supervises the ADS-DV and operates the RES."** + +I'm going to designate numbers for these rules, not because they are provided, but because they might make them easier to remember. + +#### Rule 1: + +There must always be a qualified Autonomous Systems Responsible person (ASR) present to operate the ADS-DV with the Remote Emergency Stop (RES). + +*"Bottom line, you can't go using the ADS-DV car without the ASR present, and with the RES properly attached"* + +#### Rule 2: + +The ASR must keep the RES strapped securely around their waist and on their person at all times while the ADS-DV is active. It must not be held in one hand, put down, or moved out of immediate reach. + +*"Keep the thing attached and held on you in a reasonable fashion. If you can't immediately press the E-Stop button in less than half a second, your probably wearing it wrong"* + +### If there is anyting you get from this document, remember this: + +#### Rule 3: + +### **"The ASR must only be responsible for mission selection and the RES. They must not perform any other duties while the ADS-DV is active."** + +Your primary role is isolated to these 2 things, the mission selection (also setting the mission) and the RES. Everything else about the role is about promoting and ensuring the safety of yourself and others. **You must not have any other interaction with the vehicle of any kind.** + +The whole point of this is to let the ASR have their full attention on the RES at any given moment in time during both Static and Dynamic Operation. + +#### Rule 4: + +During static and dynamic operation, you the vehicle and operation of the RES switch must have your absolute undivided attention + +*Your eyes should be plastered to the vehicle at all times during static and dynamic operation* + +## What to do if... + +### The light on the status light on the emergency stop button starts flashing: + +The RES battery is running low. Ask an IMechE official for support. (Rules also state how to change the battery) + +### The RES starts vibrating randomly: + +*"Your phones in your pocket mate" - ZF guy* + +### Anything about the Static or Dynamic operation of the ADS-DV during present or future operation is unsafe: + +EBS and stop interacting with the vehicle in a safe manner and assess the situation. + +#### *Case study* + +During the Sunday of FSUK 2026, people around me, the ASR were busy putting cones out in a rush in order to get a run in the newly designated practice area with the ADS-DV. The proposed run involved increasing the speed of the ADS-DV since the last run dramatically. + +As the ASR I noticed that the cones that were laying out the proposed track were a little bit close to the tyre barrier for my liking at one corner. The officials around the vehicle did not have any complaints, but as the ASR (and knowing the fact that we were increasing our speed on that run), I would have felt much more comfortable had the track been a metre or two further out from the tyre barrier. The ADS-DV vehicle in this case overshot the first turn due to the high speed it was carrying in the first corner, but had it have been carrying the same speed in the corner closer to the tyre barrier, it could have posed a potential hazard, even though I hit the emergency stop well before it reached that corner. **In this particular case, all operation should have been halted until the track layout met my standard.** As the ASR, you have to look out for yourself, and the others around you. The EBS switch can't be treated as though it will cause the car to come to an immediate stop. **You must account for a reasonable amount of runoff (4 metres minimum)**. + +It might seem annoying, but you have to have an element of cop on when it comes to these things. **Your the person who should be enforcing safe operation of the vehicle.** diff --git a/docs/tutorials/onboarding_videos.md b/docs/tutorials/onboarding_videos.md new file mode 100644 index 0000000..6fe0096 --- /dev/null +++ b/docs/tutorials/onboarding_videos.md @@ -0,0 +1,14 @@ +# Onboarding videos + +This page includes some basic videos showcasing where to find the certain POIs (Points Of Interest) regarding Formula Trinity Autonomous + +### Finding the FT-Autonomous Locker and the "Rigby-Room": + +
+ +
\ No newline at end of file diff --git a/docs/tutorials/python_to_cpp.md b/docs/tutorials/python_to_cpp.md index 6575acf..db51b1b 100644 --- a/docs/tutorials/python_to_cpp.md +++ b/docs/tutorials/python_to_cpp.md @@ -1,12 +1,12 @@ ### Note: Its important to note that this is only a guide to migrate from Python to C++, not necessarily a mandatory read. -Many people prefer to work with Python for its dynamic types, but besides user readability C++ is the most optimal language for robotics as C++ is much closer to assembly language, both in terms of structure and performance. +Many people prefer to work with Python for its dynamic types, but besides user readability, C++ is the most optimal language for robotics as C++ is much closer to assembly language, both in terms of structure and performance. ## Reasons for wanting to migrate: - C++ code runs miles faster than Python -- No dynamic types ( you know excatly what every variable should be storing ) +- No dynamic types ( you know exactly what every variable should be storing ) - A very good way to understand how your code is actually working, and whether or not there are any mistakes in your current code. - Avoiding bottle necks in performance for small but necessary ROS2 nodes and packages diff --git a/mkdocs.yml b/mkdocs.yml index 3bcca14..5f391b7 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -151,6 +151,7 @@ nav: # This is the structure of the sidebar - Tutorials: - Getting Started Guide: tutorials/Getting_started.md + - Onboarding Videos: tutorials/onboarding_videos.md - Cutting Bags Down to Size: tutorials/cutting_bags.md - Competition Launch Scripts; Configuration, Setup and Running them: tutorials/comp_launch_scripts.md - Reducing Boot Time: tutorials/reducing_boot_time.md @@ -162,6 +163,7 @@ nav: # This is the structure of the sidebar - LiDAR Setup: tutorials/lidar_setup.md - YOLO Training: tutorials/yolo_training.md - Webpage Setup: tutorials/webpage_setup.md + - The role of the ASR: tutorials/ASR.md - Equipment: - ADS-DV Vehicle: equipment/ads_dv.md