FAQ

After a video call or multiple video calls, there is no response to the conversation with Xiaobao.

Because of the particularity of the robot microphone array, only the correct parameters can get data from the Recorder, and all parameters are fixed parameters and cannot be changed, otherwise there may be no data collected.

When accessing the three-party SDK, it is possible that the audio data collection parameters in the SDK are inconsistent with the robot parameters, resulting in a different sampling rate after a video call. It needs to be reset when the system takes over. However, resetting the sampling rate sometimes does not succeed. It cannot be converted to the specific sampling rate of the robot, so the robot cannot receive the sound normally after the video call.

Solution: Just change the audio sampling rate of Sanfang SDK, or custom audio sampling rate, to the robot’s fixed sampling rate.

Agora solution

Robot audio collection parameters

Currently, the SDK opening capabilities related to Zhaocai Leopard’s multi-machine collaboration are not yet provided.

Multi-machine cooperation includes multi-machine scheduling and multi-machine avoidance functions. It involves the basic capabilities of robot multi-machine cooperation. The communication module mainly involved here also belongs to the robot’s multi-machine cooperation basis. The capability part, the system function to which it belongs, is therefore not provided to secondary development partners for open expansion.

Multi-robot collaboration does not require us to do any operations, and all behaviors are scheduled by the robot system. But the premise is that the robots must be guaranteed to work under the same map. After multiple robots meet, they will call our robots to communicate, and their work priorities at this time will be sorted to determine whether to avoid or continue to work, so as to avoid multiple robots. When two robots meet at the same place at work, they are sluggish. Therefore, it is only necessary to ensure that the robot performance and hardware are normal, and the multi-machine collaboration capability can work normally.

Currently, the SDK opening capability of the top camera of the Zhaocai Leopard is not provided.

The top camera belongs to the robot sensor, that is, the basic capability module of robot navigation control involved in the sensor. It is the basic capability module of the robot, used for positioning, and belongs to the system navigation capability.

The top camera is mainly used to scan tags. Together with the radar, it constitutes an important guarantee for the robot to locate the current position and avoid getting lost. Therefore, this part of the function is related to the robot’s basic movement control walking ability and the system function, so it is not provided to the second Sub-development partners do open-ended expansion.

Although the function here does not provide two openings because it involves the basic capabilities of the robot, as long as the robot is operated properly, our map label is attached, and our map tool is used correctly to build a map along the label, then a line is formed. The navigation route identified by the infrared camera on the top of the robot itself will not affect the normal operation of the related functions of the top camera as long as the label and the top camera are correct. (In addition, the radar can also guarantee the positioning and navigation functions of the robot, but the label is the most accurate. Under normal circumstances, the robot must be labeled when entering the venue).

The camera on the robot is initially set at a direction of 90° when launched through the standard Android method. This is because the robot does not have a gyroscope, and the program defaults to a portrait-oriented camera, whereas the robot is an landscape-equipped device. The solution is simple – by using the Android API (or APIs provided by other video SDKs), the camera rotation can be corrected by -90° or 270°.

Other camera functions are the same as the standard Android camera. Here’s a demo that uses the Android Camera component that you can refer to:

Demo using Camera1 suitable for Greetbot Mini.

Demo using Camera2 suitable for Luckibot .

Note: Due to existing bugs in the robot’s authorization, the app may crash when authorizing camera usage for the first time. However, there are no further limitations after that. If the app crashes while authorizing the camera, simply restart it, and the camera usage should work normally.

Because the robot microphone array requires long sound pickup, there are some restrictions on using the audio recorder function from the Android framework.

It must be under specific audio settings to receive sound. For details, please refer to SDK document->Audio->Robot audio collection parameters

There are only two ways to correctly load the robot ability component of the installed APK:

1. Through the robot application center, click apk to run.

The specific method is: pull down with three fingers on the robot screen -> all applications -> find the APK and enter.

If you need a debug program, you can open the APK in this way, and then the attach process can be debugged.

For example, we want to open a developer demo Demo:

2. Set the APK as the default APK.

This method is not suitable for debugging, please refer to the SDK access part in apk development for details.

If you use Android studio’s run or debug to directly start the apk, it will not be able to load the robot ability components correctly, remember.