FAQ

If you're experiencing difficulties with your Origin One, please consult this section list of known issues and the proposed mitigation before contacting Avular.

In case the problem you're experiencing is not listed here and you cannot resolve it, please do not hesitate to contact Avular.

Frequently asked questions

Can you work with multiple laptops on the robot?

Yes, you can do that. Multiple devices can be connected to the robot via SSH, and therefore can also be connected to the ROS2 network of the robot. Either for reading data or for calling services

Should you connect multiple instances of Cerebra Studio to the robot, for example one device from you and one device from your co-worker both running Cerebra Studio, then they may both be connected to the robot at the same time. You will also be able to visualize the location of the robot on the map. However, you will render into issues when managing jobs for the robot, along with their paths, waypoints etc. It will NOT be that nay changes made by one user are automatically synced with other users also running Cerebra Studio.

How to know which map the robot is using?

For localization and planning the robot will use a localization_map that is being published from the database of the robot. In Cerebra Studio though you may use a different map than the one that the robot is actually using. This may cause unclear situations when the robot is operating. Therefore, to be sure that you visualize the same map as the robot is currently using, you should look for the active green indicator in the list of Locations in Cerebra Studio.

REMARK: Cerebra Studio does not automatically switch between map when the robot is switching its map.

How long may the robot be in a StandBy mode?

When booted up the Origin One will run different software packages for robot control and autonomous navigation. Often, you will develop your own application on top of the robot, implying that the robot will be standing by most of the time. You may experience issues when you then want to start using the robot.

For example, the remote controller will turn itself off when it did not receive input for over half an hour. To connect the remote controller to the robot you should turn the remote controller back on and press the "O" button to request control of the robot.

Or the robot does not start the task it is asked to execute. This may be caused by the Autopilot Inference that rendered into issues and caught itself in a dead-lock. Best is then (soft) restart the Autopilot Inference, i.e., ssh-into the robot and run $avular compose stop followed by $avular compose start, or to physically turn the entire robot off and then on.

Why is my Origin One (still) driving slowly?

When the robot is switched to MAPPING mode, then the maximum velocity of the robot is lowered to create a more accurate map of the environment. This velocity is set on the real-time computer of the robot. When you switch to DEFAULT mode then this maximum velocity of raised again. But for that you should hit the button "Stop Mapping" in Cerebra Studio (switching from Mapping to the Mission Planner in Cerebra Studio will not set the robot to a DEFAULT mode). Also triggering a (soft) restart of the Autopilot Inference, i.e., ssh-into the robot and run $avular compose stop followed by $avular compose start, will not solve this issue and result in a robot that is still driving slowly.

The tires of the Origin are deflated, what to do?

The tires can easily be inflated by a normal tire nozzle. Make sure to set the pressure to 1.5bar. It is good practice to check the tire pressure regularly.

Troubleshooting

Origin One Platform

Origin One remains of E-stop state when all emergency stop buttons are disengaged

Are all emergency stop buttons disengaged and does your Origin One status lights still show emergency stop active and display showing the following image?

Screen - E-Stop

Then the Origin One can be experiencing a known issue its state machine which it cannot resolve by itself.

How to resolve:

Simply reboot the Origin One to resolve this issue.

Origin One does not drive

First check whether the remote controller is connected to the robot, indicated by the blue light on the back of the controller. If that is the case, that is might be that none of the docker containers are running, which are necessary. You may check whether the docker containers are running by ssh into the robot using a terminal and run docker ps. This will list all the docker containers currently running on the robot. It should list a container called pioneers prod and, depending on whether the robot is configured with the Autopilot Inference, it may also run containers named information_manager and autopilot.

If these containers are not running, then please contact Avular's support.

Origin One takes long to power up

Is your Origin slow in booting up, that is, taking more than 2 minutes to boot up (solid red or green lights, depending on the E-stop button status)? With this issue, the booting is "stuck" on the startup animation of the internal realtime computer. The issue is caused by an overflow of the memory of the realtime computer that stores the log files, in reality it should flush old logs with new logs when full. With this issue this functionality is not executed correctly. Please contact Avular to assist you in resolving the issue, it's a minor fix that the user can do themselves with assistance from us remotely.

Origin One moves without providing input

Is your Origin moving without any velocity inputs provided whenever the emergency stops are disengaged? This can be caused by two different causes. Please check the following suggestions.

Origin One was moved during the powering on of the system.

During the initializing phase of the power on sequence of the Origin One, the robot should not be moved. Otherwise the odometry sensors get initialized and calibrated with a nonzero value. This can result in the Origin One moving without providing control commands (i.e. remote controller joystick movement).

How to resolve:

Simply reboot the Origin One and keep it stationary until the startup sequence is complete.
Remote controller (PS4) is experiencing stick drift.

