# Magni safety function **URL:** \ **Category:** General Questions\ **Created:** [January 25, 2021, 7:04pm UTC](https://forum.ubiquityrobotics.com/t/magni-safety-function/713 "2021-01-25T19:04:02Z")\ **Posts on this page:** 16\ **Page:** 1
**Author:** ![EdSeymore](https://forum.ubiquityrobotics.com/letter_avatar_proxy/v4/letter/e/ecb155/32.png) [@EdSeymore](https://forum.ubiquityrobotics.com/u/EdSeymore)\ **Post date:** [January 25, 2021, 7:04pm UTC](https://forum.ubiquityrobotics.com/t/magni-safety-function/713/1 "2021-01-25T19:04:02Z")
Has anyone built or implemented a ROS Safety package to prevent Magni from making contact with obstacles in the path of movement? ---
**Author:** ![MoffKalast](https://forum.ubiquityrobotics.com/user_avatar/forum.ubiquityrobotics.com/moffkalast/32/214_2.png) [@MoffKalast](https://forum.ubiquityrobotics.com/u/MoffKalast)\ **Post date:** [January 25, 2021, 8:52pm UTC](https://forum.ubiquityrobotics.com/t/magni-safety-function/713/2 "2021-01-25T20:52:04Z")
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. ---
**Author:** ![EdSeymore](https://forum.ubiquityrobotics.com/letter_avatar_proxy/v4/letter/e/ecb155/32.png) [@EdSeymore](https://forum.ubiquityrobotics.com/u/EdSeymore)\ **Post date:** [January 26, 2021, 5:19pm UTC](https://forum.ubiquityrobotics.com/t/magni-safety-function/713/3 "2021-01-26T17:19:57Z")
> [@MoffKalast](#): > > move\_basic 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? ---
**Author:** ![MoffKalast](https://forum.ubiquityrobotics.com/user_avatar/forum.ubiquityrobotics.com/moffkalast/32/214_2.png) [@MoffKalast](https://forum.ubiquityrobotics.com/u/MoffKalast)\ **Post date:** [January 26, 2021, 8:36pm UTC](https://forum.ubiquityrobotics.com/t/magni-safety-function/713/4 "2021-01-26T20:36:05Z")
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/](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. ---
**Author:** ![EdSeymore](https://forum.ubiquityrobotics.com/letter_avatar_proxy/v4/letter/e/ecb155/32.png) [@EdSeymore](https://forum.ubiquityrobotics.com/u/EdSeymore)\ **Post date:** [January 26, 2021, 9:38pm UTC](https://forum.ubiquityrobotics.com/t/magni-safety-function/713/5 "2021-01-26T21:38:10Z")
> [@MoffKalast](#): > > unconditionally 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. ---
**Author:** ![mjstn2011](https://forum.ubiquityrobotics.com/user_avatar/forum.ubiquityrobotics.com/mjstn2011/32/30_2.png) [@mjstn2011](https://forum.ubiquityrobotics.com/u/mjstn2011)\ **Post date:** [February 13, 2021, 10:33am UTC](https://forum.ubiquityrobotics.com/t/magni-safety-function/713/6 "2021-02-13T10:33:22Z")
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 ---
**Author:** ![EdSeymore](https://forum.ubiquityrobotics.com/letter_avatar_proxy/v4/letter/e/ecb155/32.png) [@EdSeymore](https://forum.ubiquityrobotics.com/u/EdSeymore)\ **Post date:** [February 14, 2021, 4:52pm UTC](https://forum.ubiquityrobotics.com/t/magni-safety-function/713/7 "2021-02-14T16:52:10Z")
> [@mjstn2011](#): > > stop when we approach something 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? ---
**Author:** ![mjstn2011](https://forum.ubiquityrobotics.com/user_avatar/forum.ubiquityrobotics.com/mjstn2011/32/30_2.png) [@mjstn2011](https://forum.ubiquityrobotics.com/u/mjstn2011)\ **Post date:** [February 15, 2021, 1:27am UTC](https://forum.ubiquityrobotics.com/t/magni-safety-function/713/8 "2021-02-15T01:27:51Z")
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](https://github.com/UbiquityRobotics/ubiquity_motor) ---
**Author:** ![EdSeymore](https://forum.ubiquityrobotics.com/letter_avatar_proxy/v4/letter/e/ecb155/32.png) [@EdSeymore](https://forum.ubiquityrobotics.com/u/EdSeymore)\ **Post date:** [February 15, 2021, 6:22pm UTC](https://forum.ubiquityrobotics.com/t/magni-safety-function/713/9 "2021-02-15T18:22:36Z")
> [@mjstn2011](#): > > ubiquity\_motor node listens to topic /cmd\_vel for velocity commands. 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. ---
**Author:** ![mjstn2011](https://forum.ubiquityrobotics.com/user_avatar/forum.ubiquityrobotics.com/mjstn2011/32/30_2.png) [@mjstn2011](https://forum.ubiquityrobotics.com/u/mjstn2011)\ **Post date:** [February 16, 2021, 2:08am UTC](https://forum.ubiquityrobotics.com/t/magni-safety-function/713/10 "2021-02-16T02:08:27Z")
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](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. ---
**Author:** ![mjstn2011](https://forum.ubiquityrobotics.com/user_avatar/forum.ubiquityrobotics.com/mjstn2011/32/30_2.png) [@mjstn2011](https://forum.ubiquityrobotics.com/u/mjstn2011)\ **Post date:** [February 18, 2021, 6:35am UTC](https://forum.ubiquityrobotics.com/t/magni-safety-function/713/12 "2021-02-18T06:35:25Z")
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 ---
**Author:** ![EdSeymore](https://forum.ubiquityrobotics.com/letter_avatar_proxy/v4/letter/e/ecb155/32.png) [@EdSeymore](https://forum.ubiquityrobotics.com/u/EdSeymore)\ **Post date:** [February 18, 2021, 4:03pm UTC](https://forum.ubiquityrobotics.com/t/magni-safety-function/713/13 "2021-02-18T16:03:51Z")
> [@mjstn2011](#): > > /system\_control 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](https://github.com/EdSeymore/ets_pkg01.git) for my testing process and code. Magni still runs into obstacles. Thoughts? ---
**Author:** ![mjstn2011](https://forum.ubiquityrobotics.com/user_avatar/forum.ubiquityrobotics.com/mjstn2011/32/30_2.png) [@mjstn2011](https://forum.ubiquityrobotics.com/u/mjstn2011)\ **Post date:** [February 19, 2021, 1:18am UTC](https://forum.ubiquityrobotics.com/t/magni-safety-function/713/14 "2021-02-19T01:18:54Z")
I will be looking at this over the weekend. Thanks for feedback. ---
**Author:** ![mjstn2011](https://forum.ubiquityrobotics.com/user_avatar/forum.ubiquityrobotics.com/mjstn2011/32/30_2.png) [@mjstn2011](https://forum.ubiquityrobotics.com/u/mjstn2011)\ **Post date:** [February 19, 2021, 9:35am UTC](https://forum.ubiquityrobotics.com/t/magni-safety-function/713/15 "2021-02-19T09:35:47Z")
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](mailto:support@ubiquityrobotics.com) and in the subject line say something like this: ATTN Mark - sonar collision detector node ---
**Author:** ![EdSeymore](https://forum.ubiquityrobotics.com/letter_avatar_proxy/v4/letter/e/ecb155/32.png) [@EdSeymore](https://forum.ubiquityrobotics.com/u/EdSeymore)\ **Post date:** [February 23, 2021, 5:05pm UTC](https://forum.ubiquityrobotics.com/t/magni-safety-function/713/16 "2021-02-23T17:05:29Z")
> [@mjstn2011](#): > > /system\_control 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. ---
**Author:** ![mjstn2011](https://forum.ubiquityrobotics.com/user_avatar/forum.ubiquityrobotics.com/mjstn2011/32/30_2.png) [@mjstn2011](https://forum.ubiquityrobotics.com/u/mjstn2011)\ **Post date:** [March 2, 2021, 9:24am UTC](https://forum.ubiquityrobotics.com/t/magni-safety-function/713/17 "2021-03-02T09:24:50Z")
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](https://github.com/mjstn/sonar_detector) You no longer need a branch of our ubiquity\_motor repository as the README shows now. Enjoy! Mark