I'm running into what looks like to be almost the exact same issue described in #37 after pulling the most recent updates from master. This happened with an older version and the solution given in #37 fixed it, but now that fix doesn't seem to work with the latest changes. Any advice on troubleshooting?

Here's the error message:

Traceback (most recent call last):
  File "/home/administrator/catkin_ws/src/spot_ros/spot_driver/scripts/spot_ros", line 3, in <module>
    from spot_driver.spot_ros import SpotROS
  File "/home/administrator/catkin_ws/src/spot_ros/spot_driver/src/spot_driver/spot_ros.py", line 19, in <module>
    import tf2_ros
  File "/opt/ros/melodic/lib/python2.7/dist-packages/tf2_ros/__init__.py", line 38, in <module>
    from tf2_py import *
  File "/opt/ros/melodic/lib/python2.7/dist-packages/tf2_py/__init__.py", line 38, in <module>
    from ._tf2 import *
ImportError: dynamic module does not define module export function (PyInit__tf2)

ROS Melodic
Spot firmware: 2.3.3

I tried to visualize the Spot in the Gazebo using the provided xacro

<?xml version="1.0" encoding="UTF-8"?>
<launch>
    <param name="robot_description" command="$(find xacro)/xacro.py '$(find spot_description)/urdf/spot.urdf.xacro'" />

    <!-- spawn initial location -->
    <arg name="x" default="1"/>
    <arg name="y" default="1"/>
    <arg name="z" default="0.5"/>

    <node name="spot_spawn" pkg="gazebo_ros" type="spawn_model" output="screen"
          args="-urdf -param robot_description -model spot -x $(arg x) -y $(arg y) -z $(arg z)" />

    
    <!-- <node name="robot_state_publisher" pkg="robot_state_publisher" type="robot_state_publisher" /> -->

</launch>

In gazebo , there is a model called "spot" is generated but nothing can be seen.
Can this description be used in gazebo?

I often see the following trace when shutting down the driver node. This might be something to do with incorrect ordering, or perhaps that releasing the lease automatically releases the estop keepalive somehow.

Traceback (most recent call last):
  File "/opt/ros/noetic/lib/python3/dist-packages/rospy/core.py", line 572, in signal_shutdown
    h()
  File "/home/spot/spot_ws/src/spot_ros/spot_driver/src/spot_driver/spot_ros.py", line 825, in shutdown
    self.spot_wrapper.disconnect()
  File "/home/spot/spot_ws/src/spot_ros/spot_driver/src/spot_driver/spot_wrapper.py", line 492, in disconnect
    self.releaseEStop()
  File "/home/spot/spot_ws/src/spot_ros/spot_driver/src/spot_driver/spot_wrapper.py", line 462, in releaseEStop
    if self._estop_keepalive:
AttributeError: 'SpotWrapper' object has no attribute '_estop_keepalive'
shutting down processing monitor...
... shutting down processing monitor complete
done

Hi Thanks for this work.
I had a problem let the robot stand up. Following the guidance from tutorial.
I can call rosservice to claim this robot in my terminal

~/spot/spot_ws$ rosservice call /spot/claim 
success: True
message: "Success"
~/spot/spot_ws$ rosservice call /spot/power_on 
success: True
message: "Success"

I can hear that the power is on from the Spot
But when I try to call stand up service, there is an error

~/spot/spot_ws$ rosservice call /spot/stand 
success: False
message: "bosdyn.api.RobotCommandResponse (UnsupportedError): The API supports this request,\
  \ but the system does not support this request."

Seems Do I need to upgrade something?

Thanks!

My PR about trajectory cmd uses ROS service as a API for trajectory command which enables spot to move to a given position.
But I think there are 3 candidates of API for trajectory cmd.

• topic ( e.g. /cmd_vel )
• service ( e.g. services in spot_driver such as /spot/stand )
• action ( e.g. Action API of move_base )

According to patterns for ROS Communication API, I implemented trajectory cmd as a service because I thought it is a kind of remote procedure which issue a robot command with Boston Dynamics API.
But it is also good to make trajectory cmd as a topic or an action if treating trajectory cmd as a 'continuous data stream' like /cmd_vel or a 'discrete behavior' like move_base.

How are folks relocalizing Spot? When running Spot for a while, my Vision/Odom frames get radically offset from the robot. I.e. the Vision frame is 15 meters below Odom frame, and the robot's GPE is another 10 meters below and away from that. So when building my map and costmaps, everything is offset and the heights aren't valid.
I was assuming that the Vision frame would be accurate over time, but maybe I need something like AMCL instead?

Unless I'm just missing something obvious?

After I run the command

roslaunch spot_driver driver.launch 

I can connect the spot normally and control it through different commands such as sit, stand, velocity.
However, after a few seconds, the terminal will show an error. I can still control the robot, just the error bothers me.

Traceback (most recent call last):
  File "/home/zhaozhong/spot/spot_ws/src/spot_ros/spot_driver/scripts/spot_ros", line 7, in <module>
    SR.main()
  File "/home/zhaozhong/spot/spot_ws/src/spot_ros/spot_driver/src/spot_driver/spot_ros.py", line 586, in main
    self.spot_wrapper.updateTasks()
  File "/home/zhaozhong/spot/spot_ws/src/spot_ros/spot_driver/src/spot_driver/spot_wrapper.py", line 402, in updateTasks
    self._async_tasks.update()
  File "/home/zhaozhong/.local/lib/python3.6/site-packages/bosdyn/client/async_tasks.py", line 39, in update
    task.update()
  File "/home/zhaozhong/.local/lib/python3.6/site-packages/bosdyn/client/async_tasks.py", line 90, in update
    self._handle_result(self._future.result())
  File "/home/zhaozhong/.local/lib/python3.6/site-packages/bosdyn/client/common.py", line 458, in result
    raise error

The spot software is the latest version

The pose portion of the nav_msgs/Odometry messages on the /spot/odometry topic seem to have incorrect quaternions. The w parameter is identically 0, while the x, y, and z values seem reasonable. Inferring the w parameter from the others is possible by assuming it's a unit quaternion and choosing the sign carefully, but this is a hacky solution.

This seems like it might be an issue of the default protobuf value (0.0 for floating point) propagating through the Spot SDK and then this wrapper, but I haven't been able to see anything in the code that actually looks out of place.

Hello everybody,

I made a few commits on my fork (here) to support camera images from spot's arm and to control the endeffector. I verified that the code works but I can't test the code on a spot without an arm currently, since I won't have access to one for quite some time.