A known issue of the DualShock 4 (PlayStation 4) controller is that it can experience stick drift over time. This phenomenon is experienced when the remote controller sends out control commands without actuating any of the two joysticks. To check if this is the actually the case, the user can check if there are commands sends to the Origin over the /robot/joy topic. To analyze this joy message, you need to establish a ROS2 connection with the Origin One or create an SSH connection with the robot and enter a user container. Once inside the ROS2 network, use the following command to assess the joy messages.
```
ros2 topic echo /robot/joy
```
Now let's analyze the message content without touching the remote controller joysticks. If the messages shown in the terminal contain values different then the following code-snippet, then the controller is experiencing stick drift
```
axes:
- -0.0
- -0.0
- 1.0
- -0.0
- -0.0
- 1.0
- 0.0
- 0.0
```
How to resolve:

There are a few ways to troubleshoot this issue. Please consult the following link to get started with this. If steps 1-4 do not resolve the problem, please contact Avular. Do not proceed with replacing analog sticks before consulting Avular.

The robot cannot be turned on (does not respond to the power button)

There can be 2 reasons why a robot is not able to startup. One software and one hardware reason.

Software: When the real-time computer of the robot was not able to properly shut down it will get stuck in a shutdown sequence. Therefore, at a next moment when you want to start the robot and power it on, it will not be able to respond as it is still stuck in a prior shutdown sequence. Apart from the robot not being able to startup, you may identify this situation by the fact that the Lidar is still warm (indicating it is powered).

How to resolve: simply press the power button for more then 10 seconds and release it. Then, wait for about 1 minute to power up the robot again. In case this did not work, than it might be caused by the hardware of the robot.

Hardware: When the battery of the robot has been depleted too much (less than 38 Volts), then the real-time computer will not be starting, and therefore nothing of the robot will be starting and the lights will remain off. To check whether this is the case, you may take a Volt meter and measure the voltage of the charging connector of the robot.

How to resolve: If this measures less then 38 Volts, then you should charge the robot first.

The robot does not seem to charge

When the robot is plugged to the charger, then the led of the charger will be "green". If you then also plug the charger into a wall socket, then the light will turn "red" when it is actually charging, followed by "green" when it is not charging the robot (when the battery is already full). So if the light is "red" then the charger is definitely charging the robot. Note that the fan of the charger should also be turning at those situations. If the light is green, then the charger is not charging the robot, which may occur when either the wall socket is not functioning properly, or when the cable between the wall socket and the charger is broken (which you may replace with any similar cable as provided by Avular).

The location of the robot in front of a marker is inaccurate

Localization of the robot in front of an Aruco marker is mostly accurate in linear position, i.e., in X and Y, but is set (internally) as not so accurate on its orientation. When the robot is starting up you will not see any issues related to this, as then the will only have one orientation, i.e., the one with respect to the marker, and thus will estimate its own orientation accordingly. But when the robot drives in front of a marker after an operation, then it may take its previously tracked orientation as being the more accurate than the orientation measured from an Aruco marker (even though this measured orientation from the Aruco marker is better than the one previously estimated by the robot itself).

How to resolve:

In order to align the robot's self-estimated orientation with the orientation of the Aruco marker, it is best to drive te robot back and forth in front of the marker.

The location of the robot outside is inaccurate

When outdoors, and RTK-GNSS is available, then the robot will "trust" the RTK-GNSS measurement is being the one that is most accurate. However, the robot is not aware of any distortions to the sensor signal, for example when it is operating near building. Therefore, the robot may drive in a completely wrong direction, even though in Cerebra Studio the robot thinks it is driving along a planned or given path. But in reality the RTK-GNSS measurements are being effected by nearby buildings, thereby adding errors to the estimated position of the robot.

How to resolve:

Often there is not much you can do when RTK-GNSS reception is bad, other than operating in a different area.

Connecting to the Origin One

Cerebra Studio does not show my Origin in the pop-up connection menu

The auto-discovery process of Cerebra Studio on the Origin One located on the network of your computer may sometimes have difficulty in detecting a robot. This means that the robot is not present in the drop-down menu of Cerebra Studio for connecting to a robot

How to resolve:

Select to connect to another device and state the IP-address of the robot directly. The IP-address is either 192.168.192.1 in case you are connected to the WiFi hotspot of the robot, or it can be found by toggling through the menu of the onboard UI in case the robot is connected to some external WiFi network.

ROS2 topics are not available on my user PC or companion PC

Your user PC and/or companion PC are connected to the ROS2 network of the robot by a Zenoh-server (running on the robot) and a Zenoh-client (running on the user/companion PC). The Zenog-server is known to crash when the ROS2 network has equally named nodes, topics or services that are in use or being called, which shall happen when Cerebra Studio is also connected to the robot and requests information or sends jobs. Therefore, you may expect that the Zenoh-server on the robot will have crashed once you operated the robot with Cerebra Studio.

We are working on this bug.

How to resolve:

Close Cerebra Studio, stop you Zenoh-client, and restart the Zenoh-server on the robot by ssh into the robot and run:

docker stop zenoh
docker start zenoh

Then, you may start the Zenoh-client again. Yet remember, do not connect Cerebra Studio to the robot as well.