Using ROS with robot software version 2.7 #45
Comments
FabianPG11
changed the title
|
Hello, We contacted MIR for this issue. The problem is that the message type for /cmd_vel should be TwistStamped in stead of Twist on line 208 in mir_driver/nodes/mir_bridge.py . Not sure if this changed in the MIR software (only tested with latest version), but this solved the problem for us, on a MIR 500, and I assume it will solve it on a MIR100/200 too. |
|
Thanks for the reply. We have tested it on MiR100 running robot software version 2.7 and it worked. |
|
Thanks. I am looking to measure the deceleration of a MiR 100 robot in an emergency stop (e-stop) situation. I am running software v 2.8.1 but can roll back to v2.8.0 if commanded velocities don’t t move the robot.
My understanding is that from the command line, this would translate to (would appreciate if someone could validate the command) : Would welcome any other ideas to force an e-stop ! Thanks as always! |
Hi all, I was troubleshooting my problem and had a few updates. The result is setill the same (Nothing happens after commanding velocities through /cmd_vel topic.)
I'd appreciate any troubleshooting suggestions! Thanks! |
|
You're not publishing a TwistStamped message in the correct way. Try this: rostopic pub -r 5 /cmd_vel geometry_msgs/TwistStamped "{header: auto, twist:{linear:{x: 1, y: 0, z: 0}, angular:{x: 0, y: 0, z: 0}}}" |
|
Hey, Thanks. |
|
Thanks a lot @kurtgeebelen - It worked from the command line! Is the change in mir_bridge.py the only change needed in the entire code base? Based on my limited understanding of ROS, I suspect there are other files (such as catkin_ws/src/mir_robot/mir_msgs/msg/ExternalRobot.msg) that will need to be modified, because the Twist message has a different structure from TwistStamped. At a high level, I am trying to do this: I was able to do this using the Twist message in earlier versions of the MiR software. |
|
Hi I am also using MIR software version 2.8 and managed to move it using topic /cmd_vel by changing the msg type as described above. I am having the same issue with the topic /move_base and relative_move_action. Anyone who has used this, kindly comment on this. Thank you |
|
Hi all, we had the same issue in trying to send a goal (x,y,orientation) to the MIR, and it didn't react or when it did react it didn't navigate to the correct position. We are now using the rest API to have it navigate to a desired posiiton. The position can then also be send from a script. Below is an example python script that we use for this. In the MIR itself you have to create position and a mission to drive to this position. The coordinates of this position are thus changed by this script (set_position) import requests
import json
import time
import sys
# MIR settings
mir_ip_address = "192.168.50.123"
#generating the authorization key see restapi documentation
mir_authorization_Distributor = "your authorization code"
mir_headers = {
"accept": "application/json",
"Accept-Language": "en_US",
"content-type": "application/json",
"Authorization": mir_authorization_Distributor,
}
# ----------------------------------- Get MIR State ---------------------------------------#
# retrieve the state number
def get_robot_state():
# Request the status
response = requests.get(mir_url + "status", headers=mir_headers)
# Take out the state number from the code
code = response.json()
#state = code['state_id']
# Return the state number
return code
# ----------------------------------- Send MIR position --------------------------------------#
# start mission to specific location
# retrieve mission_id via output from get missions command
def set_position(GUID, x, y , orientation):
data = {"pos_x": x, "pos_y": y, "orientation": orientation}
# Send mission to mir
response = requests.put(mir_url + "positions/"+GUID, headers=mir_headers, data=json.dumps(data))
return response.json()
# ----------------------------------- Send MIR on mission --------------------------------------#
# start mission to specific location
# retrieve mission_id via output from get missions command
def set_mission(GUID):
data = {"mission_id": GUID}
# write to log
print("mir send on mission: " + GUID)
# Send mission to mir
response = requests.post(mir_url + "mission_queue", headers=mir_headers, data=json.dumps(data))
return response.json()
if __name__ == "__main__":
set_position("your guid", 5.0, 2.75 , 153)
set_mission("your guid") |
Hi Kurt, Thank you |
|
I don't have MiR Software 2.8 for testing. The latest I have is MiR software 2.6.0. From what I can tell, there are two main problems with using this driver for versions > 2.3.1:
I have just pushed a new branch melodic-2.8 where I'm attempting to fix these two things. The general idea behind the fixes is that the
Based on the discussion in this issue, I'm relatively confident that 27652fa fixes the first problem (cmd_vel). The commit 47c6aeb is my attempt at fixing the second issue (move_base). If you look at the commit, you'll see that lots of fields were added to the 47c6aeb#diff-f84e16efd5bf3d46b6e08d6c36495fdcR3-R8 ... so I'm setting it to 47c6aeb#diff-5fb6d7d4a121556dac4973fa51f0c2b2R38 Since I don't have access to the real robot (or MiR software 2.8) at the moment, I could not test these changes. So there is a significant chance that they won't work yet, but they should give you a starting point. @BenziF @FaseehCS @FabianPG11 @rsr152 @kurtgeebelen : If you have the time, please test the branch |
|
Hi mintar, thank you very much for your quick reply. Due to COVID, we have limited access to our facilities, but next Tuesday I should be able to go and test the new branch of the code on our real robot (MiR software 2.8). As a quick followup question, is there a way to synchronize the internal PC of the MiR from Ubuntu's command line? I did it using the web interface, but i need to press two buttons in it, one to get the time of my device and another one to save the info and setting it to the robot's internal system. As a result, when I run Anyway, I'll report back to you next Tuesday, and thanks again |
Not really. I have a working solution, but it's not very easy to install: We have an external PC integrated into our robot that is on the same wired network as the MiR PC; let's call it If you're wondering how you can install stuff on the internal MiR PC:
Or you do what I did and build your own MiR update image that installs chrony. But that's not easier than the previous way. :) Alternatively, maybe there's a way to set the clock using the REST API, but I haven't looked into that.
It would be better if you could get it down to around 0.1 seconds, but that's not really easy using the manual method. I have only ever used the old interface, where they had only one button for setting the time.
Probably because in the "standard use case" for the MiR (i.e., not using ROS), it doesn't matter if the clocks are not in sync. But I agree, this is a major PITA for our use case. |
|
@FaseehCS and me tested the branch with our MIR. cmd_vel worked after applying the change in #56. One time it also happened that the "planner" module on MIR dies "unexpectedly" and the button in the web interface went into the grey state after sending a goal from RViz. As of now we can only recover from that by rebooting. When starting the MIR bridge we also stumbled upon #57. Another change that was necessary is in #58: MIR uses tf2. |
|
Thanks for testing this and providing the pull requests! I've merged #56 and #57. I have my doubts about #58, but I'll post them over there. Now that we know that this works, we'll have to think about how to merge it into the main Before merging, we'll need some mechanism like the following:
If any of you want to do that work and provide a pull request, that would be great! Otherwise it'll have to wait until I find the time. |
|
Hi @mintar and everyone, yesterday i was able to test the robot (version 2.8) using the new melodic-2-8 branch but sadly still nothing works. I tested posting to If it's my fault and I'm not launching the correct files, then my bad and I kindly as you to correct me. If instead you can ensure me that the problem lies in the synch, I'll find a way out. Thanks for everything btw :) |
|
Thanks for testing and providing feedback! While 0.35 s time lag may cause some more subtle problems, I don't think that's the problem here. As long as the lag is below 10 s, the robot should at least move. I have just merged #58 today. If I understand @matthias-mayr correctly, it's necessary to avoid the transform errors. So please pull the melodic-2.8 branch and try again. Another thing that looks suspicious is the "topic 'move_base/feedback' is not published by the MiR!" warnings. Did you start the "planner" component in the MiR web interface? |
|
Thank you for all the support! Okay, I suspected it too, given the large timeout value, but still wasn't 100% sure. Perfect, I'll try it next Tuesday! Sorry about the slow updates, but we still have limited access to the facilities.
I went through most of the web interface and didn't find anything which resembled the "Service" -> "Configuration" -> "Launch menu" cited in the README, so I simply exported the master with Also, quick followup question, do I need to push the Play button from the web interface? I tried both ways yesterday, as paused ( yellow LEDs) and active state (green LEDs) but still achieved nothing |
|
The layout of the web interface has changed. You can find it in "System --> Processes --> planner". Although in our understanding it should have responded to the But #58 should be the reason why your transformations could not be resolved and therefore mapping on the ROS side should not work. |
Finally, thanks you, I don't know how I missed it. Now I can be 100% sure
All I did was launching |
|
I'm never in the green mode ("mission") when publishing goals from ROS, always either blue ("manual active") or yellow ("manual inactive"). Also remember that you must not do Still, to check whether |
Okay all clear, thank you very much for the confirmation. As a last question, does the procedure described in the README for the case of Gazebo (mapping) also works with the real robot? Namely, if I launch |
|
I have another question that might be related to the new software version. When connecting to the MIR I get to quite fast, but then there is an ~20s delay until it progresses with Is this always the case or could it be due to some changes? |
|
No, that's normal. It takes quite some time to get all the publishers and subscribers. I didn't debug where exactly the time lag occurs, but I guess it's all the back-and-forth of adding publishers and subscribers one by one via the websockets interface. |
|
I just started working on the MiR in the lab with the melodic-2.8 branch. I managed to connect and sync the robot with a 0.2s delay, but when I try to send goals to the MiR with |
|
I'm still a bit confused which MiR versions now work and which don't. @MartinJensen37 is running MiR software 2.8.3, and move_base isn't working (but cmd_vel is). @BenziF @matthias-mayr @rsr152 : Could you please post which MiR software version exactly you're using (e.g. 2.8.1) and if move_base works with the current melodic-2.8 branch? |
|
@MartinJensen37 : I suspect that something in the MirMoveBase action changed between MiR 2.8.* and 2.8.3.
Did you reduce the time delay between your PC and the MiR? Some steps that would help debugging:
|
Yes, I'm currently using the 2.8.3 and the |
I'll try and do this now. I'll report back with some screenshots and a status for the rosbag. |
As an aside: You can also just copy-paste text from the terminal, that's better than taking screenshots. |
|
This is going to be a bit long, but here is the output from the And then I have the |
Yes, the delay currently is 0.2s approx. instead of 20-30s. |
Great! Could you please upload the rosbag? |
Github doesn't allow me to upload the file in the comments, so maybe we can put it somewhere else? Where do you prefer? |
|
I don't care - Dropbox, Google Drive, Mega.nz... your choice. |
|
Here is a link for the .bag file then: https://drive.google.com/file/d/1qOQnfR9kd9vUqDBqvI4wAwpjtUgg9_OB/view?usp=sharing |
|
It isn't a public link, but I've requested access. |
Oh sorry, it should be accessible now. |
|
We are running version 2.8.0.3. I checked our repo and we have no further changes that should be relevant for this issue. |
|
@MartinJensen37 Thanks for the bagfile. There was indeed a small change in the MirMoveBaseAction between 2.4.0 and 2.8.3 (2e79d94), but I don't think that has anything to do with the problem. Can you try using an action client instead of the #!/usr/bin/env python
import rospy
from actionlib import SimpleActionClient, GoalStatus
from geometry_msgs.msg import PoseStamped
from move_base_msgs.msg import MoveBaseAction, MoveBaseGoal
def make_waypoints():
waypoints = []
p = PoseStamped()
p.header.frame_id = 'map'
p.pose.position.x = 41.39
p.pose.position.y = 24.24
p.pose.orientation.z = 0.7071067811865475 # sin(pi/4) (90 degrees yaw)
p.pose.orientation.w = 0.7071067811865475
waypoints.append(p)
p = PoseStamped()
p.header.frame_id = 'map'
p.pose.position.x = 39.49
p.pose.position.y = 24.37
p.pose.orientation.z = 1.0
p.pose.orientation.w = 0.0
waypoints.append(p)
return waypoints
def return_code_to_string(return_code):
if return_code == GoalStatus.SUCCEEDED:
return 'succeeded'
elif return_code == GoalStatus.PREEMPTED:
return 'preempted'
elif return_code == GoalStatus.ABORTED:
return 'aborted'
else:
return str(return_code)
def main():
rospy.init_node('drive_to_waypoints')
action_client = SimpleActionClient('move_base', MoveBaseAction)
if not action_client.wait_for_server(rospy.Duration(30)):
rospy.logerr('Timeout waiting for move_base action!')
return
rospy.loginfo('Connected to move_base action!')
while True:
for nr, waypoint in make_waypoints():
rospy.loginfo("move to pose {}".format(nr))
goal = MoveBaseGoal()
goal.target_pose = waypoint
ret = action_client.send_goal_and_wait(goal)
rospy.loginfo('move_base result: %s', return_code_to_string(ret))
if rospy.is_shutdown():
action_client.cancel_all_goals()
return
if __name__ == '__main__':
try:
main()
except rospy.ROSInterruptException:
passIf that doesn't solve it, can you do the following, while using the
|
|
Okay, I've tried the script and it gets stuck while giving the goal at Here is the link to the .bag file where I run the script:https://drive.google.com/file/d/12ZSH0Ehqz4u_4-b2gKRqfxcUwhuw75jQ/view?usp=sharing |
|
I just looked at the frames and it seems like a lot of them aren't present, I'm not sure why this is but here is the .pdf: |
|
What about the It's very strange that there are no The robot is doing some very strange things. It always ends up in the same pose that it started from and reports "Goal reached", but that's not actually the goal that you sent. The tf frames shouldn't have anything to do with the current problem (but they'll need adjustment, too). You could do the following to help:
|
|
Here is the And the info for the two topics:
I might've connected to the robot wrong yesterday since I cannot reproduce the movement and all the frames are there now. So I tried running your script again with no luck unfortunately. |
|
Hmm, that all looks normal. I don't think it's a problem with the MiR version, because the implementation of Perhaps the following helps. In all terminals, before starting any ROS nodes, run the following commands: export ROS_IP=<your wifi IP>
export ROS_MASTER_URI=http://<your wifi IP>:11311 |
|
Now I exported my IP while connected to the WiFi of the robot. I still get the message: When I run Rviz and give the first goal it doesn't come with the could not connect to |
|
I'm out of ideas, sorry. |
|
No problem, I'll try a bit more with some adjustments and I'll write if anything works. Thanks for all the help! |
|
I have just pushed a large update to the |
Dear all,
I have a question regarding the ROS integration with MiR100 running robot software versions of 2.7 and 2.8.
As already mentioned in the previous issues, the ROS wrapper available in this repository is not compatible with versions older than 2.3. I was wondering what causes the problem and whether there is a fix for it.
Currently, we run the driver and the robot gets connected successfully, however, nothing happens after commanding velocities through /cmd_vel topic.
I would highly appreciate any help.
The text was updated successfully, but these errors were encountered: