Hi,
I’ve got a robot with pi and ROS installed(kinetic).
the robot has a service which run ROS nodes and motor_node between them.
when I writing “rostopic info” I can see there is a topic named “/odom” and when Im checking with
“rostopic info odom” I can see that motor_node is the one who publish it.
I need to edit some stuff at the node but the robot contains only exe of motor_node so I’ve been told that I can download the code from git and compile it.
I’ve checked all the files in the git and there is no place the motor_node publish this topic!
no one publish this topic!
I even downloaded the source code and compile the motor_node and when I replaced it with the robot motor_node the odom topic dissapeard.
so my question is:
where is the code that publish the “odom” topic ???
I have to ask if you have an actual Magni with its main board or if you are doing your own robot? I will proceed with your answer that is only a good answer if you have the real Magni robot. You are certainly welcome to use our Image but all the stuff o /odom publication is highly specific to our board and our motor_node.
IF your robot is NOT a magni I first offer this page that is of value for our image:
Read on IF you have a real magni because this ONLY applies for a real Magni that has the main motor control board (MCB).
When in ~/catkin_ws/src you would run this command to clone our motor node:
git clone https://github.com/UbiquityRobotics/ubiquity_motor
After that the location of /odom stuff is in catkin_ws/src/ubiquity_motor/src/motor_hardware.cc
What you seek is ‘near’ line 300. It is HIGHLY specific to our main product, Magni.
I hope this helps,
Mark
I have a real magni robot.
and I already downloaded the git, and after reading your answer still, there is no odom publish.
no around line 300 and not at all.
there is no ros subscriber with the topic “odom” at motor_hardware or anywhere.
in lines 343-344 you got this:
leftError.publish(left);
rightError.publish(right);
and those only the error of left and right on a different topics
I need to ask another basic set of questions here.
To me I would now assume that you are not able to get your Magni to move at all, is that the case?
If unable to move at all then what you describe is the motor_node is not connecting to the MCB. If you have a rev 5.2 or rev 5.3 MCB (big board) tell me if you see both the SIN and SOUT leds blinking very fast after you have started the robot and waited lets say up to 5 minutes?
Tell me (perhaps again) what version of MCB you have on the robot.
We will proceed based on your answers.
This is our troubleshooting page on our ‘learn’ site:
The key points on this page are near the middle of the page:
- Power Supply And Status Quick Reference Table focus on blink, 5M and 12M leds.
- The Serial Communications Status LEDS
- Verify The MCB Is Recognized Over Serial port
- List item
I actually can drive this is not the problem.
Im trying to do some manipulation before sending the odom topic, thats it.
few of the manipulation contains sending encoders ticks in addition to odom and reduce some time.
I talk with the support on phone and they told the code of motor_node is on the git.
but it is not the same!!
the only thing I want to know is where is the source code corresponding to my robot.
If you also gonna say “on the git” and send me the same link so please, show me where is the /odom publish
You are then asking for exactly the same source. This is not something I know how to track down. It is ‘possible’ but really involved so I suggest getting known code. When you pull a repository and make the code one of the beauties of ROS is it ‘overlays’ that code and uses it next reboot.
This is why I think your easiest path is that you get your OWN ubiquity_motor node code and THEN you have the same code.
cd ~/catkin_ws/src
git clone https://github.com/UbiquityRobotics/ubiquity_motor
cd ~/catkin_ws
sudo systemctl stop magni-base (to avoid it taking FOREVER!)
catkin_make
after done, reboot.
You can then use the tips I gave to find /odom publication from our motor node and know it is the matching code.
I did exactly what you said.
I stopped the service of magni-base and compiled to git node.
so now both the “odom” topic and the “cmd_vel” topic dissapear.
it makes sense because the code at the git doesn’t subscribes/publishes them.
Now I am going to go into some specifics that you will likely not like at all.
The creators of our motor_node wanted to use some very low level code rather than directly pubish /odom. So here we go … hold onto your hats!
In our motor node we periodically update what is called the robot ‘joints’ which in this case means the wheel rotations.
Deep in the depths of some OTHER shared ROS code lies the stuff that takes our wheel geometries and rotation rates in rad/sec and keeps track of ‘wheel odom frame’. This I ‘think’ is what you are asking about basically.
So we instantiate this module as hardware_interface::JointStateHandle joint_state_handle How do do what YOU want to do will be really involved and require digging deep into the _joints stuff.
I personally HATE that layer and NEVER use it on my robots. I leep all my odom frame stuff easily viewable in my own code. We could argue the ‘religion’ of use of pre-existing ROS standards all day and who am I to ‘pass judgement’. Frankly I myself feel it is such a wild abstration that it is if near zero value and was only done because it seemed like the right thing to do at the time.
I myself really have not followed it into the depths. It is a ‘ROS’ sort of ‘standard’ but IMHO is nearly unsupportable by anybody but a ROS Guru (WHICH the guy who did it certainly is). I prefer supportable code that is able to be followed over the ‘beauty of object oriented abstractions’. Again, that is me, hey, I am by title the hardware guy so ‘what do I know’?
There you have it. Such is the case. It works but we do not mess with it.
I now see your reply. I have in a GREAT MANY cases overlaied the ubiquity_motor node and made it, the made numerous changes in a branch and pushed the branch to Pull requests then after review merged them into ‘kinetic_devel’.
So I am not sure what you ran into. It may be some recent change or other ‘real’ problem. I will have to let our ‘real software folk’ sort out if you cannot do a pull of the kinetic-devel branch on the Nov 2020 image.
One possibility is you ended up pulling our VERY recent noetic-devel branch in which case your image is all kinetic-devel but you pulled noetic-devel and yet, that would be totally likely to be a royal mess and not work. Recent changes in high level git may have made the ‘default’ branch of the ubiquity_robotics repository be noetic-devel BAD IN YOUR CASE!
So since I think you said you used the 11 2020 image then in your ubiquity_motor repository clone use ‘git status’ and see if you are in fact in noetic-devel. If so you need to do a ‘git checkout kinetic-devel’ and then re-make, perhaps with a ‘git pull’ for safety after the branch switch (not likely required but is good practice). This is quite likely your current issue.
OK, I think I cannot go further from here.
I asked my colleague to set support appointment.
I hope you can help me on the phone 