[Quick Guide] Husky | xARM6 | Robotiq 2F-140 | Ouster | Intel Realsense D405 | Phidgets

Husky | xARM6 | Robotiq 2F-140 | Ouster | Intel Realsense D405 | Phidgets

This post is a quick and compact guide for working with Husky which has been augmented with a variety of sensors such as Ouster, Intel Realsense D405, Phidgets as well a robotic manipulator xARM6 and a robotic gripper Robotiq 2F-140.

Informative Links

Quick Start

Powering On

The robot is turned on via the power button, and the start-up of the Husky may take up to a minute to start. The green light indicates that the MCU has successfully started and is now able to receive commands from the onboard PC.

For software remote connection, the robot may be accessed via an ethernet port or via the onboard WiFi.

Teleop

Some quick useful commands in case there is an issue with the joystick is to ssh into the robot and teleoperated it via:

rosrun teleop_twist_keyboard teleop_twist_keyboard.py

Network

Network configuration for the robot is.

Device Network Password
Husky MCU 192.168.131.1 clearpath
xARM6 192.168.131.5 -
xARM6 GUI 192.168.131.5:18333 -
Ouster 192.168.131.20 -
Router 192.168.131.100 mybotshop23

Robot Interface

The network configuration can take place in one of two methods, the first being via the static network connection and the second being through the screen, where the screen method is much quicker and easier for clients to set up. Alternatively, the hotspot Husky-A200-2.4G or Husky-A200-5G can be used to connect with the robot.

Hotspot Network Connection

To connect via hotspot, please search for the SSID of Husky-A200-2.4G or Husky-A200-5G and connect to it. The password is:

mybotshop23

Once connected, you can interface and ssh into the robot via:

ssh -X administrator@192.168.131.1

Static Network Connection

For the first time, one needs to connect through a LAN cable to configure the robot’s WLAN network.

To create a static connection in your own PC (not the Husky), in Ubuntu go to Settings → Network then click on + and create a new connection.

  1. The first task is to go to IPv4 and change the connection to manual.

  2. The second task is to put the Address IP as 192.168.131.1 (may differ from robot to robot) and the Netmask as 24.

Click save and restart your network. Next is to connect the LAN cable to the robot. After a successful connection let’s check the host’s local IP by typing in the Host PC’s terminal.

ifconfig

This should show the host IP which was assigned in the above step. Now its time to check if we can ping the robot or not, to do so type in your host pc

ping 192.168.131.1

After a successful ping, it’s time to access the robot. To access the robot you can type the following command:

ssh -X administrator@192.168.131.1

The password is

clearpath

Screen Connection

An alternative for connecting to the Husky is by plugging in an HDMI cable as well as a mouse and keyboard. This will allow you to connect the Husky to your own local WiFi network and then you can connect later over the WiFi.

Husky PC

The procedure is simply to go to your networks and add your WiFi. Then in the terminal type:

ifconfig

The IP that comes with the initial characters of wl is your WiFi’s IP. e.g. wlps0. With this IP you can SSH to your robot via your host PC.

ssh -X administrator@192.168.0.228

192.168.0.228 is just an example of this. IP is taken from the ifconfig.

clearpath

Please note not all Husky are shipped with the WLAN module.

Robot Software

The Husky drivers as well as custom drivers configured by MYBOTSHOP are located in the ros_ws. In the src folder, the third_party contains the drivers for the Husky and other sensors.

As requirements vary from user to user, the setup has been left as default and the users can specify their own parameters in their own custom package. When connecting or ssh’ing to the robots pc, additional information regarding the robot will be displayed e.g.

-----------------------------------------------------
 _  _  _  _  ____   __  ____  ____  _  _   __  ____   
