Development Call Today


#1

We had a Google Hangout with some of the main developers of the project. We try to have these hangouts every week. They're all immediately archived to YouTube in case you missed it.

Drop a note in the comments if you'd like to be included in future development calls. We'd love to have your input/feedback.


#2

Please invite me to future development calls. I'm great with bits, still working on the atoms.


#3

[WARNING: Notes taken by software developer. Some of the hardware/electronics parts are incoplete and/or garbled because I didn't know what was going on. But I felt better when people were in awe of the wizard-like power of writing Javascript ;)]

http://openrov.com/profiles/blogs/development-call-today-1
http://www.youtube.com/watch?feature=player_embedded&v=idWPcdrVf2c

Summary:
[0:40] Options for Tethering without AC power
[3:00] Voltage drop problem with electronics and controls
[~16:00] Different ways to adjust thruster controls - Arduino vs JS, adjustable vs better defaults
[~26:00] Ranges for limiting throttle
[32:40] Discussion of servo pointing down
[34:00] Data stream coming from Arduino - self identifying sensor readings
[42:15] Raspberry Pi port
[44:40] Camera, video, Logon to OpenROV with more than one computer?

Callouts:
[FOLLOWUP] check voltage graphs from [4:40] against current
[FOLLOWUP] Some electronics diagrams were emailed instead of posted publicly - what's the best way to post/share docs?
[PROPOSAL] - keep current constant and adjust speed - speed isn't a limiting factor, brass props are *fast*
[FOLLOWUP] right now battery voltage is being measured on the wrong side of the diode, could change for next cape
[PROPOSAL] move mechanical/physical things to Arduino, so the people that play with motors
[FOLLOWUP] Fix cad files and documentation so the downward servo hole is the right size
[IDEA] put a serial display into the cockpit so Arduino-only people could still read values
[PROPOSAL] Create an "observer" connection mode so other people can view the stream without issuing controls
[TODO] Wireshark observations of bandwidth usage
[PROPOSAL] Move to 100Mb connection to avoid constant struggle with 10Mb limitation; it can be optimized, but there are tons more better things to spend time on

------------------------------------

[0:40] Eric (http://openrov.com/profile/1gupl83kvnk8f):
Tethers are in issue, for data throughput and movement
Ethernet over AC 2-wires works but is dangerous
Walt (from forums) and Liz (locally) took the communications board from an OTS part to send comms w/o AC power, trying to see if it can be better
They have the pool at the office but it's not setup

-------------------------------------

[3:00] Electronic problems between electronics and control:
John:
If you separate supplies so escapes from the horizontal thusters are running, you don't see any noise on control electronics
(some discussion about voltage drops causing reset and failure - couldn't understand)
[4:40] graph and discussion
Possibility of having different controls for electronics and motors
[FOLLOWUP] check these graphs against current
Difference between using brass and plastic propellors - smaller props might be better above some min size
[8:15] discussion of alternatives to splitting power - put supercapacitors and diodes between electronics
(electronics discussion that I don't understand enough to summarize)
[FOLLOWUP] Some electronics diagrams were emailed instead of posted publicly - what's the best way to post/share docs?
Computer restart takes ~40sec
Prefer pulsing motors and keeping the computer running because you can still get home
Interal configuration of batteries matters - testing with NiHi batteries (4 amps), Li batteries (higher V chemisty gives ~8 amps)
But John's observed voltage and reset issues are coming from a powered test bench so it's prob not a supply issue
[~16:00]
[PROPOSAL] - keep current constant and adjust speed - speed isn't a limiting factor, brass props are *fast*
Just b/c motors are capable of spinning fast doesn't mean we should let them
Put a control gain block to limit throttle
Experimented with changing ESC (electronic speed control) to 50% in software, but currently only on reverse motors
ESC values below 20 are not acknowledged
Joystick controls have software problems because of the dead spot in the middle

-------------------------------------

[20:30] Discussion of arduino control for motors
Colin

-------------------------------------

[21:30] Architecture question - where should configs/settings live?
Arduino - as simple as possible, listen to commands from the BeagleBone
BB - more complex software, Javascript, harder for normal people to program [Editors note: As a software guy, this is hilarious to me after having my mind blown by the electronics discussion earlier!]
Should we put more code and logic (adjustments to gain limits, etc) in the Arduino so the electronics people can tweak it
Colin: tweaking options and configs could be done easier through a JS interface
BB knows the voltage and only BB knows that info
[FOLLOWUP] right now battery voltage is being measured on the wrong side of the diode, could change for next cape

-------------------------------------

[25:00] Dominic shows up (http://openrov.com/profile/DominikFretz)

Throttle ranges - possible 30-150 instead of 0-180 - you could get that effect with a one-line code change
=> https://github.com/OpenROV/openrov-software/blob/master/src/lib/ArduinoPhysics.js
There are lots of choices about how to adjust the prop speed, for reliability and maneuverability
Comparing to
Software remapping is easy, start by putting these into config files, adding to UI should be easy then
All these calculations should be done in the same layer, e.g. move physics to Arduino
[PROPOSAL] move mechanical/physical things to Arduino, so the people that play with motors
Node software would be about user interaction, command/control, etc

-------------------------------------

[32:40] Discussion of servo pointing down
John used a smaller servo and doesn't have the lockup problem, but the CAD files for the frame are too big for the smaller servo
[FOLLOWUP] Fix cad files and documentation so the downward servo hole is the right size

-------------------------------------

[34:00] Data stream coming from Arduino
Modified Arduino code to measure current from cape
The bar at bottom of cockpit - what if it was data driven, self-describing?
If someone added an Arduino sensor, it could automatically display in the cockpit
Probably won't work for too many things, e.g. heading; best for simple values that don't require special handling
[IDEA] put a serial display into the cockpit so Arduino-only people could still read values

-------------------------------------

[~37:00] Is it time to release a new version of the firmware/software?
reset issue possibly still present?
issue with GPIO pin (?)

[42:15] Philip (http://openrov.com/profile/PhilipandNathanaelMathieu)
Working on switching a Raspberry Pi for the Beagle Bone
Trouble getting communication with Arduino
Firmware upload isn't working, has to be run as root, from a certain directory
UARP (?) easier because Pi has a built-in port
Dominic and Philip are going to meet tomorrow (2/15) to work through those issues

-------------------------------------

[44:40] Camera, video, Logon to OpenROV with more than one computer?
ROV gets jumpy going back and forth between two computers
[PROPOSAL] Create an "observer" connection mode so other people can view the stream without issuing controls
Issues with mpeg, jpeg streaming, bandwidth issues, etc
Possible solution: use ffmpeg, ffserver (not really successful) - problems between relaying, capturing, displaying, and encoding video
Need right combination of codec, transport protocol, and video container
The system looks like it uses ~12Mb/s bandwidth (based on Eric's friend's observations in Antartica)
[TODO] Wireshark observations of bandwidth usage
John - 10MB connection made the video really choppy
Dominik had more success with VLC, mpeg encoding, send via UDP
VLC: http://www.videolan.org/vlc/index.html
Microsoft robotics platform and Xbox controller as no lag when you stay within their ecosystem
[Editor's note - video should be sent to the controller interface and relayed from there. Don't overload the poor processor and bandwidth on the ROV
Dominik mentions someone working on an integrated BeagleBone camera (didn't catch name or link)
[PROPOSAL] Move to 100Mb connection to avoid constant struggle with 10Mb limitation; it can be optimized, but there are tons more better things to spend time on

-------------------------------------

[56:34] Eric - We should take notes on these calls (Editor: Ha! Great idea!)

This is really freaking cool!


#4

THANK YOU PETER!!! We were just talking about which one of us was going to re-watch and take minutes...

Will invite you next time!


#5

No problem at all. You can pay me back by letting me pester you with questions on Saturday :)


#6

Please invite me to future development calls as well. Even just so I can "listen in -realtime"!


#7

I would like to be included in future calls as well. Are they ad hoc, or setup on a regular weekly, bi-weekly, monthly or ??? Just let me know and I will do my best to attend.