How to smooth jackal simulation movements

[jmledran]

Hi!

I’m working on a project and the first step is to have a simulation running with the Jackal robot using ROS Navigation Stack. I already have everything configured, but for some reason the Jackal robot is moving odd, like if I posted a rostopic pub with 1 HZ. It advances, then stops, then advances again, and so on. Why does it stops after each movement? Is it related to my simulation frequency? How can I smooth his movement?
Does this have to do with the simulation? With my computer resources?
I’ve tried moving it using twist markers, setting a goal in RViz and the movement is still paused.
Here’s my repo: GitHub - JuanMaLR/jackal_velodyne_vlp16_lidar_ros_nav_stack: Masters thesis project Tecnológico de Monterrey
And here’s a video where you can see the robot behaivour: Jackal movement demo - YouTube

[girishkumar.kannan]

Hi @jmledran ,

I think I know exactly what your problem is. I experienced the same issue with Husky robot in ROS Navigation in 5 Days course.

Here are the links to the solutions (both are from same issue, but both posts are equally important):

1. Husky robot not moving as it should - #3 by albertoezquerro
2. Husky robot not moving as it should - #4 by rzegers

Let me know if that fixes your problem!

Regards,
Girish

[jmledran]

Hi @girishkumar.kannan ,

Thanks a lot for your fast reply!

The dead-man switch and multiplexer are two very interesting topics that I am not familiar with. Do you know if there’s any course in the academy that explains this topics in depth?

And so, a new question arises. How can you modify the publish rate from move_base cmd_vel topic? So that it’s done in a way that doesn’t stop the Jackal. Or would it be recommended to latch that topic?
I tried changing the move_base controller_frequency param, but it didn’t appear to make a difference.

Thanks,

[girishkumar.kannan]

HI @jmledran ,

@jmledran

Do you know if there’s any course in the academy that explains this topics in depth?

Unfortunately, I do not know any course that explains those topics personally. Perhaps someone from TheConstruct can give you more information on these topics. On the other hand, you can try Googling these topics.

@jmledran

How can you modify the publish rate from move_base cmd_vel topic?

From my personal experience, I don’t think you can. But you can always play around with the Global and Local planner parameters.

@jmledran

Or would it be recommended to latch that topic?

Since you said that the movement is performed by move_base package, latching the topic would require you to do modifications in the move_base package’s files, which I think is not a viable solution.

@jmledran

I tried changing the move_base controller_frequency param, but it didn’t appear to make a difference.

When you set a Goal Pose on Rviz, do you get a global planner path? If you get the global path, then you might have to play only with local planner parameters. If you do not get global path plan, then you will have to play with both global and local parameters.

Try changing path planners, you have the following options:
Global - Navfn, Carrot, GlobalPlanner
Local - Trajectory, DWA, EBand, TEB
Some combination should definitely work.

These are just my suggestions. I have not yet worked with Jackal robot.

I am not sure that I helped you much, but do let me know if any of my suggestions did work!

Regards,
Girish

[rzegers]

Hello @jmledran,

@jmledran

The dead-man switch and multiplexer are two very interesting topics that I am not familiar with. Do you know if there’s any course in the academy that explains this topics in depth?

I personally see this topic more as a side subject rather than “core knowledge”. It is a good topic for a YouTube video, though. I added it to my list of possible videos.

@jmledran

And so, a new question arises. How can you modify the publish rate from move_base cmd_vel topic?

Before you try to modify the frequency, have you verified what is the current frequency at which Twist messages are being published?

You can use this command:

rostopic hz /cmd_vel

(If that is the topic for velocity commands that you are using, meaning, you don’t have a namespace).

Cheers,

Roberto

[jmledran]

Hi @girishkumar.kannan and @rzegers

Thanks both for your replies!

It would be great to have a youtube video explaining those topics!