( \/ )( \/ )(  _ \ /  \(_  _)/ ___)/ )( \ /  \(  _ \ 
/ \/ \ )  /  ) _ ((  O ) )(  \___ \) __ ((  O )) __/ 
\_)(_/(__/  (____/ \__/ (__) (____/\_)(_/ \__/(__)   
-----------------------------------------------------
Current PC: Husky 
-----------------------------------------------------
Husky IP:     192.168.131.1 
Pswd:         clearpath
   
xARM6 IP:     192.168.131.5 

Ouster IP:    192.168.131.20

Router IP:    192.168.131.100
Pswd:         mybotshop23
-----------------------------------------------------
Husky-xARM6-Gripper-Drivers
----------------------------------------------------- 
HXG status:   sudo service hxg status
HXG start:    sudo service hxg start
HXG stop:     sudo service hxg stop
HXG restart:  sudo service hxg restart

View robot:   roslaunch hxg_viz view_robot.launch
-----------------------------------------------------

Robot Startup

The startup job launches two main components:

  1. Husky base drivers
  2. Phidgets IMU driver

The launch file system_bringup.launch in the ros_ws package of hxg_startup includes everything which is being launched at the startup.

The Husky ordinarily utilizes Clearpath startup job unless otherwise specified. In this robot, we have our own upstart job for the custom auxiliary drivers. In case there is an issue with the robot not starting up. One can ssh into the Husky and verify if the startup job is working correctly.

sudo service hxg status

The red marker in the service indicates that the startup job has failed. Green indicates everything is operating correctly. Grey indicates that the service has not started yet. In case of red or grey marker, you may restart the service via:

sudo service hxg restart

New launch files and nodes can be added to the startup job by inserting them into the system_bringup.launch launch file for PC startup. Once added Run the following in ros_ws.

rosrun hxg_startup startup_installer.py

It should now run with the updated additions.

Configuration

###### Sensor Information
export HUSKY_LOGITECH=1
export HUSKY_IMU_RPY='3.1416 0 0'
export HUSKY_IMU_XYZ='0.19 0 0.149'

# Add HXG Environment 
export HXG_XARM_IP='192.168.131.5'

export HXG_REALSENSE=0

export HXG_OUSTER_LASER=0
export HXG_OUSTER_IP='192.168.131.20'
export HXG_OUSTER_HOST='192.168.131.1'

# ROS Environment Variables
export ROS_MASTER_URI=http://192.168.131.1:11311/
export ROS_IP=192.168.131.1
export ROS_HOSTNAME=192.168.131.1

The configuration file is located in hxg_startup/config/setup.bash. The important information is that the variables HXG_REALSENSE=0 and HXG_OUSTER_LASER=0 can be used to enable the roslaunch files. If the values of 0 are replaced by 1, it will enable the launch files for the realsense camera to turn on e.g. HXG_REALSENSE=1 (The file must also be source e.g.: source setup.bash). This will also enable it to start on the robot startup if the following command is executed.

rosrun hxg_startup startup_installer.py

Please note that it is not recommended to keep the sensors on as they take time to startup and cause the startup job to fail. If this happens you can simply restart the service. As described above.

xARM6 | Robotiq 2f-140 (Robotic ARM | Robotic Gripper)

The xARM6 driver and robotiq drivers can both be turned on and used with moveit with the following:

roslaunch hxg_arm6 xarm6_robotiq.launch

This launch file includes the custom moveit setup for the Husky and the xARM6.

Ouster (Lidar)

The Lidar drivers are started via:

export HXG_OUSTER_LASER=1
roslaunch hxg_lidars lidars.launch

Intel Realsense D405 (Depth Camera)

The Lidar drivers are started via:

export HXG_REALSENSE=1
roslaunch hxg_realsense_cameras wrist_camera.launch

Phidgets (Inertial Measurement Unit - IMU)

The provided Husky has a phidgets IMU integrated into it. The parameters for odometry can be tuned in the folder ros_ws/src/mbs/hxg_control/config/wheel_localization_config.yaml.

It is recommended not to change the parameters without a backup and without expert supervision.

Issues

In case of any issues please first try restarting the service of the robot via:

sudo service hxg restart

In case of questions please contact support@mybotshop.de. For issues related to the software please attach a ros bag e.g.

rosbag record -a

Dear Myra,

a red light usually appears when the ROS Service is not up an running (connection between PC & Husky itself)

@Sohail may you can assist?

Dear @myra,

Please provide the following information

OS: (e.g. Ubuntu 20.04)
ROS Distro: (if applicable)
Built from source or pre-installed

Expected behavior

A clear and concise description of what you expected to happen.

Actual behavior

A clear and concise description of what you encountered.

To Reproduce

Provide the steps to reproduce:

  • run something
  • launch something else
  • see the error
  • Other notes

Add anything else you think is important.

We have the same equipment from that project, but the HUSKY robot seems to have problems after one charge. The robot’s fault light comes on and the robot cannot be moved by remote control operation. Can you please tell us what is the reason for this phenomenon in general.
Thanks in advanced!

Concerning the red light of the Husky is due to the ROS startup service failing which may be due to one of several reasons.

  1. There is roslaunch file that has been added to the startup job that does not work consistently.
  2. There is an IP conflict on 192.168.131.1 sometimes due to the ethernet bridge
  3. The initially delivered hardware had one of its auxiliary component’s wires switched or tampered → This causes the issue of the first point which you can identify and resolve by simply commenting out all auxiliary drivers except Husky and its IMU driver and then running rosrun mbs_husky_startup startup_installer.py [change according to the documentation provided to you] after which check if it is starting up correctly.
  4. Change in the startup installer file
  5. Extremely rare and unlikely but discrepancies in the PC’s time

Most likely your issue is either point 1 or point 2. The solution point 1 is provided in point 3 and if the issue is point 2 then you can remove or disable all ethernet connections except the one coming from the Husky and then switch the other ethernet connections on one by one to identify the sensor that is causing the conflict and then change its IP.

Hope this helps!

Regards,
S. O. Sohail

Dear @myra,

Regarding point 2, the power flickering is normal in the Husky and is from the manufacturer.

As for point 3 and 4, it seems some of the auxiliary cables have moved or one of the connections have been removed (e.g. lidar, depthsense camera, robotiq, etc.). The solution is as mentioned above for resolving the issue. Modifying the or displugging the connections in the Husky results a change the ROS startup as it might be the case that your robot is running all the drivers on startup and if they are not detected then the driver fails causing the startup job to fail. So for clarification, change in the hardware will be reflected in the software drivers in case they are in the startup job!

It would help clarify which components your husky has as well as the distribution and based on that we can guide you further.

@myra, FYI: If you could send Salman a private message with the S/N of the Husky, we could check, which components are mounted and in which Ubuntu & ROS distro the robot was setted up. I wouldn’t recommend changing the cableing etc. in any way!

In case you are not familar with ROS please feel free to arrange a 15min Video call so we can get access to the robot and can show you how to find and solve the issue.

Also, please note that on the back of the Husky, you have to twist the emergency stop button in case it has been pressed.

Thanks for your help, the HUSKY can work now. Based on your reminder I found out that the key next to that emergency stop button is in a locked state, thus preventing HUSKY from operating correctly.

2 Likes

Dear Support Team,

I hope this message finds you well. I am currently facing an issue while setting up the HUSKY project by your docs and I am seeking your assistance and guidance.

Inadvertently, I installed the workspace in the directory of the ‘myra’ user. The problem I am encountering now is that the ’ administrator’ user is unable to access any packages or files within the workspace. This is causing operational issues, and I am keen to resolve this to continue my work.

I am unsure whether I need to reset the Ubuntu system and reinstall the HUSKY project, or if there is a simpler solution to address this problem. If there are alternative methods, I would greatly appreciate your guidance on how to correct my configuration so that the administrator user can access the files and packages within the workspace.

This is my currently configuration:

[Note] Target OS version >>> Ubuntu 20.04.6 LTS
[Note] Target ROS version >>> ROS noetic
[Note] Catkin workspace >>> /home/myra/catkin_ws
[Note] Non-ROS package build space: >>> /home/myra/catkin_ws/utils
[Note] Robot package build space: >>> /home/myra/catkin_ws/src/mbs
[Note] Package dependencies build space: >>> /home/myra/catkin_ws/src/third_party

Dear @myra,

Thank you for asking we are doing well, and we hope you too are well!

Inadvertently, I installed the workspace in the directory of the ‘myra’ user. The problem I am encountering now is that the ’ administrator’ user is unable to access any packages or files within the workspace. This is causing operational issues

Please explain? Was the workspace deleted and/or what was the need of a separate user?

I am unsure whether I need to reset the Ubuntu system and reinstall the HUSKY project, or if there is a simpler solution to address this problem

We highly advise against this unless you have worked with several Huskies and are quite the expert on it. The reason is that UDEV and several other services have been modified to enable the current setup to work correctly.

If there are alternative methods, I would greatly appreciate your guidance on how to correct my configuration so that the administrator user can access the files and packages within the workspace.

I would advise that you add your workspace directly into the administrator, ros_ws/src/myra instead of creating a separate user myra. As to my knowledge, ros1 when installed as any user other than the root cannot freely access other users unless by jumping through several software configurations. Also, this is not well documented by the community, hence, following ros convention, we advise to simply add your own workspace to the administrator user in src.