Hi, I’ve been using myrobotlab but am looking to migrate to ROS. SO I’m just getting started.
Currently using Arduino to interface to 5 servos in a humanoid head including eye cameras as a starting point for some CV experimentation with object tracking and recongition.
I’ve installed the latest version of 32 bit ROS on a Ubuntu 16.04.2 Mate system running in 32bit VirtualBox under Linux Mint. of course I expect that things will be a bit slower running on the VM. But Ubuntu is pretty responsive.
I’ve built the Blink example and have successfully controlled the LED using ROS, but there is a several second delay from when I start the command to when the LED changes state.
Same thing for the single servo example. It takes about 4 seconds from then I start rostopic to when the servo actually moves.
Is this just due to running in the VM environment, or is there something else that I should be looking at to improve the performance. Obviously a 5 second latency from command to movement is going to be a problem:)
If it is just due to the VM environment I have another machine I can sacrifice to doing a bare metal install of Ubuntu 16.04 on.
Other than this perhaps being due to the VM installation is there anything I should be looking at that can reduce the latency? Edit: 04/09/17 - Or is it that there is a significant load time for rostopic and that is most of what I see? In other words for the examples using rostopic to send message requests I’m assuming that during normal operation my application would be interacting with the user and would be sending the message requests off to the arduino about as fast as My Robot Lab does. I’ll dig a bit deeper in the tutorials and perhaps there will be a framework example for a interactive application to control servos, etc. that I can pattern after for a quick start.
Hi It’s definitely the VM, as ROS is a heavy software I expect it to run much slower in VM’s. Though I have used Arduino Mega with ROS indigo on a VM (Ubuntu 14 running on Ubuntu 16) and the time delay was still maximum around a second. I suggest look into the rosrate, the rate at which the communication takes place given in hertz. Maybe You can use Rviz simulation tool to simulate and check the response of your components, but you will have to create a urdf model of your setup and write some code to make it move on Rviz.
Thanks, I don’t know if you saw my edit. I got to thinking that at least part of the latency could be due to having to load rostopic each time to send the message from the examples, so part of the delay may be the time it takes for rostopic to load and initialize before it gets around to sending the message.
So I was thinking that I could write a test program that would be able to send several messages in a row without having to reload and init for each command, or maybe there is a way with rostopic to accomplish the same thing for testing. So more digging into examples and tutorials.
I’m also working on setting up an older box to try running ROS without the VM. Unfortunately the one I have available has some issues running 16.04 Ubuntu, and even 15.10. I was able to get 15.04 to install and run well, but I prefer to use the latest ROS, so I’m seeing if 15.10 even with a couple of hiccups will work well enough. If not then I’ll have to get a newer machine to use for ROS testing, or figure out the hiccups with trying to get ROS installed under Linux Mint.
OK, I have ROS kinetic running now on an older 32 bit box running Ubuntu 15.10.
That improved things significantly. Now each launch of rostopic has a latency of a bit under 2 seconds from the time I press enter to when one of the servos connected to the Arduino moves. That is much better than the 4+ seconds I was seeing in the 32bit VM installation.
Now on to some more advanced tutorials and getting things set up to drive all 5 of the servos associated with the head I’m working with, then on to looking at OpenCV integration, etc.
You’re right about the initialization time. On startup, rostopic registers a new publisher with the ROS master. Then, rosserial_arduino is notified of this and negotiates a direct communication channel with rostopic. All of this takes some time. So what you should do is create a publisher once and keep it open. This should greatly reduce your latency on all following publish() calls.