Merge pull request #228 from FS-Driverless/remove-fsonline-docs

Removed FSOnline-specific documentation

docs/README.md

@@ -9,8 +9,10 @@ In any case, here are a few suggestions for newcomers.
 * **Get familiar with the architecture.** The [system overview](system-overview.md) introduces you to the ideas and concepts of the system.
 * **Launch the simulator and ros bridge.** Follow the [getting started guide](getting-started.md).
 
-## Participating in FS-Online 2020?
-Participants of the FS-Online 2020 virtual event should start by reading the [system overview](system-overview.md) and [integration handbook](integration-handbook.md).
-Next, follow the steps in the [getting started guide](getting-started.md) to get you up and running.
+## Looking for details on FSOnline 2020?
+
+Please visit version v1.4.1 for a the code used during.
+That version also includes the integration guide describing the rules regarding sensors of FSOnline 2020.
+
 
 ![Front picture](images/fsds_pretty.png)

docs/competition-signals.md

@@ -0,0 +1,73 @@
+## Competition system flow and Signals
+
+### Staging
+At some point, your AS will be staged: The vehicle is placed prior to the starting line, the `fsds_ros_bridge` node will connect to the ROS system.
+From this point onwards, the AS will receive sensor data and can control the vehicle by publishing vehicle setpoints.
+However, it shouldn't start driving the vehicle just yet!
+
+### Starting 
+Just like with a physical FS event, the vehicle must only start driving after a GO signal is received.
+The GO signal indicates that the AS must start the mission and that the vehicle should start driving.
+This signal is also known as the 'green flag' signal or 'starting' signal. Within this repo, we will reference it as 'GO'.
+Within the GO signal, the mission and track are added. 
+Currently, `autocross` and `trackdrive` are the supported missions.
+
+In autocross, the vehicle has to complete a single lap on an unknown track.
+On the trackdrive, the vehicle has to finish 10 laps on a track it has previously seen.
+During the competition, on each track, every AS will do an autocross mission before a trackdrive mission.
+It can occur that multiple autocross runs on different tracks take place before going to trackdrive.
+It can also happen that multiple autocross runs take place on the same track.
+For example, the AS might be requested to do:
+
+1. autocross on track A
+2. autocross on track B
+3. trackdrive on track A
+4. autocross on track C
+5. autocross on track C (re-run)
+6. trackdrive on track C
+
+The AS must implement the following behaviour:
+
+* When the AS is requested to do autocross on a track that it has seen before, it must delete any and all data it gathered during all previous runs on this track.
+* When the AS is requested to do trackdrive on a track where it has done a trackdrive previously, it must delete any and all data it gathered during all previous trackdrive runs on this track. However, the data gathered during the last autocross on this track shouldn't be deleted.
+
+An exception to this rule is data recorded with the exclusive intent to analyze the AS's behaviour after the event.
+This includes all files that the AS only writes to but does not read from.
+
+To make the AS aware of which track it is driving, the GO signal includes a unique identifier of the upcoming track.
+
+After the initial GO signal, the signal is continuously re-sent at 1 Hz to ensure it arrives at the team's AS.
+The timestamp of all consecutive GO signals is equal to the first one.
+
+### Finishing
+There are two ways to conclude a run: finishing or stopping.
+
+When the autonomous system feels it concluded it's run, it should send a FINISHED signal.
+The FINISHED signal tells the simulator that the AS no longer wants to control the vehicle.
+As such, the simulator will stop the `fsds_ros_bridge` and the AS will no longer receive sensor data or be able to control the vehicle.
+
+When the official decides that the run is over it will stop the simulation.
+See the rulebook for a description of when the official does so.
+When the simulation is stopped the `fsds_ros_bridge` is stopped immediately and the AS will no longer receive sensor data or be able to control the vehicle.
+The AS will not receive a signal that this happened.
+To detect a stop, the AS should keep an eye on the GO signal.
+
+The general rule is: If the AS did not receive a GO signal for 4 seconds the AS can assume the `fsds_ros_bridge` is stopped.
+When this state is detected, the AS can reset itself and prepare for the next mission.
+
+
+## Ros messages
+
+The AS will receive the GO signal on the following topic:
+
+- `/fsds/signal/go`
+
+And it AS can publish the FINISHED on this topic:
+
+- `/fsds/signal/finished`
+
+The AS must publish vehicle control commands on this topic:
+
+- `/fsds/control_command`
+
+Read more about the techincal detalis of these topics in the [ros-bridge documentation](ros-bridge.md)

docs/getting-started.md

@@ -176,4 +176,22 @@ roslaunch fsds_ros_bridge fsds_ros_bridge.launch
 The ros bridge will read the settings from `~/Formula-Student-Driverless-Simulator/settings.json`.
 Make sure this is the same configuration file as the simulator uses.
 
