A revised camera tilt mechanism


So a while back I was brainstorming about how to re-do the camera tilt mechanism, especially in a way that would be simple for people who have existing kits (that would include me) to implement. I noticed that the revision 2.4 kits that shipped out recently have revised endcaps, which only have a single O-ring groove and thus open up some extra space inside the electronics tube. I began to wonder whether there was room inside the tube to turn the tilt servo backwards. It turns out the answer is yes, just barely:

This got me started down the path of having the servo tilt only the camera plate, and not the entire electronics chassis.

I cut down the ends of the camera mounting plate, and used pieces of scrap acrylic to make an arm on either side of the plate. It turns out that the pieces I cut off of each side of the plate are just a bit too short to make the correct size arm, so I needed to raid the scrap bin. One arm has a hole drilled for a pivot, the other arm has a cut-down servo arm hot-glued to it:

On the electronics chassis, the tilt servo is mounted backwards, as mentioned above. I hot-glued 4 nylon nuts to the chassis to mount the Beagle Bone:

Here's how the camera plate arm mounts to the servo:

On the other side, I used a 2-56 nylon screw as a pivot:

If the camera is going to tilt while the electronics chassis is stationary, there's absolutely no room for excess cabling. I removed the back side of the camera, and spliced in the white right-angle USB connector. The two LED modules were wired together as suggested by Kensaku here:

Here's the BeagleBone and Cape mounted on the chassis:

To get the maximum tilt angle, the gusset on the side of the electronics chassis has to be cut back a bit:

The net result of all this is that the camera can tilt from about 10 degrees above the horizon to about 60 degrees below the horizon, or about 70 degrees total of tilt. The RJ-45 connector on the HomePlug adapter blocks the camera from tilting any further up. Removing that connector is a bit of a challenge, as it has some circuitry (transformers and common-mode chokes) embedded in it. So for now I'm going to run with a 70 degree tilt range.

To prevent interference with the servo, I used a Dremel tool to cut back some of the housing on the RJ45 plug where it mates to the BeagleBone, maximizing the clearance:

So here it is in the tube:

Next weekend I'll be hooking up the ESCs and the servo and running the wires for all of that.



Nice stuff! Did you modify your code to allow the extra rotation?


I'm still a couple of weeks away from worrying about the software. I figured I'd have to reverse the sign of rotation to account for the fact that the servo was physically reversed, but I wasn't aware of any restrictions. Is there currently a maximum up/down limit in the software?



I think they are capable of 180 degree rotation, so they must be.

Update: I poked around in the code, and the servos are in fact limited on line 59 of /src/lib/ArduinoPhysics.js. The current limits are at -0.7 and 0.7 (out of what appears to be a -1.0 to 1.0 scale). This is somewhat convenient because changes can be made without having to update the Arduino.


I think what I will probably do is hand-tune the software to keep the camera plate from banging against a stop, then having the servo stall and draw lots of current. The only downside to this is that every time I remove the camera plate from the electronics chassis, I'll have to re-calibrate, since I probably won't attach the servo to the servo arm in the exact same orientation every time.

There's currently an open software issue on GitHub (#78) to turn off the servo when it reaches the desired target location, in order to reduce power consumption. I wonder if there's a way you can detect a stalled servo, and shut it down as well?



Really good idea! I've had thoughts about a similar function, but then having the servo in the old direction. and then file off a section around the circular endplates on the chassis. and extending the camera/light bracket to go beyond the endplates. where one connect the arms like you have done.


Hi Thomas:

Please keep us posted if you implement that! I think what drove me to do it the way I did was that it involved shortening the camera plate rather than making a new, longer one. But given how easy it is to work with acrylic, perhaps I should have just spliced in an extension on an existing camera plate. Hmmm, food for thought for the next E-chassis I build up......



I needed to make changes to this for my build, I just tested some changes.

I set the limit to -1,1

and the camera increased the tilt but I did not get the full 180deg range I wanted.

I changed the Map values to 900,2200 and then I got the full range I was looking for.


I'll play with it. The Servo actually allows for reading the degrees of rotation that it is at. So technically we should be able to detect that it stalls and back off in a sort of auto calibration. Next time I'm coding I'll add manual calibration settings in the UI to replace the hard coded values that are set today.


A standard servo does not allow for reading out its actual position without modification. The Arduino servo library's command Servo.read() only returns the last value written by Servo.wrtite(), but not the actual physical position. This starts to be an issue as soon as the servo is switched off using Servo.detach() after having reached its final position, which means that the position can drift inspite of the gear's resistance due to the unbalanced weight of the e-chassis or due to bounceback when the servo is turned too fast.

To get the physical position back from the servo, we'd need a solution like this:


I have a 2.3 kit (with thicker endcaps), so the solution suggested by Walt won't work for me due to a lack of space for mounting the servo invertedly. But finally I managed to get the servo working even when moving the whole e-chassis. The modifications I made to achiev this were:

1. cleared everything (cables etc.) and even the e-chassis itself from touching the inner side of the tube by adding a simple bearing at the opposite side of the servo. The bearing is very simple and consists of a surplus servo arm (which fits into the blue acrylic disc at the endcap just as it does on the servo side) and a screw. This removes friction almost comletely. I'll post a picture of this solution as soon as possible.

