Skip to content

Commit

Permalink
update remote control app section
Browse files Browse the repository at this point in the history
  • Loading branch information
hokashun committed Nov 15, 2023
1 parent e83d296 commit b6f83d0
Show file tree
Hide file tree
Showing 15 changed files with 588 additions and 117 deletions.
6 changes: 4 additions & 2 deletions docs/_sidebar.md
Original file line number Diff line number Diff line change
Expand Up @@ -17,8 +17,6 @@
- [RoCS Model](rocs_model.md)
- [RoCS Enable WIFI](rocsenablewifi.md)
- [Connect to Cluster](clustermode.md)
-
-
- [Client SDK](sdkoverview.md)

- [Understanding GR-1 Programming](python\understanding_gr-1_programming.md)
Expand All @@ -28,7 +26,11 @@
- [Javascript/Typescript SDK](rocsclientsdk-ts&js.md)
- Remote Control App

- [Startup](startUp.md)
- [Login](login.md)
- [Remote Control App](rocsappoperation.md)
-
- [Remote Control Interface](remoteControlInterface.md)
- Autonomy

- [Autonomy](autonomy.md)
Expand Down
Binary file added docs/image/login/1700032171029.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added docs/image/login/1700032179929.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added docs/image/remoteControlApp/Startup.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added docs/image/remoteControlApp/login-connected.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added docs/image/startUp/1700028396397.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
66 changes: 66 additions & 0 deletions docs/login.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,66 @@
# Login Interface

The login interface is designed to provide users with a seamless login experience. It comprises various elements, including a header, an image of GR-1 robot, a `Start Exploring` button, and a prompt box appearing based on certain user interactions. The functionality is implemented using the Vue.js framework with Vuex for state management.

### **Disconnected**

![1700032171029](image/login/1700032171029.png ":size=80%")

### **Connected**

![1700032179929](image/login/1700032179929.png ":size=80%")

### Header

The header component serves as the top section of the login interface. It includes a logo and login-related functionality.

* **Events:**

* `@connect`: Triggered when the `Connect`button is clicked. It invokes the `startExplore()` method.
* `@shutDown`: Triggered when the `Shutdown`button is clicked. It opens the prompt box via the `promptBoxOpen()` method.

### `Start Exploring` Button

The `Start Exploring` button is a call-to-action element prompting the user to begin the exploration process.

* **Event:**
* `@click`: Invokes the `startExplore()` method when clicked.
* **Method:**
* `startExplore()`: Checks server status via the `control_svr_status` method on the `robot` object. If connected and server status is positive, navigates to the `loading` route; otherwise, navigates to the `robotStartup` route.

### Prompt Box

The prompt box is a modal component that appears based on certain user interactions.

* **Events:**
* `@cancel`: Invokes the `promptBoxOpen()` method when the cancel button is clicked.
* `@confirm`: Invokes the `shutDown()` method when the confirm button is clicked.
* **Method:**
* `promptBoxOpen()`: Toggles the visibility of the prompt box.
* `shutDown()`: Initiates server shutdown by calling the `control_svr_close` method on the `robot` object. Logs the response or error and closes the prompt box.

## Vuex State

The Vuex store manages the application state, including the `robot` states and the `connected` state, which is determined through the `heartbeatCheck` method in the `Heartbeat` mixin.

* `connected`: Boolean, representing the connection status to the server. It is determined by the periodic execution of the `heartbeatCheck` method.
* `robot`: An instance of the `Human` class from the `rocs-client` module, representing the GR-1 robot.

!> Please note that the provided state check mechanism is presented for reference purposes. You are encouraged to architect your own methodologies in alignment with project's specific prerequisites and considerations.

### Heartbeat Mixin (`Heartbeat`)

The Heartbeat mixin is responsible for periodic heartbeats to check the connection status with the server.

* **Data:**
* `intervalId`: Holds the identifier for the heartbeat interval.
* **Lifecycle Hooks:**
* `created`: Initiates the heartbeat mechanism when the component is created.
* `destroyed`: Stops the heartbeat mechanism when the component is destroyed.
* **Methods:**
* `startHeartbeat()`: Initiates the heartbeat mechanism by calling `heartbeatCheck` at regular intervals.
* `stopHeartbeat()`: Stops the heartbeat mechanism by clearing the interval.
* **Method:**
* `heartbeatCheck()`: Uses the `get_robot_type` method from `rocs-client` to check the robot type. Updates the Vuex store's `connected` state based on the success or failure of the request.