-[Read all about configuring the ros bridge here.](ros-bridge.md)
+[Read all about configuring the ros bridge here.](ros-bridge.md)
+
+## Connecting your autonomous system
+
+The ROS bridge of this simulator had to make use of several custom msgs (for control commands, the groundtruth track, etc). 
+These messages are defined in a ROS package called `fs_msgs` which is located in a separate, light [repository](https://github.com/FS-Online/fs_msgs). 
+To implement publishers and subscibers for these messages types in your autonomous pipeline, you will have to add the `fs_msgs` repository as a submodule in your codebase (inside de `src` directory of an existing **catkin workspace** as done in this repository) or clone it and build it somewhere else in your system.
+
+Now, all that is left to do is subscribe to the following topics to receive sensordata
+
+- `/fsds/gps`
+- `/fsds/imu`
+- `/fsds/camera/CAMERA_NAME`
+- `/fsds/camera/CAMERA_NAME/camera_info`
+- `/fsds/lidar/LIDAR_NAME`
+- `/fsds/testing_only/odom`
+- `/fsds/testing_only/track`
+
+and publish to the following topic `/fsds/control_command` to publish the vehicle control setpoints.

docs/gps.md

@@ -2,7 +2,10 @@
 
 The GPS model in AirSim has been configured to mimic an average GPS receiver used during formula student competitions.
 
-The GPS operates at 10 Hz, this value can be altered with update_frequency parameter. 
+The GPS operates at 10 Hz, this value can be altered with update_frequency parameter.
+
+The GPS is located in the [vehicle pawn center](vehicle_model.md). 
+The GPS captures the position of the vehicle in the geodetic reference system, namely longitude [deg], latitude [deg], altitude [m].
 
 At this moment there is no artificial latency added.
 Still there will be some delay between the creation of the gps points and arrival at the autonomous system because of network latency.  

docs/import-car-3d-model.md

@@ -70,14 +70,6 @@ Take a look at `Suv_Pa` for an example:
 
 ![](images/ue-suv_pa.png)
 
-**If you are planning to use this car in an online competition (FSOnline)** you must use create the bounding boxes exactly the following specification:
-
-* Width: 100cm
-* Length: 180cm
-* Height: 50cm
-
-In competition all cars will be equal in behaviour. 
-So all bounding boxes must be equal.
 Below picture shows how bounding boxes can be bigger or smaller than the mesh.
 
 ![](images/ue-equality.png)
@@ -119,8 +111,12 @@ Next, in the details pane:
 * From Drag Coefficient onwards all settings should be exactly equal to the settings in `SuvCarPawn`. Have fun copy-pasting.
 
 # 7. Selecting a car
-Update your settings.json `PawnPaths -> DefaultCar -> PawnBP` to point at the newly created pawn. 
-It should (tm) work.
+Update your settings.json `PawnPaths -> DefaultCar -> PawnBP` field in the `settings.json` to point at the newly created pawn. 
+Currently the following values are supported:
+
+* `Class'/AirSim/VehicleAdv/Cars/TechnionCar/TechnionCarPawn.TechnionCarPawn_C'`
+* `Class'/AirSim/VehicleAdv/Cars/SuvCar/SuvCarPawn.SuvCarPawn_C'` 
+
 
 # 8. Sharing your vehicle with the world!
 

docs/imu.md

@@ -1,5 +1,8 @@
 ## IMU Sensor
-The IMU sensor in FSDS is using AirSim's built in IMU sensor simulation, that has been modelled and parametrized according to MPU 6000 IMU from [InvenSense](https://www.invensense.com/wp-content/uploads/2015/02/MPU-6000-Datasheet1.pdf)
+The IMU captures the acceleration, orientation and angular rate of the vehicle.
+The IMU sensor in FSDS is using AirSim's built in IMU sensor simulation, that has been modelled and parametrized according to MPU 6000 IMU from [InvenSense](https://www.invensense.com/wp-content/uploads/2015/02/MPU-6000-Datasheet1.pdf).
+
+
 
 
 The maximum achievable internal IMU frequency is 1000 Hz, ouputing information of the vehicle's 3-axis angular velocity, 3-axis linear acceleration, as well as its orientation in quaternions. 
@@ -10,6 +13,8 @@ The angular velocity, linear acceleration outputs as well as their biases have a
 
 All of the IMU measurements are timestamped.
 
+The GPS is located in the [vehicle pawn center](vehicle_model.md). 
+
 See ImuSimple.hpp (/AirSim/AirLib/include/sensors/imu/ImuSimple.hpp) and [ImuSimpleParams.hpp] /AirSim/AirLib/include/sensors/imu/ImuSimpleParams.hpp for the implementation of the IMU model.