Build Day on Saturday, March 9th (And development call on Tuesday...)


We'll be having another build day on March 9th, from 1-5pm. You can RSVP here:

We're also planning a Development Call at 1pm PST on Tuesday, March 5th. Please add me on G+ and send me a message if you'd like to take part in that!


Hey David:

Now that there's an events page on the wiki, is it going to be kept up to date? I don't know whether I should bookmark the events page and look there, or always just look to the OpenROV blog when I want to figure out what's upcoming.

Also, do I need to have a google+ account or whatever you call it to take part in the developer's calls? I'd like to hear about what's going on with battery pack design, and perhaps add my thoughts as well, before Saturday's build day.



Yes! I’ll update the wiki page, too. The easiest way is just to join the G+ group and watch for events there.

I’ll also create a static page for instructions to the development calls fr anyone who’s new to Google Hangouts.


YIKES! Please note the time for the dev call tomorrow is 1pm PST, not noon. Sorry for any confusion.


I'm try to keep the events wiki page up to date and cross-post as appropriate.

Here's the page for tomorrow's call: - it's in the index as well.

Walt, you can follow the events page, as long as David keeps me posted :)


Here's an outline for the meeting, please add:

  • results of followups
  • proposed agenda items
  • etc - it's a wiki!


Hi David:

So I just watched the video of the Dev Call on YouTube (for the link see the Dev Call wiki link below). Thanks for posting it there, and thanks Peter for starting to organize the notes on all this stuff. There was a lot of interesting discussion, and it was a bit frustrating to not be able to comment since I wasn't there in real-time. Here are my comments after watching the call:

1.) The discussion on where to put the software complexity- Arduino or JavaScript on the BeagleBone- was really fascinating to me. I'm a hardware guy, and the Arduino development environment is pretty simple to learn, so I lean towards the side of putting things in the Arduino, and touching the JavaScript code as little as possible. It was interesting to hear that, for the most part, the software guys want to essentially abstract the Arduino (either with Firmata or not) and then do everything in JS or some other layer on the BB. For me, my desire is to have it exactly the opposite- I want the BB to be a generic pipe to the topside unit for the camera and the Arduino. I have lots of great ideas on how to interface sensors to the Arduino, but unfortunately I have no idea how to send that sensor data topside, and it sounds like I'm going to have to learn JS to accomplish this.

From comments on the call it appears that there are still issues with programming the Arduino through the tether/BB, and this is a bit troubling to me. Pulling the Arduino chip every time you want to make a change in the code will get old really fast, and will discourage those of us who are not software types from tinkering and contributing. The ability to remotely update the Arduino chip seems (to me) to be a fundamental architectural issue that really needs ironing out.

2.) Thanks Peter for making the link over to the Under Development Page, and for starting to clean that up. So it turns out I didn't even know that the GitHub page existed for electronics, thus my comments on another forum post that I didn't know how to capture proposed changes to the BB Cape. I had been looking on the OpenROV home page menus under "Build One" and it turns out there are links to GitHub there for software and mechanical hardware but not electronics. I don't necessarily know how to structure that "Build One" menu, but I do know that it tripped me up.

I'll get myself a GitHub account and start posting stuff on the openrov-electronics site. Do I need anything more than a GitHub account to do so?

3.) If the project is heading towards standardizing on HomePlug tethers, I can help with the documentation process. Let's talk on Saturday about how to move forwards with this.

4.) The discussion on motor pulsing phenomena was an interesting one. The idea of a settable gain control for the motors was a good one. The Seabotix ROV software that I have used has this feature, where you can preset a maximum throttle in percent of full power. That way, you can do fine work in calm conditions without overpowering the ROV, and for training purposes you can start with a very low power available.

This being said, however, I was surprised that more time wasn't spent on discussing how to find the root cause of the motor pulsing phenomena. Perhaps this is something to discuss a bit at the build day, figuring out how to cleave the problem and figure out whether its a software issue or an ESC issue or what.

5.) I was happy to hear that somebody (outside of OpenROV) is working on interfacing a Logitech C920 webcam to the BeagleBone. Here's a website I found that looks promising. Hardware-based H.264 video compression is definitely the way of the future, and if we can get the C920 to fit in the electronics tube, I think a lot of people would want to run with that solution. If I don't get wrapped up in battery pack redesign over the next couple of months, I think I'm going to tear down a C920 to see if I can get it to fit in the ROV.



Walt: i'm also an electronics guy and also was a bit unsure of how the GitHub system works.

to post issues you mainly just need to register a username, and for practical purposes follow the Openrov sections.

For posting files(like i did with schematics) i used the Github software for windows.

this is basicly build up that you sync the github folder/section to your computer, files that are edited(source code etc) is detected, and you can upload the changes you do(called commit?)

to upload files: put the files you want to upload where you synced the github section. and commit them. one of the admins for the github section needs to approve it before the files get available.

software guys: correct me if i'm wrong ;-)


btw Walt, I also support you on your 1st point. and is think Jim's proposal with some easy "portals" to send information up would be great for the Arduino community.

In my opinion there must be quite simple to program the frontend/node-js etc. system to read in example a tag posted from the arduino: $1"sensorname","value for front","descriptor"* following $2....

then the thinker ercan easily hardware adapt and configure an analog pressure sensor on an ADC input, make the offset and scale. and finaly print it to serial as above as $1.

example $1"Pressure","10","Bar"* and this is then printed to empty fields or sections in the frontend(bottom bar)

the defined $1 gives with section the data is shown in the frontend.

Most monitoring sensors can be shown in text and numbers in an early stage as this; pressure/depth, temperature, heading, proximity sensors, current-sensors, current-consumed(mah)


Full notes on dev call posted: