I need to add 3 M-200 motors to BlueRov2. Now these motors will be linked through a gearbox to a single shaft so they all need to be ran at the same speed. The shaft has to be able to ran and stopped at the command of the operator preferably at variable speeds. I am currently not at liberty to publicly reveal anything after the shaft but if more info is needed as to the required action of the shaft I can go into more detail. Any help would be appreciated. Thanks, Elijah
@adam may be of help here, but I don’t think there is a way to guarantee that the three motors are running at the same speed without some sort of RPM sensor feedback. However, if the rotation of the three motors are physically coupled, they will of course run at the same speed, but I don’t know if this would cause issues with the ESCs.
You can attempt to drive the motors at the same speed by sending the same PWM input signal to all three ESCs. You can do this by wiring a single PWM output on the Pixhawk into three parallel outputs (what I would recommend), or by programming the Pixhawk to output the same PWM on three separate outputs.
There are currently options to configure the aux outputs on the Pixhawk to output PWM signals according to the buttons pressed. For example, you could configure lights2 to test this. This makes dynamic control a little bit difficult, and is definitely not as easy as using an analog input to control the servos. There are currently two unused analog inputs on the joystick, but it is not possible to use them at the moment. It would be good to include support for those axes for this kind of situation, and for gripper control.
-Jacob
Suction dredge eh? Going after gold or something similar?
Hi Elijah,
@jwalser is correct. Brushless sensorless motors depend on specific electric commutation from the ESC, and this can vary slightly between motors due to tolerance variation and other factors. I’m not sure if coupling multiple motors together on a single shaft will work well, it may be that they will fight each other and get out of sync with their respective ESCs. There is some discussion about his topic on another forum here. It could work, but I’ve never tried it myself. If not, adding sensors or using field-oriented control ESCs may help.
-Adam
Jacob, you mentioned earlier that to be able to use these other axes that I would have to create another MANUAL_CONTROL, where would I go to do this?
From what it looks like, I have to
- Install github and download the code
- Modify this MANUAL_CONTROL (somehow)
- Install eclipse
- Compile the code through eclipse
- Flash code to the pixhawk with QGroundControl
In our email conversation, I mentioned:
The QGC joystick is handled here. The current implementation sends a MANUAL_CONTROL message which has only 4 variable axis fields, all of which are used. In order to use the triggers you will also need to make a new message to accommodate the extra analog values.
There is a lot to learn and understand about making a new mavlink message, but briefly, you will need to:
- Make a new mavlink message definition, or modify the existing definition
- Generate c headers using your new message set
- Implement your new message in QGC
- Compile QGC using your new c headers and implementation
- Implement your new message in ArduSub
- Compile ArduSub using your modified message set
- Build and install pymavlink using your new message set on the Raspberry Pi
This is difficult. I recommend an alternative approach like using the lights2 configuration as a workaround.
Also, note that installing git and eclipse are not necessary for compiling. Using git definitely helps with syncing these mavlink changes across multiple applications, though.
-Jacob
What is this lights2 configuration?
You can select an output channel for lights2 (channel 13 and 14 are reserved for other functions by default, so avoid those). You can configure joystick button functions as lights2_brighter and lights2_dimmer. Then these buttons will simply increase and decrease the pulse width on the output channel selected.
Ah, Okay, That will be clunky but I should be able to get that to work. I might have to insert an arduino inbetween to smooth it out. I was looking at the other optional button actions and I saw “relay” and “custom”. What do these functions do?
Relay will pull a pin high or low, you can’t drive most ESCs this way. Relay isn’t supported in 3.4, but is in the current development build. Custom will do nothing, it is a developer option.
I think that relay will serve our purpose best as there will be a arduino on the drone to give the correct esc commands when given the appropriate signal.
Hardware-wise what pin does this relay control and is it adjustable?
On the software side how would I be able to match the pin’s state to the current state of the button? For example, the pin was low until I pressed the button changing to high and then going low once I released the button.
Thanks, Elijah
By default, the two relay pins are AUX 5 and 6, these can be changed to other pins. I made button functions to turn the relay on, turn the relay off, and toggle the relay, but not a momentary activation like you are describing. I think that’s a good Idea though, and I’ll try it.
-Jacob
Sorry to bother you, but any luck with the momentary button? Also I would like to be able modify the code. Now maybe adding a new mavlink message is currently beyond me, but as I earlier stated the relay function will sufice and I would imagine that there would be a place in which some pre procesing is able to be done with the inputs before it is sent to the drone with which this momentary function could be added. However going thru the connection between the QGC and the drone seems to indicate that such a level of the code would reside in the implementation of QGC in the reading of the input from the controller. I would like to learn how to modify this myself such that I can implement further changes however that is not the ultimate goal. If you are able to whip it up in 15 min then that would be great but I only suggest that because it seems like no big deal for you. I would be glad to do it but it unreasonable long amount of time just to get up to speed.
Thanks for any help, Elijah
The role that QGC plays is to read the input from the controller and pass it to the autopilot. The autopilot decides what to do with the inputs, so this functionality resides in the autopilot software, ArduSub. I’ve had a go at it, initial bench tests indicate appropriate behavior, but I will have to test more before putting this in the mainline code. I’ll follow up when that happens. You can see the changes I made here.