Autonomous Control of OpenROV

propulsion
software

#1

Hi fellow ROV Enthusiasts!

I am trying to autonomously control the OpenROV using a program that runs on my computer (not the BBB). I would ideally like to use either Labview or MATLAB to write this program. What would be the best way for me to communicate with the OpenROV motors and how would I do so?

Thanks for the help,
Vai


#2

The API that is exposed in a socket.io API. Lots of clients available including a C++ client. You can find an example page for the documentation on the forum.


#3

I am using C++ to replicate the OpenROV stuff done with Node.js. I am also using a Raspberry Pi instead of a BBB, but it’s a slow go to write the code for the various sensors. I plan to use the BBB and Node.js with the OpenROV, right out the box…but then slowly replace that hardware with my own at some point.

If you know some C++, you can use Qt to do what you want to do Vai. In addition to being cross-platform (and available for embedded systems), it has excellent support for TCP/UDP sockets, serial communications and mutli-threaded applications. So that’s an excellent place to start if you want to use C++ to do this.

The one problem I see you having is how to connect the sensors to your computer, and also provide PWM motor control to the ROV. Maybe you plan to still use the Arduino? I think that could be a potential issue for you. You can use stand-alone i2c (or SPI) motor controllers, but then you need a way for your computer to support an i2c (or SPI) bus…physically and logically. How were you planning to do this–not to mention getting sensor data back?

You have an interesting idea, but I don’t know how you could make it happen when you need that sort of hardware to actually provide control and accept sensor data–not to mention all the physical wires it will take from your compute out to the ROV.

TB

EDIT: I forgot to mention that the reason I mentioned Qt is because I’ve seen forum threads that discussed running MATLAB code from Qt-based GUI applications. Although I’ve never done it, I know that you can also create a GUI from inside MATLAB. So that may well be an option for you as well of course. But the hardware control I mentioned above will still be an issue you’ll have to overcome, I think.


#4

Thanks for getting back to me! I plan on using the Arduino to interface with the motors and sensors.

Tom - Thanks for the heads up on Qt. My C++ is a little weak, but I’ll be sure to check it out!

Brian - I am trying to use socket.io. Would I want to create my own socket, or should I just communicate with sockets that already exist?


#5

You would create your own sockets (end points to communication) to communicate from your PC to the stuff running on the BBB, for instance. However since you aren’t planning to use the BBB, then you will have to implement a socket connection to your Arduino. Another option might be serial communication to the Arduino…although that will likely be limited by the length of cable, and likely won’t be of much use to you. Also, in terms of only using the Arduino with your PC, I would definitely look at something that can give you a GUI on the PC. Qt would allow you to do that–and you could do it in C++, or (I think) Python. I’m not much of a Python guy, but I seem to recall seeing some forum threads where people have done a bunch of Qt-related work with Python.

The problem that I see with using serial communication for the way you want to do this, is the length of the USB cable you’ll need–or the length of the UART wire needed. You’ll have to research it a bit more, but I am pretty sure that a USB cable won’t be of much use to you due to the length limitation they have. Last I heard it was like 20 feet or so, although I honestly haven’t researched it in a while. And the i2c/SPI stuff isn’t really meant to be long-distance either, as far as I know. So then it would seem as though you will indeed end up having to use sockets on the Arduino. I believe there is an EthernetServer class in Arduino that you can use, and simply connect an Ethernet cable from your PC to an Ethernet shield on the Arduino. Seems like that might work–but then you’d create sockets on the PC, and on the Arduino, and then communicate between those.

Does MATLAB support the use of sockets? If so, and if you know how to make a GUI in MATLAB…then you wouldn’t need Qt at all I guess. I’m just unfamiliar with MATLAB, so I can’t really comment on using it to create and manage sockets.

Here is a brief tutorial I found for using TCP sockets with Arduino. There’s a bunch of stuff on it out there in Google:

http://evothings.com/doc/examples/arduino-led-onoff-tcp.html


#6

Thanks for your help! I think I will open up a socket on the BBB.

I do not think I was communicating my point clearly: My goal is to write a program on my computer that communicates motor and sensor data via a socket on the BBB. I plan on using socket.io and either MATLAB, Labview, or both.

I will update later based on my success.

While we are here, does anyone recommend a place I can learn how to open up my sockets? A tutorial on interfacing with the OpenROV would also be helpful.

Thanks again,
Vai


#7

Oh…so you ARE going to be using the BBB? Your initial post made it seem that you wouldn’t be doing that.

I think you simply need to Google something like “MATLAB TCP sockets” as a start. For sockets on the BBB (Linux OS), you’ll need to use something like the Node.js socket.io library, or C/C++ sockets…or even Qt-based TCP sockets. Those are pretty easy, and there are tutorials on them on YouTube. Look for the channel of a guy named “VoidRealms” as he has over 100 Qt-based videos. So if you’re going to do them in C++, Qt is a very good way to go–otherwise just use YouTube’s search engine for Node.js-based TCP socket demonstrations/tutorials.

First hit in Google: http://www.mathworks.com/help/instrument/using-tcpip-server-sockets.html

TB


#8

Brian,

You say that there is an example page for the documentation; where can I find this page?

Thanks,
Vai


#9

Note the API is targeting our 30.1.0 release. It is slightly different for the 30.0.x releases.