Job scheduling and monitoring

Corresponding components: Cerebra Studio – Mission Planner.

Avular has developed a user interface, called Cerebra Studio, via which a user may schedule, execute and monitor the operations of the robot (called jobs). Some aspects of Cerebra Studio were already introduced, such as the mapping workflow and definition of tasks. A job is an ordered list of tasks that requires prior information about maps, paths polygons and waypoints before such a job can be executed. The administration of this prior information in Cerebra studio, together with the status signals shown by Cerebra studio, are explained on this page.

Info

This section is applicable only if your Origin One includes autonomous capabilities.

Info

Confirm that Cerebra Studio is installed on your computer. See the installation guide for instructions.

Managing prior information

The robot requires information before it may execute a job. Information such as:

• Localization maps for navigation (if applicable) and path planning;
• Polygons indicating the layout of such maps or the boundaries for covering areas;
• Paths that are used in Follow Path tasks
• Waypoints that are used in GoTo Waypoint tasks.

On the top left of Cerebra Studio you will find some buttons to open the library where such information, as it is present on either the robot or your local computed, can be found and checked. The illustration below shows all buttons of Cerebra Studio, followed by a short explanation on each of them.

Open library opens a library containing all information present on the robot and your local computer.

Download map for offline use will save the satellite image linked to the current location as set for Cerebra Studio, so that you may use it also when your computer is not connected to the internet.

Save to computer will save the details of the current job to your computer.

Upload to robot will save the details of the current job to the robot.

Start job on robot will save the details of the current job to the robot and immediately start its execution.

Abort job will abort the execution of the robot, although it will try to finish the current task of the job it is executing.

Scheduling a job

The mission planner of Cerebra Studio has 2 main windows. One is the "Plan" window in which you may defined a job as a list of tasks, as was shown in the previous examples on indoor and outdoor operations. We will assume that you have defined such a tasks, which is named "job_for_manual" in the example below, and that the job was saved to your local computer and to the robot - using the buttons of Cerebra Studio's mission planner. The other window is the "Scheduling" window that can be used for scheduling jobs in the future. Here, we will introduce how you may use this scheduling of jobs.

In the snippet below you will notice the part in Cerebra Studio's mission planner where you may switch between planning and scheduling a job. There are two tabs, one called "Plan" and one called "Schedule". Once you have saved a job to your computer and to the robot you may click on "Schedule to start scheduling the job.

Cerebra Studio now displays the interface for creating a schedule and link that schedule to a job. A snippet of what Cerebra Studio is presented to you as a user is shown below. Herein, you will see that you are connected to an Origin One robot, while the row below indicates status buttons for you to interact with the scheduling interface:

• Add schedule shall create a new schedule for you to adjust.
• Sync status indicates whether your computer and the robot are in sync on the schedules that have been defined.
• Local status indicates whether any current changes made in Cerebra Studio have been saved to your local computer
• Triggering status indicating whether the current schedule selected in Cerebra Studio should be uploaded to the robot and selected for (later) execution.

By clicking on the butting Add schedule a new entry will be created named "New schedule" that is not yet linked to a job and with a scheduling definition initialized on the current time. The illustration below displays this newly created schedule in Cerebra Studio. To the right of this display you will see multiple fields that you may update for the schedule you have selected, such as the name of the schedule as well as the job to which the schedule is linked and the actual timings of the schedule.

In the two examples below we have renamed the newly created schedule in "schedule_for_manual" and linked it to the job we previously defined called "job_for_manual". in the first example below we have created a schedule with a single instance to run the job at noon, while in the next example we have created a recurrent schedule to run the job at noon on every week-day.

The final steps in order to command the robot to execute the job at the given schedule is to Save changes followed by clicking on the button Schedule on.

Warning

Please do not shutdown the robot as then it will not be able to trigger the execution and also ensure that the robot is not connected to the charger as there is no check to prevent that the robot will not start the job when the charger is connected (and it will thus break the connector).

Warning

This feature assumes that the Autopilot Inference does not come across any internal errors while waiting. The linger the robot has to wait until the schedule starts, the more likely it is that such an internal error will occur and therefore preventing the robot to start the job.

Info

Park your robot in front of an Aruco marker, or in RTK-GNSS supported areas, so that the robot will not lose its position accuracy which may also prevent it from starting the execution of the job at the defined schedule.

Monitoring the status

Prior and during the execution of tasks the robot will inform the user on some important status values. On the top right of Cerebra Studio you may find the section that signals on these status values. The illustration below also illustrates a typical set of status values, while more details on other status values is introduced below the illustration.

Execution status is the first element providing information about the execution of the robot. It may present information about the initialization procedure, for example when the robot is starting up, or it may present information about the current task (or behavior) that the robot is executing. In the illustration below the message states that the robot is "waiting for behaviors to execute". This means that the robot is standing idle and waiting for a task or a list of tasks (job) that it will execute using the behaviors that were implemented on the robot.

Position status is the second element providing information about the accuracy with which the robot is able to estimate its position in the world. The order in which with which the position has been estimated in indicated as follows, starting from mostly inaccurate up to as most accurate: "unknown", "inaccurate position", "inaccurate orientation", "accurate". The robot is only allowed to navigate autonomously when the position is "accurate".

RTK status is the third element providing information about the availability of RTK-GNSS. It shows if RTK-GNSS is available, or not, and how many satellites are being detected via which the robot is able to compute its latitude, longitude and altitude.

Status indicators
When the robot is switched on either in front of an Aruco marker, or after a small manual drive with RTK-GNSS available, its position should be accurate. The robot will then wait for the user to specify which behaviors to execute. These behaviors are triggered when you start the job you have defined.
After uploading the job to the robot, you may notice that it does not immediately begin to move. The status indicators may show that Autopilot Inference is waiting to take control of the robot. This typically occurs if you previously operated the robot manually and initiated job execution without first releasing control. In this case, the robot remains in MANUAL mode. To resolve this, press the "X" button on the remote controller to release control, allowing Autopilot Inference to take command and begin executing the job.
While the robot is executing a job and in motion, it may notify the user that it is operating within a known map and is using LiDAR data to improve its position estimate. In most cases, the robot will also indicate that it has achieved high pose accuracy.
Alternatively, while the robot is executing a job and in motion and it is not operating within a known map, then the status is switched to navigation without a exploiting a map.
When the robot is booted with RTK-GNSS available, but the status indicators show that it is waiting for behaviors to execute and waiting for a proper position, the robot will not start a job (even if one has been uploaded) until its position is sufficiently accurate. This can happen if the RTK-GNSS signal is unstable or if the robot needs to be manually driven back and forth to improve its orientation estimate.
When the robot is booted indoors, yet not in front of an Aruco marker, Autopilot Inference will remain in a waiting state until an accurate position estimate is available. Either the position or the orientation is indicated as "inaccurate". Also, the status indicators will show that the robot is waiting for a valid position due to low pose accuracy. To resolve this, simply drive the robot in front of a marker to resume the initialization process.
After entering a state where the robot is awaiting a valid position, and you solved that issue as mentioned in the rows just above, there may be a brief intermediate state before full initialization is complete. During this state, the status indicators in Cerebra Studio may show conflicting messages — one indicating that the robot is still waiting for a proper position, and the other confirming that it has already achieved high pose accuracy. It means that the position is already accurate within the system, but that the internal manager of the robot is yet to be updated.
When the robot is connected to Cerebra Studio, there may be cases where the application is unable to retrieve the robot’s status. This will be indicated by a status of "unknown" in the interface. If you are sure that the robot is indeed turned on properly, then a typical solution is to first disconnect and the again connect to the robot