The `setConnected` mutation in the Vuex store is triggered based on the results of the `heartbeatCheck` method, reflecting the real-time connection status.
44 changes: 21 additions & 23 deletions docs/networking.md
Original file line number Diff line number Diff line change
@@ -1,12 +1,12 @@
# Network Communication

To establish communication with the GR-1 robot, all applications utilize a network connection through WebSocket and HTTP protocols. A solid comprehension of these protocols is essential for effective troubleshooting and ensuring the robust performance of applications.
To initiate communication with the GR-1 robot, all applications leverage a network connection employing WebSocket and HTTP protocols. A comprehensive understanding of these protocols is imperative for effective troubleshooting and ensuring the robust functionality of applications.

RoCS APIs manage two types of instructions, namely continuous and instantaneous, exchanged with the GR-1 robot. Continuous instructions employ WebSocket for real-time communication, ensuring immediate feedback and reliability. Conversely, instantaneous instructions use HTTP for simpler communication when real-time feedback is not imperative. The SDK offers tools for monitoring actively pushed messages and handling different types of instructions accordingly.
RoCS APIs manage two categories of instructions: continuous and instantaneous, exchanged with the GR-1 robot. Continuous instructions utilize WebSocket for real-time communication, ensuring immediate feedback and reliability. Conversely, instantaneous instructions use HTTP for simpler communication when real-time feedback is not essential. The SDK provides tools for actively monitoring pushed messages and handling different instruction types accordingly.

## WebSocket Connection

GR-1 primarily relies on WebSocket communication as the key protocol for interaction. WebSocket is a real-time, bidirectional protocol that facilitates near real-time data exchange between your applications and the robot. This approach is particularly suitable for scenarios demanding low latency and high responsiveness, such as those involving continuous instructions.
The primary mode of communication for GR-1 is WebSocket, a real-time, bidirectional protocol facilitating near real-time data exchange between applications and the robot. This approach is particularly suitable for scenarios requiring low latency and high responsiveness, such as those involving continuous instructions.

**Continuous Instructions:**

Expand All @@ -17,11 +17,11 @@ GR-1 primarily relies on WebSocket communication as the key protocol for interac

### WebSocket Libraries

To communicate with GR-1 robot product via WebSocket, you'll need to use WebSocket libraries in your programming language of choice. These libraries facilitate the creation and management of WebSocket connections. Depending on your preferred programming language, choose a WebSocket library that is compatible with your application.
To communicate with the GR-1 robot via WebSocket, you need WebSocket libraries in your programming language of choice. These libraries facilitate the creation and management of WebSocket connections. Choose a WebSocket library compatible with your preferred programming language.

### Sample WebSocket Connection (Python)

Below is a simplified Python code snippet that demonstrates how to establish a WebSocket connection to your GR-1 robot product using the `websockets` library:
Below is a simplified Python code snippet demonstrating how to establish a WebSocket connection to your GR-1 robot using the `websockets` library:

```Python
import asyncio
Expand Down Expand Up @@ -51,7 +51,6 @@ In this example, replace `wss://your_gr1_ip_or_hostname:443/your_websocket_endpo
- HTTP communication is chosen for instantaneous instructions as it offers a more straightforward way to communicate when real-time feedback is not critical.
- Examples of instantaneous instructions include functions like `human.stand()` and `human.stop()`, where the focus is on the success or failure of execution and error reasons in case of failure.


### HTTP Libraries

Similar to WebSocket communication, establishing communication with the GR-1 robot via HTTP requires the use of HTTP libraries in your chosen programming language. These libraries simplify the handling of HTTP requests and responses, making it easier to interact with the GR-1 robot's Server APIs.
Expand Down Expand Up @@ -88,35 +87,34 @@ In this example, replace `http://your_gr1_ip_or_hostname:80/your_http_endpoint`

Choose an HTTP library compatible with your programming language to streamline your interactions with the GR-1 robot's Server API through the HTTP protocol.


## Network Choice

GR-1 offers a variety of networking options to support a diverse set of applications and environments. Options include:
GR-1 offers various networking options to support diverse applications and environments. Options include:

- **GR-1 as a connected peer**. Applications can be deployed on computers that physically connect to GR-1 via the rear RJ-45 port. This provides a reliable, high-rate communications link without infrastructure requirements, but limits where the application can be run.
- **GR-1 as a WiFi access point**. Applications with physical proximity to GR-1 can connect to the WiFi access point and communicate directly without any networking infrastructure.
- **GR-1 as a WiFi client**. Spot can join an existing WiFi network, and applications can also join the same WiFi network to talk to GR-1. This approach increases the possible range between application and GR-1, but attention needs to be paid to dead zones in the network, handoff times between access points, and other considerations.
- **GR-1 via custom communications links**. Custom communication links can act as a bridge between GR-1 and applications. These can be useful when the above cases are insufficient for network design.
* **GR-1 as a connected peer:** Deploy applications on computers physically connected to GR-1 via the rear RJ-45 port. This provides a reliable, high-rate communications link without infrastructure requirements but limits the application's deployment location.
* **GR-1 as a WiFi access point:** Applications in physical proximity to GR-1 can connect to the WiFi access point and communicate directly without any networking infrastructure.
* **GR-1 as a WiFi client:** GR-1 can join an existing WiFi network, allowing applications to communicate over the same WiFi network. This increases the possible range between application and GR-1 but requires attention to network dead zones and handoff times between access points.
* **GR-1 via custom communications links:** Custom communication links can act as a bridge between GR-1 and applications, useful when standard cases are insufficient for network design.

While the application-layer protocol for the GR-1 API works across any IP-based network connection, the examples above show that networking choice can have a significant impact on the performance and reliability of an application as well as deployment strategies.
While the application-layer protocol for the GR-1 API works across any IP-based network connection, the examples above highlight that networking choice significantly impacts application performance, reliability, and deployment strategies.

## Network Configuration

To establish a WebSocket connection with GR-1, you'll need to configure the network appropriately. Here are the key steps:
To establish a WebSocket connection with GR-1, configure the network appropriately. Key steps include:

1. **GR-1 Network Connection:** Ensure that your GR-1 robot is connected to the network. GR-1 can be connected via Ethernet or Wi-Fi, depending on your requirements.
2. **IP Address or Hostname:** Determine the IP address or hostname of your GR-1 robot. You will use this information to connect to the robot product via WebSocket.
3. **Port Configuration:** WebSocket communication typically occurs over port 80 (HTTP) or port 443 (HTTPS). Ensure that the required port is accessible for WebSocket communication.
4. **Security Considerations:** While WebSocket is a secure protocol, it's important to implement proper security measures. Ensure that your WebSocket connection is secured with encryption (WSS) if sensitive data is being transmitted. Additionally, consider implementing authentication and authorization mechanisms to control access to the GR-1 robot.
1. **GR-1 Network Connection:** Ensure GR-1 is connected to the network via Ethernet or Wi-Fi, depending on requirements.
2. **IP Address or Hostname:** Determine the IP address or hostname of your GR-1 robot for WebSocket connection.
3. **Port Configuration:** WebSocket communication typically occurs over port 80 (HTTP) or port 443 (HTTPS). Ensure the required port is accessible for WebSocket communication.
4. **Security Considerations:** Implement proper security measures, such as encryption (WSS) for sensitive data transmission. Consider authentication and authorization mechanisms to control access to the GR-1 robot.

## Error Handling

Robust applications need to handle errors when communicating with the GR-1 robot product over WebSocket. WebSocket libraries often provide mechanisms for error handling, allowing you to gracefully manage issues like connection failures or timeouts. Be sure to implement error-handling logic in your application to ensure reliability.
Robust applications communicating with the GR-1 robot over WebSocket must handle errors gracefully. WebSocket libraries often provide mechanisms for error handling, allowing for the graceful management of issues like connection failures or timeouts. Implement error-handling logic in your application to ensure reliability.

## Robot Discovery

To talk to GR-1, a client application needs to specify an IP address where a GR-1 is running. There are a number of possible options for doing this sort of robot discovery.
To communicate with GR-1, a client application must specify the IP address where a GR-1 is running. Possible options for robot discovery include:

- **Fixed IP address**. This approach can be used reliably when connecting directly to Spot as a WiFi access point, or over ethernet. No name lookup infrastructure is required.
- **DNS name**. A DNS server (or HOSTS file) can be configured to statically point to a fixed IP address that GR-1 listens on, and the application specifies a DNS name to reach.
- **Custom Discovery mechanism**. Applications can develop custom approaches to map a specific GR-1 to an IP address, such as using a cloud-based discovery endpoint.
- **Fixed IP address**: Reliable when connecting directly to GR-1 as a WiFi access point or over Ethernet. No name lookup infrastructure is required.
- **DNS name:** Configure a DNS server or HOSTS file to statically point to a fixed IP address that GR-1 listens on, specifying a DNS name to reach.
- **Custom Discovery mechanism:** Develop custom approaches, such as using a cloud-based discovery endpoint, to map a specific GR-1 to an IP address.
26 changes: 12 additions & 14 deletions docs/operationinstruction.md
Original file line number Diff line number Diff line change
@@ -1,4 +1,3 @@

# Operation Instruction

## Before power-on
Expand All @@ -11,21 +10,21 @@ Do the following steps before powering on the robot:
2. Ensure that the batteries of robot and the support stand are fully chareged.
3. Ensure that the robot components moves smoothly.

![1698657344119](image/README/1698657344119.png ':size=80%')
![1698657344119](image/README/1698657344119.png ":size=80%")

### Inspecting environment

1. Ensure that there is a 4-meter clearance around the robot.
2. Ensure that the ground is level and dry.

![1698656074242](image/README/1698656074242.png ':size=80%')
![1698656074242](image/README/1698656074242.png ":size=80%")

### Connecting robot to monitor

1. Power on the router.
2. Connect monitor to Type-C interface through the extension dock.

![1698657743472](image/README/1698657743472.png ':size=80%')
![1698657743472](image/README/1698657743472.png ":size=80%")

### Preparing arms for calibration

Expand All @@ -34,15 +33,15 @@ Do the following steps before powering on the robot:
3. Ensure a 10 cm interval between palms and hips.
4. Ensure that the robot stands upright.

![1698658681237](image/README/1698658681237.png ':size=80%')
![1698658681237](image/README/1698658681237.png ":size=80%")

## Powering on Robot

1. Press actuator power-on button.
2. Press robot host power-on button.
3. Release e-stop switch.

![1698659185945](image/README/1698659185945.png ':size=80%')
![1698659185945](image/README/1698659185945.png ":size=80%")
4. Initialize robot arms and legs through desktop terminal.

Enter the following command to calibrate arms.
Expand All @@ -63,15 +62,14 @@ Do the following steps before powering on the robot:

!>The robot has started successfullly if the indicator lights of actuators and robot host flash regularly.

![1698661268810](image/README/1698661268810.png ':size=60%')
![1698661268810](image/README/1698661268810.png ":size=60%")

## Connecting Remote Controller to Robot

1. Switch on the remote controller and open the **System Settings** interface.
2. Input the Wi-Fi account and password specified on the back of the robot.

![1698736555432](image/README/1698736555432.png ':size=80%')

![1698736555432](image/README/1698736555432.png ":size=80%")
3. Click **Connect** .

!> A success prompt will be given when the connection succeeds.
Expand All @@ -81,11 +79,11 @@ Do the following steps before powering on the robot:
1. Ensure that the robot is fastened to the support stand.
2. Click **Initial** to make the robot to initial state.

![1698744141867](image/README/1698744141867.png ':size=80%')
![1698744141867](image/README/1698744141867.png ":size=80%")
3. Lower the robot with the lift of the support stand and ensure the robot's feet stably contact with the ground.
4. Click **Stand** in the remote controller.

![1698744210172](image/README/1698744210172.png ':size=80%')
![1698744210172](image/README/1698744210172.png ":size=80%")

## Controlling Robot

Expand All @@ -96,11 +94,11 @@ Do the following steps before powering on the robot:

Use right handler to control the vision field.

![1698744913325](image/README/1698744913325.png ':size=80%')
![1698744913325](image/README/1698744913325.png ":size=80%")

## Pausing Robot Motion
## Halting Robot Motion

Following two approaches are used to pause the motion of the robot:
Following two approaches are used to halt the motion of the robot:

* Press the **Stand** button on the remote controller.
* Press down the E-stop button in case of danger or any emergency situation.
Expand Down
Loading

0 comments on commit b6f83d0

Please sign in to comment.