2. without friction, the remaining issue is the momentum caused by the weight of the e-chassis when it is accelerated and stopped by the servo. This can be overcome by moving the servo slowly (I use one degree per Arduino loop cycle). I also detach the servo when it can be assumed that it has reached its end position. My Arduino code is no longer compatible to the OpenROV software head revision, but this can be implemented very easily.

3. Since the plastic gear of the servo coming with the kits (HS-81) gets broken very fast, I replaced it with the metal gear version (HS-82) which does a good job. However, to prevent this servo from damage, I limited the angular range from looking horizontally to 50 degrees down, which is sufficient for me at the moment.

I did not implement the phyisical position readout solution shown in the link above, but this would certainly add additional controlability to the servo, making it less prone to positioning issue and damage.



Hi Brian

At the moment it looks like we just have three positions up/down and middle, or am I missing something as I just got to a point on my build where I am playing with the controls and settings. Can I stop the tilt in any position I want?

It would be nice to put a pan/tilt and maybe zoom icon on the screen, for future camera changes, so that we can move the camera with the mouse/keyboard or remote to any position we want.

I will have the ability to do both pan and tilt but at the moment I only have tilt as I need to wire in and configure the 2nd Pan servo.


Here is a photo of the bearing fitting into the blue disc at the endcap at the oppisite end to the servo, reducing the friction significantly.

1437-echassis_bearing.jpg (55.1 KB)


Interesting, Stefan. I had been under the impression that it was the stiffness of the external wire harness that was keeping the E-chassis from rotating. Did you do anything special to minimize this stiffness?



Yes, Walt, you're completely right. The stiffness of the harness IS an issue. I minimized it by NOT using a zip tie here and I removed the screw terminals where I initially had hooked up all 12V/Gnd connections (ESCs etc.) so that there is more room for the harness to move when the e-chassis rotates. The first images shows this. The Tamiya connector visible on the photo connects the batteries with the e-chassis and can be used to connect a charger without having to open the battery tubes (I have an 8C NiMH battery configuration).

Instead of the screw terminals, I used a more compact solution for distributing 12V/Gnd which can be seen in the second image. The white cables you can see connect the main relais (which is switched by the famous bistable reed contact :-) ) with the left (black, Gnd) and right (red, 12V) terminal.


1435-harness.jpg (80.9 KB) 1436-rails.jpg (55 KB)


Hey guys,

It's been really awesome to follow this tread and I think we can combine a lot of our thoughts into a solid design for the next version of the E-Chassis. While we've got all of this brain power in one place, I thought it would be good to show you guys some images of the concept I've been working on based on Walt's idea of having a mostly static structure where just the camera and light platform rotates. I haven't labeled any of the parts in these images as I think that will be fairly obvious, but let me know if you have questions. I'd really love to hear your feedback!

Here are some of the advantages of the new design:

much more open space

cleaner wiring routes

less ambiguous assembly

no need for USB extension cable to BB

more suited for hard mounted electronics

eaiser to access electroncis

more suited for changes in hardware


That design looks stellar! It looks like it's based off of Walt's concept but increases the total area inside the chassis by mounting the servo inside. I assume the three grey boxes are the ESCs, but what is the grey plate above the beaglebone? Just an extra support mechanism? Also, have you measured to see whether there's enough space to stack the beaglebone cape as well as the ethernet adapter above the bone? If not, you could always add a void in the middle support beam to accommodate for that.

Does this version take up the entire chassis width for the single-O-ring design or does it support the dual-O-ring design endcaps as well?

I'm very interested in this design and can't wait to see (or build) some prototypes!


We're excited to build the prototype too! We will hopefully have our very own laser cutter up and running some time next week, so hopefully very soon, we can built a few test e-chassis to verify that they fit together right, then send out the cut file to everyone! I have a few more modifications to do before the cut file is ready for that, but if you like, I can send you what I have whenever.

You're right that the grey boxes are ESCs. The description of the grey plate also answers your question about fitting the Cape on the board- the plate represents a PCB we are considering which would replace the Cape and also would have power distribution electronics on-board. This is still an early concept (which is probably obvious since there is nothing else on the PCB) but we think it could make wire routing much cleaner, reduce cost, add functionality, and make the E-Chassis much easier to assemble.

We'll keep you posted as we develop this design!



Oh- and to follow up with your other question about the end caps this would work with-- unfortunately, this would not work with the two o-ring end cap design. Since we've switched to the single end cap configuration, we wanted to redesign an e-chassis that would make maximum use of that space. I suppose the width of the design could be reduced (since this will be open-hardware, we'll make all the CAD files available), but from here on in we'll be designing for the new increased internal width of the main tube.



I feel that's a good direction to go towards. Plus, as you said, it shouldn't be much of an issue reducing the dimensions of it for those who might want to retrofit their earlier kit versions.

When do you think you will be posting the CAD files/Laser files for it?


Probably in the next few weeks. I’m going to add some more details tonight, then start reviewing the design with other people. Maybe I can send you am early version to take a look at!

Also, for this PCB, I’ve been considering either using a single Arduino Mega microcontroller or two separate Atmega 328 microcontrollers (so that one could be for dedicated ROV control and the other could be for add-ons). This is a concept Jim Trezzo introduced, but I’m still weighing the pros and cons for each. Any recommendations?