openrov / openrov-software Goto Github PK

On the UI enable a 'capture' function with an button and a keyboard shortcut.

• in the sidebar you can see thumbnails of the captured images
• you can download the images to topside

Current Behavior: When running the most recent BeagleBone, when I SSH and kill the Node.js process, the web interface does not appear to update and instead shows the green connection light.

Expected Behavior: When the backend process fails (or is killed) the connection light should turn red, and control of the ROV should be suspended with an error message.

Notes: This was tested with just the bare BeagleBone, no shield/Arduino/etc. It was tested with the linked disk image.

Eric pointed out that with the 5 minute connectivity issue, you can have the connection drop with the motors still powered with no way to turn them off.

The beagle code should call the Arduino stop command when connectivity is lost.

from the forum: http://openrov.com/xn/detail/6365107:Comment:36445

"there is also an issue with a constant servo jitter when the servo has reached one of its end positions which comes from the servo trying to hold the exact postion, which adds a constant current of 100 to 500 mA and surely will lead to another servo damage not to speak of the faster draining of the batteries."

Use keys Q to look up, A to look forward, Z to look down.
Also show in the UI where the webcam is pointing to

The Voltage and such that is sent to the browser is not resuming after the Arduino firmware updates unless the node.js process is restarted.

reference: http://openrov.com/forum/topics/automated-video-resolution-switching
With the new homeplug tether system. some users has now really high bandwidth, but the videostream remains the same.
Could one make some simple config switches to change the resolution of the video, and/or change the resolution based upon link-speed.

When trying to update Arduino code on the Cape from the cockpit interface, the code fails to upload. It repeatedly returns these error messages
"Initiating arduino reset
upload failed, trying again.
avrdude: stk500_recv(): programmer is not responding avrdude done. Thank you."

It seems that many people are having the same issue

See this thread for more information: http://openrov.com/forum/topics/trouble-loading-code-into-cape-bd?id=6365107%3ATopic%3A34028&page=2#comments

As a USER I want to see the run time of the current dive.

As long as we don't know anything about depth, we should display the time since we started the ROV.
Once we know about the depth, calculate the dive time to the UI

From Eric: 'I envision using the 1,2,3 keys to set the power'.

Need a way to select different speed settings when using the keyboard. Currently it is all or nothing.

The serial connection has to be stopped for the firmware upload and is restarted afterwards. For some reason the connection state doesn't change to connected again.

Code for the arduino part has been already implemented

When uploading Arduino firmware there might be errors:

• Error while unpacking files
• Error while compiling
• Error while uploading

These errors should be reported in the UI accordingly.

To enable this, the scripts in /linux/arduino/ would to be extended. Currently they report error code 0 (no error) always.