Because of this, I don't want to create a PR on this repo, since it might not work with an "arm-less" spot.
Would you prefer that I create a WIP PR and you guys can test/edit it, or should I simply do nothing? (I'd love to save somebody some work in the future)

Best,
Eric

I thought I'd start a discussion about applying some sort of standard formatting scheme to the python code. I personally find it useful to not have to worry about formatting my code, and just apply a formatter to do it for me. It might be useful to have here as well to make sure all the code has a consistent scheme.

I have recently been using black, which I find quite pleasant as there are very few options to fiddle with.

Hi @dniewinski and others,

question: Is this repo actively maintained? The last commits to master are pretty old, and many open PRs could be merged.

Best
Eric

Hello,

using the given xacro model, I launched in gazebo empty world, however, the spot did not appear due to lackness of inertial and mass parameters. I set them randomly, and the spot appeared in the empty gazebo model. However, it would be nice to get real parameters if there are available, and update the current spot.urdf.xacro model

  <link name="anylink " >
....  
        <inertial>
            <mass value="5.0" />
            <inertia ixx="1.0" ixy="0.0" ixz="0.0" iyy="1.0" iyz="0.0" izz="1.0" />
        </inertial>

    </link>

Recent merges add a lot of code which can make the robot move in various ways, and more changes are incoming. The allow motion (and autonomy) flag should be checked for each of them to conform to the expectation that this is available.

• arm commands
• docking commands
• rolling commands

According to Odometry message docs, twist should be expressed in the child frame, which is body.

According to Bodsdyn API docs, velocity_of_body_in_odom is expressed in odom frame.

Thus the twist published by the driver is invalid for downstream nodes that expect it to be in body frame.

Note that fixing this bug could break downstream code that has already adapted to this deviation from the standard, so care has to be taken.

I got an error with spot_ros.py like below. Spot went down when the error showed up.

[INFO] [WallTime: 1605174374.227650] [node:/spot/spot_ros] [func:SpotROS.main]: Starting ROS driver for Spot
Traceback (most recent call last):
  File "/home/lshinjo/ros/catkin_ws/src/spot-ros/spot_driver/scripts/spot_ros.py", line 391, in <module>
    SR.main()
  File "/home/lshinjo/ros/catkin_ws/src/spot-ros/spot_driver/scripts/spot_ros.py", line 372, in main
    self.spot_wrapper.updateTasks()
  File "/home/lshinjo/ros/catkin_ws/src/spot-ros/spot_driver/scripts/spot_wrapper.py", line 346, in updateTasks
    self._async_tasks.update()
  File "/home/lshinjo/.local/lib/python3.6/site-packages/bosdyn/client/async_tasks.py", line 39, in update
    task.update()
  File "/home/lshinjo/.local/lib/python3.6/site-packages/bosdyn/client/async_tasks.py", line 96, in update
    self._future = self._start_query()
  File "/home/lshinjo/ros/catkin_ws/src/spot-ros/spot_driver/scripts/spot_wrapper.py", line 134, in _start_query
    response = self._client.robot_command_feedback(self._spot_wrapper._last_stand_command)
  File "/home/lshinjo/.local/lib/python3.6/site-packages/bosdyn/client/robot_command.py", line 281, in robot_command_feedback
    **kwargs)
  File "/home/lshinjo/.local/lib/python3.6/site-packages/bosdyn/client/common.py", line 225, in processor
    error_from_response=error_from_response, **kwargs)
  File "/home/lshinjo/.local/lib/python3.6/site-packages/bosdyn/client/common.py", line 340, in call
    return self.handle_response(response, error_from_response, value_from_response)
  File "/home/lshinjo/.local/lib/python3.6/site-packages/bosdyn/client/common.py", line 348, in handle_response
    raise exc
bosdyn.client.exceptions.InternalServerError: bosdyn.api.RobotCommandFeedbackResponse (InternalServerError): Command not found, id: 235
[INFO] [WallTime: 1605174455.007530] [node:/spot/spot_ros] [func:SpotROS.shutdown]: Shutting down ROS driver for Spot
[spot/spot_ros-4] process has died [pid 6430, exit code 1, cmd /home/lshinjo/ros/catkin_ws/src/spot-ros/spot_driver/scripts/spot_ros.py joint_states:=/joint_states tf:=/tf __name:=spot_ros __log:=/home/lshinjo/.ros/log/e6444882-24cb-11eb-a312-3868938abb0a/spot-spot_ros-4.log].

The exit of spot_ros.py is caused by exceptions from robot_command_feedback() function. But it seems to come from invalid value in the _last_stand_command member variable of SpotWrapper class.

Hello all,

is it possible to connect a wired ESTOP to the Spot?

After connecting the ESTOP to a payload port, the Spot is no longer usable. The motor lockout cannot be operated and the payload remains off. (Just like when the payload port cap is not mounted).

Are there already circuit diagrams or something else to solve this problem?

Thank you very much for your help.

Does anyone know what the error can be when the robot can not be controlled via the interactive markers? There are no problems controlling the robot with the controller or the console.

As soon as I pull on one of the arrows, the robot makes a step on the spot but does not move in the desired direction. (It seems to be blocked). Also, the depth image shows walls around the spot even though the robot has enough space.

Can anyone help me?

