I’m looking to add at least two, preferablly 3 servos for a robot gripper to the bluerov2 advanced control stack. Ideally I want to control it with the same controller and interface that the main rov uses. A second tether run with a pair of additional fathom x boards and a second robot arm controller is an option, but I would like to avoid that if possible.
Any ideas or existing projects I can copy? I can do the interface coding if I can get a theoretically workable electrical hardware setup. I have the external mechanics and placement of the arm itself sorted, just need to figure out how to make it do things.
This sounds like a great project! I would love to see your progress and results.
If you go this route, you could use the existing Fathom X interface to send the additional servo control data, and then route it wherever it needs to go once it reaches the Raspberry Pi on the ROV.
Absolutely! A good place to start looking is the AP_Gripper library for (simple) grippers and the AP_JSButton library for joystick button actions. This route would allow you to control the servos by pushing buttons on the joystick. If you want to have a more sophisticated method of controlling the servos, it will still be possible, but will just require some consideration and more tinkering with the code.
Thanks for the input! The Fathom X only has 1 set of wire pair mount points. is there a header to add a second wire run on there somewhere? or would i just add 4 wires to the tether attachment points? Also, does that servo breakout board look like it would work for this?
There isn’t a huge amount to see yet, I have the center core completed mostly, which is esssentially identical to the Bluerov2 but with an I2C breakout board and theoretically a servo adapter board added in. THe exterior of the ROV is going to be built around that core. I’m pulling the 3 thrusters off the larger ROV since it’s just too big for them to move quickly, then I’ll get three more for the rest of the thruster array. The plan is to 3d print the main structure, with rails for skids. Slightly longer front and back to accomodate a center tether mount, and a forward gripper arm and stuff basket / accessories, but similar-ish in motor and hull layout. There will be an additional perpendicular mounted 2" hull containing additional LED’s and 2 measuring lasers mounted in front of the battery hull. That may have a servo for pointing tied to the upper camera servo (probably an OpenROV 2.8 light board and lasers, with a 3rd center LED where that camera would normally go, or potentially a 2nd camera. I also plan on adding a total of 3 analog cameras to supplement the pi camera. one for reverse view, one straight down, and the 3rd either mounted on the robot gripper itself, or in that tertiary hull. Once I get the printable files finished, I’ll make them available to everyone somewhere. You’ll probably need a large format printer to print them, but they shouldn’t be as big as the origional Timrov ppieces.
When there is more to look at, I’ll post a build log.
Let me clarify; I meant that you could send the servo control data to the Raspberry Pi using the existing Fathom X and twisted pair telemetry connection. Then, once the data is on the Raspberry Pi, you can have the Raspberry Pi handle it however you want, by controlling the PWM shield or an Arduino, for example. You could also just incorporate the data into the existing MAVLink telemetry stream, and have the Pixhawk control the servos. You don’t necessarily need to wire up more twisted pairs or use another tether interface board.
It would work, but there are some considerations:
It might be hard to fit all of the electronics if you add the PWM shield.
The PWM shield can only drive servos up to 6V.
The Pixhawk can drive servos up to 10.5V.
Why not use the servo outputs on the Pixhawk?
I thought all the directly addressable outputs were already in use with the thrusters, the lights, and the camera servo. Can the auxiliary channels be used for that? Hmm, I’ll give that a try. Thanks!
Yes, you can use the AUX channels, for a total of 14 available PWM outputs. Note that AUX 5 and 6 are reserved as GPIO, but you can enable PWM on those pins by setting the BRD_PWM_COUNT parameter to 6.
Hmm, OK that simplifies things then. I’ll probably end up using a 4th channel for the analog camera select switch, and maybe a 5th for an emergency ballast drop thing. Should be plenty of room for all of it.