Has anyone built or implemented a ROS Safety package to prevent Magni from making contact with obstacles in the path of movement?
Well if youāre using move_basic to issue goals to the robot and have a sonar board or lidar installed the robot will watch out for obstacles and stop if it detects any. Itās generally designed to stop itself from running into people so it just stands there until the obstacle clears.
1 Like
In that case, why does Magni run into obstacle if using the basic tutorial functions of:
rosrun teleop_twist_keyboard teleop_twist_keyboard.py or
roslaunch magni_teleop logitech.launch >/dev/null 2>&1 &
if the sonar shows active?
Well thatās using plain old command velocity that tells to robot to go where you want it to go unconditionally (i.e. ubiquity_motor directly). To move it with move_basic youāll have to set a goal in 3D space and the robot does the rest.
I think there is a tutorial on that if you look at the https://learn.ubiquityrobotics.com/ documentation. Youāll have to open rviz on a workstation and send the goal through it.
Edit: Looking at the doc, I think the section in lidar navigation āDefine A Target Pose As A Navigation Goalā is the one you need. Now if you donāt have a lidar the robot will still navigate the same way with wheel odometry by default.
1 Like
MoffKalast, Thanks for the information. I have not yet studied ROS or carefully studied the learn documents.
But, that takes me back to the original question. Magni is a very powerful vehicle and I believe that a ROS Safety package is needed to ensure that the vehicle does not make contact with obstacles no matter which package is being use to control the device.
Just seeing this now. In navigation packages using ROS the layer that does the navigation and path planning includes a concept called the ācostmapā. That is the collision avoidance layer in a popular nav path planning piece called āmove_baseā. We have a simpler package that uses a simple front sonar āstop when we approach somethingā sort of logic. That stop piece is built into what we call āmove_basicā. We call it āmove_basicā because it is a greatly simplified path planner that only deals with point to point but it does have the ability to stop on an object in the front of the robot.
ROS is a set of interfaces that allows different processes (ROS Nodes) to pass messages between each other. ROS itself is in fact not really an āOperating Systemā but more of an advanced toolkit. ROS is gaining momentum every year and is at this time widely used in a great many robots. We are happy to be involved in supporting open source packages and nodes for use in ROS systems.
So because ROS is a collection of tools it does not actually define any particular full system. Assorted companies define those systems and collision avoidance is a system issue because only the system can know what is expected of the robot and what is a fault that will lead to collision.
To outguess this it would be a good thing to have some ROS node that looks for āvery likely colisionsā and then alerts other nodes on a well known ROS topic. So lets say there were a node to do this and it defines a set of ROS messages (there is a way to define and import messages and listen to defined topics). So in that way such a node would be of value and your thoughts are good.
We ourselves have not defined such a standalone node to publish to some well defined ROS topic with a name lets say of /colision_events or something.
Thanks for the ideas, its a good idea.
Mark
1 Like
Should this function be enabled when Magni comes up for joystick or keyboard operation?
In My case it does not seem to be working. My Magni will run over obstacles.
Is the source for ubiquity_motor available and does it have stop function which can listen for a ROS Stop_Front message from a safety ROS Node?
The ubiquity_motor node listens to topic /cmd_vel for velocity commands.
It would be the layer above that that sends /cmd_vel commands that would implement the stop capability. In our case that is either user code or our move_basic.
Besides stop on sonar detection we have two connectors that can be used for a node to read in bumper switches. Bumper switches are of course often too late but could be used for ācat wiskerā sort of switches as well.
We are developing systems now that are higher level than the raw movement sort of things available with ubiqiity_motor.
The problem that comes up is that a great many users will use the motor_node in ways we cannot outguess. This is why implementation of collision is basically always left to the logic that is above the raw motor node itself.
but in answer to your question our open source github does present full source code for our motor node in this repository. Also just above this url are a great many other repositories including move_basic
The motor node: https://github.com/UbiquityRobotics/ubiquity_motor
1 Like
Given that motor_node.cc listens for /cmd_vel, it seems that it should also listen for /safety_stop_forward to allow overriding the Joystick and keyboard /cmd_vel requests and prevent the user from hitting obstacles.
We simply write a new node to listen to sonar_3 and publish /safety_stop_forward if Magni approaches too close to obstacle.
Yes, that is a good idea. I am starting an issue on this topic and have fit this ability into a topic called /system_control which is used for high level control at the motor_node layer.
The definition will be that the topic /system_control is monitored
Sending the text of āspeed_control disableā will stop motor node by sending zero on /cmd_vel topic. Use of āspeed_control enableā will re-allow cmd_vel to be issued to motor lower level driver. Here is how that can be done from command line for tests:
rostopic pub /system_control std_msgs/String āspeed_control disableā
(after this is used a Control-C will get you back the command line)
Later use āspeed_control enableā.
To try this code as a ābeta testerā you are welcome do do these things:
cd ~/catkin_ws/src
git clone https://github.com/UbiquityRobotics/ubiquity_motor
cd ubiquity_motor (go into the local repository)
git checkout -b addSpeedControlForMotorNode
cd ~/catkin_ws (get back to the catkin_ws folder)
sudo systemctl stop magni-base (this is done to stop magni for make)
catkin_make (This is done from the catkin_ws folder)
sudo shutdown -r now (reboot the robot and you can try this new ability)
This will take some time to introduce into released code and so if you need it now you must do as shown above.
1 Like
I am too close to this stuff. I have edited the post.
You have to be in the folder of the repository for the checkout and then back out again for the catkin_make
1 Like
The new function installation seems to work fine.
Entering the enable and disable requests seemed to work fine. I monitored with rostopic echo /system_control.
But, Magni still moves after the disable is sent when using rosrun teleop_twist_keyboard teleop_twist_keyboard.py.
I will modify my robot_safety.py to issue the disable request.
Please see GitHub - EdSeymore/ets_pkg01: My first ROS package to examine the Magni robot for my testing process and code.
Magni still runs into obstacles.
Thoughts?
I will be looking at this over the weekend. Thanks for feedback.
I have written a node that does all this stuff using our sonars.
I donāt have a āhomeā for it yet on our repositories so I can zip you up a copy of what I have and you can play with it. You would unzip into catkin_ws/src and do a catkin_make and I would explain to you how to run the node. It fully works with the git branch I have for ubiquity motor.
So I donāt want to troubleshoot your issue but can just send you this code.
Send and email to support@ubiquityrobotics.com and in the subject line say something like this: ATTN Mark - sonar collision detector node
1 Like
Based upon further testing, The proposed implementation of rostopic pub /system_control std_msgs/String āspeed_control disableā does indeed work as designed. Once the topic /system_control shows active, motion can be toggled on and off with the suggested functions. My earlier testing must have not given Magni sufficient time to complete the initial setup to the point to having /system_control active prior to sending the new requests.
Writing a new ROS node to monitor sonar and issuing the disable and enable requests solves the immediate problem of Magni running into obstacles as desired in the original question. Thanks to mjstn2011 for this insight.
At this time I have also implemented ROS parameters as well as the ability to only back up so as to get out of a collision active state. We monitor the /sonars for the middle 4 facing front sonars and we also monitor /cmd_vel topic to allow backing up. This is very different than initial proto code in that this now uses Cpp SonarDetector class instead of straight C code.
This is on my own github but I hope to find a home for it within the Ubiquity Robotics github soon.
It is at this time here: https://github.com/mjstn/sonar_detector
You no longer need a branch of our ubiquity_motor repository as the README shows now.
Enjoy!
Mark
1 Like