I'm trying to get Spot (and the Velodyne Lidar) to give me a consistent map for navigation, but I always seem to get lag that causes ghosting and blurring when Spot moves/turns. Sometimes the map can correct for it, but eventually it breaks down. I've tried with multiple Slam plugins and all exhibit the same behavior.
I know it isn't 100% accurate, but the same code shows no lag in Gazebo.
My best guess is that there is an incorrect timestamp someplace, but I haven't been able to figure it out.
Anyone else seeing the same thing and/or successfully using Slam mapping nodes (i.e. Slam Toolbox or GMapping) with Spot? Or am I just missing some nuance with Spot/ROS?

Note the Lidar is slightly rotated from the map - which will start to cause ghosting.

The time synchronisation with the robot is done with the time skew component, which has an internal mechanism that is updated every 60 seconds by default. The top chart in the image below shows the time offset between consecutive odometry messages from the robot. When the update happens occasionally there are significant offsets. This seems to happen when the clock of the robot and the operating machine have diverged significantly. The update will gradually bring them together, but these updates can cause problems if you are expecting consistent odometry timestamps. The lower part shows the expected yaw values vs the yaw values given by the odometry, and the discontinuity caused by the gap.

This issue can probably be avoided by having the driver turned on for a while before running anything which needs accurate odometry timestamps. Alternatively, we can modify the sync frequency by changing

to set a shorter time sync interval.

That function is here

Hi,

I am running spot_ros on a jetson nano that is connected via ethernet to the GXP of our Spot. Everything works fine, but when I try to teleoperate spot, either using the interactive marker on rviz, the teleop_twist_keyboard or just publishing on a topic with the command line, spot moves really bad, kind of trembling. On the contrary, when I use the wasd example of the SDK with the same setup, the gate is smooth as it should be. What can be the problem? Maybe the jetson nano is too slow at sending the commands via spot_ros? thanks for helping!

ROS_MASTER_URI=http://localhost:11311

setting /run_id to b3f1c0be-1950-11ed-b0f8-646c80dc09a1
process[rosout-1]: started with pid [23669]
started core service [/rosout]
process[robot_state_publisher-2]: started with pid [23676]
process[twist_marker_server-3]: started with pid [23677]
process[bluetooth_teleop/joy_node-4]: started with pid [23684]
process[bluetooth_teleop/teleop_twist_joy-5]: started with pid [23691]
RLException: unable to launch [/workspace/src/spot_ros/spot_driver/scripts/spot_ros joint_states:=/joint_states tf:=/tf __name:=spot_ros __log:=/root/.ros/log/b3f1c0be-1950-11ed-b0f8-646c80dc09a1/spot-spot_ros-6.log]: Permission denied
The traceback for the exception was written to the log file
[spot/spot_ros-6] killing on exit

As of Spot v2.0.1, Spot no longer requires an application token. We now utilize a license that is local to Spot.

Would you be able to adjust the documentation accordingly? http://www.clearpathrobotics.com/assets/guides/melodic/spot-ros/ros_usage.html#get-an-applicaiton-token

Thanks!

Would be nice to be able to apt-install this.

I commented about this at https://support.bostondynamics.com/s/question/0D54X00006hjR61SAE/replicating-controller-point-motion-with-sdk-commands. If there is an obstacle in front of the robot, sometimes the trajectory command will return basic_command_pb2.SE2TrajectoryCommand.Feedback.STATUS_AT_GOAL when it is not actually at the goal. Currently the actionserver that we have returns success in this case, although actually we did not get to the goal that was requested.

In my own code I'm currently handling this by comparing the position of the robot to the expected end position, but I think it may be a good idea to have this check in the driver itself. We could do this by storing the position of the robot in the odom frame when the goal is received, then once the trajectory command returns, compare the new odom value against the old odom plus the goal in the body frame. Some kind of goal tolerance would be needed.

I have this error after launching: roslaunch spot_driver driver.launch

