Home        Store        Docs        Blog

Autonomous Operation

(Phedias Demou) #1


I am trying to create an Autonomous UUV by expanding on your excellent work of controlling the vehicle. The first step is creating a mission for depth only while sensor research is being undertaken for localizing in the x-y plane. I want to run the autonomous mission offline by not reprogramming the controller (pixhawk). My current thoughts in doing that is using Dronekit or ROS. More like MissionPlanner. What do you think? Do you have any better suggestions? Thanks for your consideration.


Phedias Demou

(Jacob) #2

I think using Dronekit, mavros, or mavproxy would all be good for what you want to do. You should make sure that the messages you try to send to the pixhawk are actually implemented by checking in GCSMavlink.cpp.


The biggest issue you will face is that only Stabilize and Depth-hold modes are supported in ArduSub right now, and you will have to become familiar with, and modify the firmware in order to do what you want. For autonomous operation, GUIDED mode must be implemented, and it requires GPS. Check out the Poshold-nogps branch to get an idea of what kind of modifications need to be made.

The only way around this that I can think of would be to write a script that automatically changes the RC inputs, as if you were moving the joystick.


(Vagelis Chalkiadakis) #3
The only way around this that I can think of would be to write a script that automatically changes the RC inputs, as if you were moving the joystick.
I am interested in doing something similar to that. Are there any starting hints you could propose?


(Pierson) #4

It really depends on what your application is. If you are serious about Autonomy and are thinking about investing in the kind of sensor that enables horizontal localization I would strongly recommend ROS. I have used ROS on my previous 2 AUVs. It enables virtually unlimited functionality. It is probably more difficult to set up than the other options and requires initial investment to really use it, but if your are trying to develop an autonomous vehicle the investment will pay off in droves.

Edit: I didn’t see the original post was quite old


(Vagelis Chalkiadakis) #5

Thank you for your answer.

ROS is certainly an option we are considering. As our project has to do with aquaculture cage inspection, where the space is limited, we are developing optical navigation algorithms, based on targets.

At this moment, we are mostly dealing with this, so my problem is how to write a simple script that, for instance, will command the AUV to “turn to the left” if the navigation target is in the left part of the picture (admittedly it is a little bit more complicated, but you get the idea I hope).

I am trying to test this using mavproxy scripts, but it looks that I cannot enable the “rc” command.

So the first “problem” I have to solve is how to enable the use of a mavproxy “rc 8 1600” command…


(Jacob) #6


MAVProxy ‘rc’ commands should work. Note that this controls the input channels, not the output channels. You can verify the results of the rc command by watching the RC_CHANNELS_RAW mavlink message.

The mavlink system id of MAVProxy (–source-system) and ArduSub (SYSID_MYGCS parameter) must match for the commands to be accepted. These both default to 255.

Channels 1-7 are the control input channels. The other peripheral channels (camera tilt etc. ch8+) do not work, I am looking into that.


(Jacob) #7


I think you are off to a good start and in the right place by using the ‘rc’ command. This command sends the RC_CHANNELS_OVERRIDE mavlink message. I recommend reviewing the rc MAVProxy module that takes care of this. Ideally, you could write your own MAVProxy module to do what you need.


(Vagelis Chalkiadakis) #8

Thanks Jacob.

I will study the code andI will come back to you.

In the meantime, I notice the following behaviour:

  • I am connecting the bluerov2 and powering it up.
  • I start QGC to verify that it works correctly and close it.
  • I start mavproxy.py without any arguments, and it connects successfuly to bluerov2 (provides info about firmware, battery, etc. etc.
  • I give the commnand "rc 8 1900" (supposedly it will move the camera up)
  • The servo moves up just a little and then down to center, and then up, and then down (like a hiccup :) )
  • The hiccup ends if a give a "rc 8 1500" command.
  • Interestingly, the same with this servo happens if i give the command "rc 7 1900" which supposedly will turn the lights on. Rather, the camera servo starts hiccup again...
Any thoughts?

Thanks in advance,


(Jacob) #9


There is a conflict between the RC_CHANNELS_OVERRIDE (which mavproxy uses) and MANUAL_CONTROL (which qgc uses for joystick control) messages. You cannot have a joystick connected to qgc while you are using rc override with MAVProxy. Only channels 1-7 will work with RC_CHANNELS_OVERRIDE right now, the issue with the camera is coming from this function (you can comment out the body).

When you write your own module, you should consider using the MANUAL_CONTROL message instead of RC_CHANNELS_OVERRIDE, and reference the code here.


You should also understand the difference between rc input and rc output. Using rc override overrides the input channels, not the output pwm on the servos. The camera input is on channel 8 and the camera output is also on channel 8. This is not always the case. The lights output is on channel 7, but the lights input is on channel 9, therefore you would need to override channel 9 to change the lights. RC_CHANNELS_OVERRIDE only uses channels 1-8, so you will not be able to control the lights with that message. MANUAL_CONTROL will allow you to control the lights.



(Vagelis Chalkiadakis) #10

Hi again Jacob.

I am trying the following MAVProxy commands and keep getting the corresponding results (in both Linux and Windows environments):

> Open MAVProxy (it connects to Bluerov2 normally)
> arm throttle (motors armed as shown in console)
> rc 3 1510 (motors start spinning trying to move rov forward)
> rc 3 1500 (motors continue - although I think they should stop)
> disarm (motors stop - camera servo starts “hiccup”)
> arm throttle (motors start spinning)
> disarm (motors stop)

I was expecting that I could start/stop thrusters with “rc” mavproxy commands, but this doesnot happen.
Any ideas?