CS684: Embedded System Course

Rulebook: [1] Theme Description


  • Figure 1 shows the arena design for this theme.

  • The arena is an abstraction of a disaster-affected area made up of a grid with the START position marked.

  • The grid is made up of 16 squares called Plots.


    Figure 1: Arena design

1. Arena Components

  • Each Plot has the following terms associated with it:
    • Four Mid-Point Markers on every path around the Plot. Figure 2a highlights the Mid-Point markers for a Plot.
    • The Clearing Zone, which is shown by the dotted square of 26cm x 26cm, highlighted in the green box in Figure 2b.
    • A 6cm x 6cm Inner Square that is highlighted in Figure 2c.
    • Four Nodes present at the corners of every Plot. This is shown in Figure 2d.

Figure 2: Terms associated with Arena

  • Rectangular chart paper patches are used to represent injured survirors and debris.
  • Three colored patches:
    • Red - represent Survivors with Severe Injuries, those require urgent assistance
    • Green - represent Survivors with Minor Injuries, those require not so urgent assistance
    • White - represent pieces of Debris strewn on the roads which cannot be moved, thus causing a roadblock
Figure 3: Injured Survivors and Debris on Arena

2. Theme Run Sequence

  • The robot will start from the START position of the arena.

  • It must traverse around the arena avoiding debris and check for the presence of a Survivors in each plot.

  • If Survivor is present in the plot, robot detects the type of emergency (Minor or Severe) using color.

    • Communicates the presence and type of Survivor to Desktop/Laptop.

  • During scanning, robot will get requests from the server on regular interval of 45 seconds.

    • Robot satisfies the requirement by traversing to the appropriate plot and ringing a buzzer for 1 second. Note: This indication can be done only from one of the Mid-Point Markers associated with that Plot.

  • Once robot scans entire grid, it should stop at medical camp to mark an end of the run.


3. Communication Sequence

  • Robot (Firebird V) will communicate with ESP 32 module over UART using serial communication.
  • ESP32 will use Bluetooth Low Energy (BLE) to communicate with the internet-connected laptop. Note that ESP32 won't be connected to the Wifi and hence the internet.
  • Laptop will communicate with the Thingsboard server.

4. Theme Requirements

Input Operations

  • Thingsboard server will send RPC requests to the laptop on a regular interval of 45 seconds. We will provide you with a script to mock this behaviour in development.
  • Laptop receives the RPC requests using MQTT Protocol in JSON format.
  • The requests may contain single or multiple requests (actions to perform). Robot can decide to satisfy the requests or ignore them.
  • There can be different types of requests as given below:
    • Fetch RED Survivor in 10s: Robot has to travesrse to the nearest RED Survivor plot and ring the buzzer within 10 second to satisfy the requirement.
    • Identify Survivor at plot 4 in 20s: Robot has to traverse to plot 4, identify the Survior and ring the Buzzer within 20 seconds.
    • No Request: No action needs to be performed

Output Operations

  • Once a request is performed by the robot, the response should be sent by the robot to the laptop over BLE and from laptop to the Thingsboard server. (The exact request and response formats are present under resource section (MockingRPC) [Updated April 6]).
  • The data should be sent as telemetry and the protocol to use while sending the data back to Thingsboard server will be CoAP. [Updated April 6]
  • Teams should prepare an interface (desktop app or web app) to show the requests received, indicate operations being performed on the arena and result of the operations. This is an open ended task so use your creativity.