My settings:
ROS: Melodic
Python: 2, 3.6, and 3.8 are installed
spot sdk: 2.3.5

I tried the solution in here orocos/orocos_kinematics_dynamics#115, but no luck.

Traceback (most recent call last):
File "/home/user1/src/catkin_ws/src/spot_ros/spot_driver/scripts/spot_ros", line 3, in
from spot_driver.spot_ros import SpotROS
File "/home/user1/src/catkin_ws/src/spot_ros/spot_driver/src/spot_driver/spot_ros.py", line 24, in
import tf2_geometry_msgs
File "/home/user1/src/catkin_ws/devel/lib/python3/dist-packages/tf2_geometry_msgs/init.py", line 34, in
exec(__fh.read())
File "", line 1, in
File "/home/user1/src/catkin_ws/src/geometry2/tf2_geometry_msgs/src/tf2_geometry_msgs/tf2_geometry_msgs.py", line 31, in
import PyKDL
ImportError: dynamic module does not define module export function (PyInit_PyKDL)
[spot/spot_ros-6] process has died [pid 14553, exit code 1, cmd /home/user1/src/catkin_ws/src/spot_ros/spot_driver/scripts/spot_ros joint_states:=/joint_states tf:=/tf __name:=spot_ros __log:=/home/user1/.ros/log/7a8bb8da-a67b-11ed-bc52-9cb6d06c21cf/spot-spot_ros-6.log].
log file: /home/user1/.ros/log/7a8bb8da-a67b-11ed-bc52-9cb6d06c21cf/spot-spot_ros-6*.log

Thank you.

When using spot_driver to operate spot is it working great to start with. But after running the spot_driver for a while will spot refuse to move. It clearly receives movement commands, it attempts to move but stops mid-motion and return.

Have anyone had the same issue? Any idea of how to slow it?

Best regards!

We're hitting an issue where after about 5 minutes, Spot starts jittering/stumbling and eventually refuses to move. The velocity messages are making it to the driver, but it appears that the clocks are getting out of sync, and I progressively get more and more "ExpiredError" failures, until eventually every message is rejected. Restarting the driver script fixes the issue for another 5 minutes. Is there more info on how the clock-sync works, and why we might be hitting this?
Running ROS Noetic on Windows 11 WSL2 - connected/controlling via Wifi.

The error:
(ExpiredError): The command was received after its max_duration had already passed.

Hi,

Are you guys working on integrating the spot cam with your driver?

If not, we could do the work and then submit a pull request.

Cheers,

Ben
Createc

Hi,
I am using ROS Melodic on Ubuntu 18.04 for NVIDIA Jetson Xavier AGX.

when I start:

roslaunch spot_driver driver.launch

i get import import PyKDL error.

Traceback (most recent call last):
  File "/home/spot/catkin_ws/src/spot_ros/spot_driver/scripts/spot_ros", line 3, in <module>
    from spot_driver.spot_ros import SpotROS
  File "/home/spot/catkin_ws/src/spot_ros/spot_driver/src/spot_driver/spot_ros.py", line 23, in <module>
    import tf2_geometry_msgs
  File "/home/spot/catkin_ws/devel/lib/python3/dist-packages/tf2_geometry_msgs/__init__.py", line 34, in <module>
    exec(__fh.read())
  File "<string>", line 1, in <module>
  File "/home/spot/catkin_ws/src/geometry2/tf2_geometry_msgs/src/tf2_geometry_msgs/tf2_geometry_msgs.py", line 31, in <module>
    import PyKDL
ImportError: dynamic module does not define module export function (PyInit_PyKDL)

In the screenshot below,

The robot is sitting on a dock, but the height difference between the odom frame and the body frame is too much.
I have tried restarting the driver, and the height difference would vary (there are times when the height seems to be reasonable, but it is very rare). What could be the reason?

Currently the driver is two massive classes with various functions, and it's not clear how different components relate to each other (if at all). I think it would be a good idea to see if it would work to break interactions out into their own classes, potentially as subclasses of some base abstract class which provides some universally required objects (e.g. the robot connection).