And answering your question @rzegers, I checked my publishing frequency (I remapped my cmd_vel topic directly to my controller topic, so I used rostopic hz /jackal_velocity_controller/cmd_vel) and I got that my average rate was between 19.967 and 20.833 (I’ve attached a picture with my output - Hz.png

. This was at 20Hz controller frequency.

Then I tried changing the controller_frequency using rqt_reconfigure and made it 50Hz. And I got a frequency between 49.383 and 50.279 (I’ve also attached a picture with my output - Hz2.png

).

But in both cases I got a warning in my main program saying that the controller loop missed its desired rate (I’ve also attached a picture of this warnings - Warning.png

).
I’m not sure if that warning is relevant or not. But I couldn’t perceive any difference in my robot movement with the two different frequencies.

If I change the controller frequency do I need to change any other frequencies in my move_base? Like planner frequency to match between them?

But I’m not sure the controller frequency is the parameter I should be changing, because I’m checking the Mastering Jackal course on the academy and I can see the robot moves very smoothly, and it has the same 20Hz in the controller_frequency parameter.

Any thoughts?

Thanks in advance!

[girishkumar.kannan]

Hi @jmledran ,

So, when you set your /cmd_vel to 20Hz, your controller frequency is around 0.0525 seconds
(and)
when you set your /cmd_vel to 50Hz, your controller frequency is around 0.0250 seconds.

20 Hz = 0.05 sec, so when controller takes a little more time, then you must set controller frequency to a smaller frequency value, example, 16 Hz, so the time taken is 0.0625 secs > 0.05xx secs.
[You cannot use 18 Hz because 18Hz = 0.0556 secs which is very close to 0.0530 seconds, so controller can still miss a few steps]. I see 0.0530 secs in the picture you posted.

Also, it is better to keep all frequencies as even number or a multiple of 5. So, { 12, 14, 15, 16, 18, 20, …} are good and {11, 13, 17, 19, …} are bad.

Similarly, for 50 Hz = 0.02 sec, you set controller frequency as 32 Hz, so 0.03125 secs > 0.02xx secs. Here again, you can’t set 35 Hz since 35 Hz = 0.0286 secs which is close to your maximum time taken on your terminal output 0.0280 secs, so chances are this might miss a few controller iterations. Therefore, 32 Hz is better than 35 Hz.

Some Math:
16 / 20 = 0.8
32 / 50 = 0.64
So, as cmd_vel frequency increases, controller frequency decreases in a decreasing ratio.
I am not sure if the relationship is linear or exponential with the data provided.

So, I believe, the best relation between the rate of /cmd_vel and controller frequency could be given as:
controller_frequency <= (0.5 * cmd_vel_frequency)
to be on the safest side to get things working.

So, if you set cmd_vel frequency as 20 Hz and controller frequency as 10 Hz, 10 / sec is still fast !
In my opinion, anything less than 4 Hz is slow. Anything less than 1 Hz is super slow.

This is my observation from the outputs that you have posted.

Let me know if this helps you!

Regards,
Girish

[jmledran]

@jmledran

Jackal movement demo - YouTube

Hi @girishkumar.kannan ,

Thanks a lot for your reply and sorry for taking too long to answer back.

I’ve been trying different parameter values in my move_base node trying to find the most optimal ones. But the results weren’t improved a lot.

However, I checked what you told me about the frequencies and by modifying the controller frequency from move_base node to 20 and the publish_rate from my differential controller I was able to get a smoother movement. But it still not as smooth as in the Mastering Jackal course from the academy.
I even tried with 12, 14 or 16 in publish_rate or the 50 move_base and 32 publish rate, but the results didn’t varied a lot.

However, I was able to get rid of that warning missing desired rate.

But I found that by switching the values the outcome was the same. I mean setting controller_frequency from move_base to 10 and publish_rate from differential controller to 20.

Could you please go a little bit more deep as to why it matters that the controller_frequency is higher than the publish_rate? Because if that’s the case, then the controller publishes lets say 2 cmd_vel (20 Hz) commands to the differential drive controller, then the differential drive only proceses and publishes 1 because of its lower frequency (10 Hz). Isn’t one velocity command lost? Or what’s the underlying logic to that reasoning?

Thanks a lot for all your answers!

[jmledran]

Hi @girishkumar.kannan ,

So, I believe I’ve found what my issue was. I’ve double checked the move_base node params and found no error in them.
So most likely my issue mas due to my computer power. Because I run my project without the gazebo gui and the robot movement improved. Still not as smooth as in the Mastering Jackal course, but it is better.
You can see in this video

Thanks a lot for your help!

[girishkumar.kannan]

Hi @jmledran ,

@jmledran

Could you please go a little bit more deep as to why it matters that the controller_frequency is higher than the publish_rate?

You have mistaken me. I actually said the opposite of what you have understood.

@girishkumar.kannan

you must set controller frequency to a smaller frequency value,

So, saying this again, set the controller frequency lesser than /cmd_vel frequency (publish rate).
For which I also gave a relation:

@girishkumar.kannan

controller_frequency <= (0.5 * cmd_vel_frequency)

~ ~ ~ ~ ~ ~ ~ ~ ~ ~

@jmledran

However, I was able to get rid of that warning missing desired rate.

Yes, so my suggestion worked for you when you set controller frequency smaller than cmd_vel frequency (publish rate). That is why you were able to get rid of those warning messages.

@jmledran

But I found that by switching the values the outcome was the same. I mean setting controller_frequency from move_base to 10 and publish_rate from differential controller to 20.

This is how the values must be set. Not the other way around.

@jmledran

So most likely my issue mas due to my computer power.

Most likely that could also be the case, but with sufficient CPU frequency (clock rate) and less program overloads, you can get this working.

I saw your video in 2x speed. The robot moves quite slow, I agree.

If you don’t mind, could you post your Computer specs?
Your processor, number of cores, RAM, and your results of top or htop command when you are running the robot program. These would make it easy to understand is there are any memory related slow-downs.

Regards,
Girish

[jmledran]

Hi @girishkumar.kannan ,

Thanks a lot for clearing that out! I did misunderstood you.

So, I set my publish_rate from the differential drive to 20 and the controller_frequency from my move_base to 10 and the result was almost identical to the one from my video, but a little bit faster.

About my computer specs, sure, here they are:
It’s an intel core i5-1135G7 (4C / 8T, 2.4 / 4.2 GHz, 8 MB)
PCIe NVME M.2 de 512 GB SSD
3200 MHz DDR4 16 GB RAM
And as graphics processor it has an Intel Iris Xe Graphics

And about the results from top here are the pictures. I added first pictures about the system at rest

When launching the project

And when the robot does the autonomous navigation

For reference, I also reactivate the gazebo gui and checked with top how the system was doing.
So, this are the results with the gazebo gui as true.
This one for the system after launching the project

And this one once the autonomous navigation system was running

Let me know if you need anything else.

Thanks for your help!

[girishkumar.kannan]

Hi @jmledran ,

@jmledran

Thanks a lot for clearing that out! I did misunderstood you.

No problem! You’re welcome!

@jmledran

So, I set my publish_rate from the differential drive to 20 and the controller_frequency from my move_base to 10 and the result was almost identical to the one from my video, but a little bit faster.

Glad to note that there was some improvement.

@jmledran

About my computer specs, sure, here they are:
It’s an intel core i5-1135G7 (4C / 8T, 2.4 / 4.2 GHz, 8 MB)
PCIe NVME M.2 de 512 GB SSD
3200 MHz DDR4 16 GB RAM
And as graphics processor it has an Intel Iris Xe Graphics

These are good specs to run ROS. Also after seeing your CPU and Memory stats from your pictures, I understand that your CPU does have some load (load average 2.61 from your pictures).
Load average should be less than number of cores in your computer. If the value is more than the number of cores, then your computer is overloaded.
In your case it is bit loaded (2.61 out of 4.0), but still fine. Make sure you do not have much of unwanted background processes like system update or any other memory heavy software like google chrome, etc.

As for the Jackal’s slow movement, try updating Jackal robot’s package files. Maybe that could fix it.
Also, try updating ROS if it was not updated for a long time. But make sure to note the current version of ROS installed with rosversion rospy or rosversion roscpp. To get the current version of all packages, do rosversion --all.

I hope this helps.

Regards,
Girish