I would be nice to use ADC4 or 5 as water detection input (http://arduino.cc/forum/index.php/topic,5961.0.html) one could also use R38/R55 with changing the resistor to a higher value.

The system is already event based, which means messages are shooting around on a bus that can easily be extended. Need a way to organize and register modules of functionality that plug in to the eventing system. Ideally a maker can create a new visualization for a sensor that others using the same sensor could select for use in their cockpit configuration. If a robotic arm is added, the UI for interacting with that arm can be a similar pluggable cockpit module.

No idea how we can automatically measure this without a depth sensor.

Add voltage reading to UI

There are some standard procedure for calibrating ESCs. Usually it's:

• start the ESC with full-throttle applied
• keep full-throttle for a few seconds (till leds change color)
• move to full throttle reverse
• keep for a few seconds
• move to midpoint
• keep a few seconds
• enjoy

Also some ESCs come with settings that are not ok for the ROV (mine where set as default to start reverse only a few seconds of zero throttle). Not sure how we should handle this

The arducopter code does automatic calibration: we might as well take inspiration on how they did it.

http://joelongstreet.com/blog/2011/08/15/understanding-how-the-accelerometer-and-gyroscope-work-in-the-browser/

Imagine having a hot spot on the screen where you can rest your thumb that puts the IPAD in to control mode. As you tilt, the ROV accelerates. As you rotate, the ROV turns. Titl... verticle thrust control.

The goal is to give makers a way to add useful code for the senors, motors, etc that other people can leverage without stepping on each others toes. One thought was to have a build system where using a web site you can select the different sensors and features you want in your firmware version and the site kicks down the .hex file for loading. There is certain meta-data needed to keep code from conflicting with one another.

Per dev call comments from Jim. A way to see the raw data so that someone working the Arduino could add data and have it pass all the way through to cockpit for viewing without having to know anything about the cockpit software.

We already have joypad support, but current code is not update with the lastest APi changes.
Also LED brightness and servo tilt is not implemented yet.

Probably led brightness can be changed with 2 of the action buttons of the joypad while servo tilt probably the triggers in the back of pad.

In the arduino software, the motor servos are driven with a call to the servo library write() function. This function takes an integer input from 0 to 180, with 90 being stop and 180 being full forwards. With the current motor arrangement, full power is at about 120, so we are only using 30 counts to represent the full range of forward speeds.

The software should be changed to use the writeMicroseconds() function, which uses a range between 1000 and 2000, with 1500 as stop. Resolution of motor control would increase by a factor of 5, and in addition the linearity of control would improve, because internal to the Arduino servos library, the write() function is mapped directly onto the writeMicroseconds() function, and the mapping of a range of 180 to a range of 1000 is not an integer multiple.

Besides changing the servo call, the midpoint value will need to change, and there are likely upstream changes in whatever code reads the joysticks as well. I'm not familiar with this code so I can't comment on the changes required.

As OpenROV matures and we have more people tinkering with it, I'm trying to think about ways to keep software debugging and software maintenance from becoming a nightmare. One of the things I have noticed is that there doesn't appear to be anything in the Arduino software for the end user to know what version is running on his Cape. He could always download a new version, but this is of limited help in the debugging process, and is of no help at all if work is being done on an experimental version of the Arduino code. This has the potential to be a configuration control nightmare.

So, what I propose is that the Arduino code start it's serial message to the BB JS code with a header that has version and checksum information in it.

Here's a description of what I propose. It will likely have to be implemented in stages. This is just a concept, I'm open to any other idea that has the same version-reporting functionality

In the arduino code, there are two 32-bit constants defined. One is the version number, the second is a checksum.

The serial message that goes from the Arduino to the BB starts with a header. As a minimum, that header includes the version number and the checksum.

The version number would consist of 4 1-byte fields. The first is the target hardware type- such as Arudino Uno, Mega, Due, custom, or whatever. The second shows the author of the build. 0 could represent official builds, other numbers could be assigned to trusted end users who have running forks of the Arduino code. A block of numbers would be open for home users to do whatever they want with. The third and fourth bytes represent the build number, which is incremented every time there's an official change in the Arduino code by the maintainer.

At first, updating of the build number could be done manually by the maintainer. At some point, whatever build script is used can auto-generate a build number during the process of tagging the build as an official one. It is at that point in time that the checksum is calculated as well. The checksum would have to somehow be based upon all the code -except- for the version number and checksum constants.

The JS code in the BB would pass the version number up to the cockpit. If there's any question as to what's running on the cape, the user can just look at the appropriate part of the display and see. So if you're a newbie having problems at home, part of your problem desription is to report what version of Arduino code is running on your cape. If you're tinkering at home with various Arduino versions, you don't have to guess what you last loaded on the ROV.

The documentation for the home builder will need to be revised to mention this functionality, and show the home user how he can assign his own custom build numbers to his experimental versions of the cape code.

The functionality of the checksum is a little trickier, and I'm not sure it's even possible. Ideally, the BB JS code should have a way of checking the SW that's loaded in the cape, and calculating a checksum of the result. This could then be checked against the checksum in the Arduino serial stream, and it could report if a checksum mismatch occurs. This functionality doesn't have to be periodic, it could be arranged to happen upon command from the user. The intent of the checksum is to be able to catch situations where the code was modified but the version and checksum constants were not changed.

Thoughts?

-Walt

Add a diagnostic mode to the OpenROV cockpit to run a pre-flight check of all systems.
Also make it possible to manually set the value sent to motors.

As the user of the OpenROV pilot, I wan't to be asked if I want to save the last dive in the DiveLog once the ROV is on the surface for 5 minutes. Alternatively, I can press a button to save the dive in the DiveLog.
While saving the dive, I can add additional information:

• Location (If my laptop has a GPS module, this could be used)
• Dive Site name
• Comments

The following things have to be recorded in the DiveLog:

• DiveTime
• Max Depth
• The dive profile with depth and temperature graphs
• Screenshots taken during the dive.
• Location, Dive site name, comments
• Battery levels in an interval of 1 min

The dive log should be vieweable any time on the UI and exportable to a HTML document with.
This enables me to keep track on my dives easily.

Here is a pretty stable and popular Node.js library to control Firmata enabled devices:
https://github.com/rwldrn/johnny-five

We have 3 components:

• html cockpit
• node.js app
• arduino code

all of them now do some kind of mapping and transformations to and from physical values and commands from the operator.
I think it would be better to place all those conversion in the arduino code, and have UI send logical commands to the node.js app which should send them to the arduinio without conversions. And let the arduino do conversion from yaw, throttle lift values to motor speed, and convert voltage ranges to battery level and in future temperatures, depth and heading. This way the arduino is the one that needs to be changed if the electronics part changes.

As a USER I want to see if the BeagleBone can communicate with the Arduino.

Use + and - to dim and brighten the light.
Add a to the UI an indicator of which level the light reached

Connect with browser. Kill the browser. Expect the socket.onDisconnect code below to leave a notice in the log file. Does not.

io.sockets.on('disconnect', function(socket){
connections -= 1;
console.error('disconnect detected');
if(connections === 0) controller.close();
});

Just limit the height of the debugging pane so that it doesn't overlap the status bar

It would be nice to have some basic functionality for the AUX2 output on the Cape.

First toughts would be to have it either a pwm control as AUX1 for external lights, or configurable to On/off for driving relays, solenoid, valves etc.

As a USER I wan't to see the output of the firmware upload scripts so I can take appropriate actions in case of an error.

These details should not be visible by default, but be made available by clicking on a 'Show details' button/link.

The battery profiles would change the behavior of the ROV to optimize it for the given characteristics of the battery. Things like overall throttle cap, meter rate of motor power changes, etc... change based on maximizing battery life and preventing failures in low power situations. The throttle behaviors change as they take in to account the current Voltage as an indicator of battery life based on the battery type.

When the capture process fails to start, an exception is thrown by the child_process lib and not being catched it kills the whole process.
Probably it should be catched, and have the possibility to retry launching the capture process

ENOMEM looks like a NO MEMory exception or something similar

child_process.js:794
    throw errnoException(errno, 'spawn');
          ^
Error: spawn ENOMEM
    at errnoException (child_process.js:847:11)
    at ChildProcess.spawn (child_process.js:794:11)
    at exports.spawn (child_process.js:618:9)
    at camera.capture (/opt/openrov/src/lib/OpenROVCamera.js:65:25)
    at Object.fs.exists [as oncomplete] (fs.js:91:19)

Both for the cockpit and the arduino code

This sets the speed used by motors when controlling them via keyboard, and sets the limit when using the gamepad.
Can be done in similar way to the testing sliders, but allowing to set a range on the slider for upper and lower limit.

in the UI, add a compass and heading visualisation like in the mockup https://raw.github.com/OpenROV/openrov-software/master/gui/OpenROV_console.jpg

• decide and apply the roles of each device: now is a bit mixed as the Arduino Controller converts yaw and throttle to motor mixing, while probably this is better to send yaw and throttle and elevation to the arduino directly, and have it deal with motor mixing)
• Use better SoC in the arduino module (now sensor classes handle also serial communication)
• clean a bit the javascript frontend: right now is a bit of spaghetti code :)

I think it's better to do them after the release

http://openrov.com/xn/detail/6365107:Comment:36314

The deadzone is a concept that comes from the fluctuations in analog controls as well as the at rest pressure fluctuations from a human hand on the controls. In the digital world, we don't have to worry about the analog jitter. The deadzone for handling human at rest pressure is controller dependent. The ROV control code itself should know where the start and end of the dead zone along the 1000 to 2000 control range of the ESCs happens to be and treat the entire deadzone as a single increment.
A keyboard users who adds one unit of trim should see the motors at there lowest rotation start moving. They should not have to keep upping the trim from 1..2..3..end of dead zone... for the motors to start moving.

Probably every time the openrov process is started via init.d start the latest log file should be renamed to log.0 log.1 log.2 log.3, etc

From the forum: http://openrov.com/xn/detail/6365107:Comment:36445

"Hi Jim,

yes, the servo issue. I think the Hitec HS-81 servo was not designed for full 180 degrees of rotation. In addition, the design of the electronics chassis does not allow for a rotation angle of 180 without getting in conflict with the cable harness entering the acrylic tube."