There might be potential benefit in this of being able to run these components in their own thread and thereby increasing the potential data throughput of odometry and other messages, which right now feels like it might be bottlenecked by having a single main loop.

As the description says, the build instructions suggest to use catkin_make when using the python3 workaround for ROS Melodic. I think that in general, using catkin build is preferred over catkin_make so maybe that section could suggest to e.g. add the additional CMake arguments to a caktin config profile using catkin config --cmake-args ...

I was following the setup tutorial and when running roslaunch spot_driver driver.launch

I'm getting this error:
ImportError: cannot import name 'SpotWrapper' from 'spot_wrapper' (/home/baldash/Documents/ros/catkin_spot/devel/lib/spot_driver/spot_wrapper.py)

I was trying to run spot ros using ros noetic, maybe is this the issue ?

The release notes for 3.1.0 (https://dev.bostondynamics.com/docs/release_notes) have changes to the default behaviour of safe power off commands when they happen on stairs.

To summarise, when the power off or gentle stop commands are used on stairs in 3.1.0, the robot will move to the top or bottom of the stairs before actually powering off. Using the hard motor cut will not have this behaviour.

To improve safety when operating on stairs, the robot may now autonomously walk off staircases in scenarios where it may have previously entered a sit. In the event of communication loss, critically low battery state of charge, or a Safe Power Off Request, the robot will walk off the staircase before sitting and powering off. The direction of travel will generally be to descend the stairs unless the robot has already reached the top landing. This includes automatic sit-and-power-off cases such as from low battery or the E-stop SETTLE_THEN_CUT level, as well as any client SafePowerOff commands. It does not affect immediate power cut cases such the PowerOff command or the E-stop CUT level.
To override this behavior for SafePowerOff commands, there is a new unsafe_action field in SafePowerOffCommand which can be set to UNSAFE_FORCE_COMMAND to force the command to take place immediately. To override this behavior for E-stop or battery power off, set the disable_stair_error_auto_descent field in the mobility params for the robot commands. As part of this change, a new TerrainState message in RobotState contains the is_unsafe_to_sit value to report when the robot considers the terrain unsafe to sit on.

Currently the implementation in spot wrapper looks like

https://github.com/clearpathrobotics/spot_ros/blob/a09e6add6b0ed192ffd60b19c64055d08505d96d/spot_driver/src/spot_driver/spot_wrapper.py#L526-L529

Which means that the safe mode will always be active. I feel like this is a safe default, but if there is any desire to use the unsafe behaviour we will have to make changes to that function.

I observed that the /spot/cmd_vel topic behaves super weird on the newest spot sdk. Spot would start to move slightly, stop, continue etc.
Increasing the command duration from the current 125ms to 400ms mitigates the problem (but it's still not completely gone). After downgrading spot to an older version, the problem is gone and the current cmd_vel implementation works fine. Note: the problem is not the version of the python pip package, but the actual spot version.

I don't currently know which versions our spots have exactly, but I'll figure that out and update this issue.

I have a node which does a three-stage trajectory, turning, walking, and then turning.

I would occasionally observe that these calls in succession would sometimes result in the robot just not doing anything for however long the duration of the trajectory command I sent was. After some debugging, I noticed that the following section does not check if the trajectory command has unknown status.

https://github.com/clearpathrobotics/spot_ros/blob/8e1554b95cf2875a53f14fda8165957559b0ffb7/spot_driver/src/spot_driver/spot_wrapper.py#L179-L197

I verified that each time I noticed this stall in the trajectory command, the else part of the if statement was being entered. It looks like something is not quite right when sending the goal, but we do not handle this failed case.

I added some sleeps to my three stage command, between the calls to the trajectory actionserver. This seems to have eliminated the problem.

I tested sending commands while a trajectory was still running, and did not notice any problems, so it seems like it might be something to do with a command finishing and sending one right afterwards.

I don't know what the best solution for this is - it's possible that a short (0.5s or less) wait in the method which sends trajectory goals to the wrapper would be sufficient to fix this, and would be transparent to the user, except that if you wanted to interrupt one command with another there would be a short delay.

Hi,

First of all thank you for providing this driver.

I was wondering if you are planning to release the code needed for simulation. It seems that the code exist for use on AWS. It would be very beneficial for testing.

Even if it was just a docker container that would behave as a virtual spot

Best Regards.

Mart

Is there a way to obtain the URDF for arm and gripper? Also, obtain images from the gripper's camera? using the spot_ros stack?

The tutorial that is at http://www.clearpathrobotics.com/assets/guides/melodic/spot-ros/ is very useful for anyone starting off with the package. However, it's not in this repository so if we make changes or add new features we can't edit the tutorial/documentation so that people know it exists.

Would it be possible to add that documentation into this repository somehow?

Hi,
First of all thank you for providing this driver.
I am having a issue that when i use the command
pip3 install bosdyn-client bosdyn-mission bosdyn-api bosdyn-core
it will occur an error that "protobuf requires Python '>=3.7' but the running Python is 3.6.9" .
So do you have some suggestion to handle this issue ? Thank you again,i have thought many ways to solve this problem ,but id
did not works .

Hello 👋
thank you for open sourcing this ros wrapper!

I'll be working with spot the next few months and will need to command trajectories. As far as I have seen, this ros wrapper does not yet support the trajectory_command as in this example from Boston Dynamics.
Are you planning on adding this feature? If not, are you interested in PRs, which add this functionality?

Best regards,
Eric

I am having an issue importing tf2_ros in the latest version of the driver. I am running ROS Melodic and I think the issue is tf2_ros is complied for Python 2 which is the default in Melodic.

  File "/home/.../spot_ros/spot_driver/scripts/spot_ros", line 3, in <module>
    from spot_driver.spot_ros import SpotROS
  File "/home/.../spot_ros/spot_driver/src/spot_driver/spot_ros.py", line 19, in <module>
    import tf2_ros
  File "/opt/ros/melodic/lib/python2.7/dist-packages/tf2_ros/__init__.py", line 38, in <module>
    from tf2_py import *
  File "/opt/ros/melodic/lib/python2.7/dist-packages/tf2_py/__init__.py", line 38, in <module>
    from ._tf2 import *
ImportError: dynamic module does not define module export function (PyInit__tf2)

I can try to recompile tf2_ros for Python 3 but that breaks other packages. Is there a recommended procedure for installing a Python 3 version of tf2_ros for only this driver? Otherwise, has support for this driver moved to ROS Noetic which defaults to Python 3?

and similar are present in the camera driver part. The only little-endian thing is the 16UC1 depth image (which is correct as protobufs are always little).

Is there some reason for the single-byte values to be marked as big endian? If I understand it correctly, this has nothing to do with BGR/RGB as that is one level higher than endianness...

I have the Spot connected to our lab's WiFi network with the ROS driver running in a Docker container, but the publisher for all camera topics is only publishing at about 2 Hz. This is much lower than when I use the Spot Python SDK to retrieve the camera feed with the same setup, indicating that it's not a network bandwidth issue. Using the SDK isn't really an option for me, since I need a subscriber written in C# for Unity.

Could this be an error in the setup, or is this publishing rate for camera topics expected?

Our lab has recently moved to ubuntu 20.04/ROS noetic so I'm trying to set up our spot payload with that.

With the package set up as it currently is, I was unable to run spot_ros, due to various issues, some of which I have fixed in #29, which I did not encounter when we were still using melodic.

With those fixes I was still not able to run it, getting this error, or similar:

Traceback (most recent call last):
  File "/home/spot/spot_ws/devel/lib/spot_driver/spot_ros.py", line 15, in <module>
    exec(compile(fh.read(), python_script, 'exec'), context)
  File "/home/spot/spot_ws/src/spot_ros/spot_driver/scripts/spot_ros.py", line 33, in <module>
    from spot_wrapper import SpotWrapper
ImportError: cannot import name 'SpotWrapper' from 'spot_wrapper' (/home/spot/spot_ws/devel/.private/spot_driver/lib/spot_driver/spot_wrapper.py)

To me this seemed to be related to the set up of the python package, so I went ahead and created a branch which includes a modified package structure which works on noetic and which I believe is closer to the usual ros python package structure. You can find it at https://github.com/ori-drs/spot_ros/tree/python-package-structure-noetic.

Can anyone else share their experience of using this repository on noetic/focal?

Hi, I have a question.
Does this package compatible with BostonDynamics's new API version 2.1.0?

Recent merges have added quite a few services to the driver, which should be exposed in the rviz panel.

• Roll over commands
• Arm commands
• Dock commands

These might need their own tab, particularly the arm stuff, since I think there are quite a few things there. The other two might be added to the main panel if there's space. But maybe better to have them in their own tab.

Hi,

Can you clarify the setup instructions for a spot core and velodyne lidar? i.e the EAP.

I've tried the suggested network configuration, trying to connect directly to 192.168.1.201 and following the instructions on the velodyne ros page - no luck on all front unfortunatly.

I'm going to reflash the stock image to the EAP and try again, but some clarity would be really helpful. Thanks!

Hey guys,

I had several issues using the /spot/navigation_to action. Did someone use it successfully? First of all, the upload of the graph_nav takes a lot of time, roughly 7s per waypoint, while on the sdk the whole upload takes few seconds. Anyway, the action always stops due to some errors in the code, and even though I fixed some of those errors (I can make a PR with my corrections so far), new ones are coming up. The last one, after the initial fiducial was successfully detected:

[ERROR] [1643984336.793953]: Exception in your execute callback: not all arguments converted during string formatting
Traceback (most recent call last):
File "/opt/ros/melodic/lib/python2.7/dist-packages/actionlib/simple_action_server.py", line 289, in executeLoop
self.execute_callback(goal)
File "/home/spot/catkin_ws/src/spot_ros/spot_driver/src/spot_driver/spot_ros.py", line 443, in handle_navigate_to
initial_localization_waypoint = msg.initial_localization_waypoint)
File "/home/spot/catkin_ws/src/spot_ros/spot_driver/src/spot_driver/spot_wrapper.py", line 671, in navigate_to
self._list_graph_waypoint_and_edge_ids()
File "/home/spot/catkin_ws/src/spot_ros/spot_driver/src/spot_driver/spot_wrapper.py", line 738, in _list_graph_waypoint_and_edge_ids
graph, localization_id, self._logger)
File "/home/spot/catkin_ws/src/spot_ros/spot_driver/src/spot_driver/graph_nav_util.py", line 109, in update_waypoints_and_edges
edge.id.to_waypoint)
File "/usr/lib/python3.6/logging/init.py", line 1308, in info
self._log(INFO, msg, args, **kwargs)
File "/usr/lib/python3.6/logging/init.py", line 1444, in _log
self.handle(record)
File "/usr/lib/python3.6/logging/init.py", line 1454, in handle
self.callHandlers(record)
File "/usr/lib/python3.6/logging/init.py", line 1516, in callHandlers
hdlr.handle(record)
File "/usr/lib/python3.6/logging/init.py", line 865, in handle
self.emit(record)
File "/opt/ros/melodic/lib/python2.7/dist-packages/rosgraph/roslogging.py", line 245, in emit
record_message = _defaultFormatter.format(record)
File "/usr/lib/python3.6/logging/init.py", line 577, in format
record.message = record.getMessage()
File "/usr/lib/python3.6/logging/init.py", line 338, in getMessage
msg = msg % self.args
TypeError: not all arguments converted during string formatting

This looks strange because it should be a copy and paste of the sdk example of graph_nav, so what could be wrong? Thanks for helping!