Galene payload documentation 2019-05-21 Powered by /dev/loadA6 Cradlepoint assigns IP 10.89.9.5 over DHCP Connect to payload using Remote Desktop Protocol on any of galene's addresses (lrauv-galene, lrauv-galene-cell or wifi) and port 3300. (There is a tunnel from galene's IPs:3300 to the payload's internal IP:3389, i.e. some-galene-ip:3300 -> 10.89.9.5:3389) User account: fphub\p-lab pw: faultdetection python FDI code location: C:\Users\p-lab.FPHUB\Code\lrauv-testbed-2019 (running branch 'galene') Configuration: C:\Users\p-lab.FPHUB\Code\lrauv-testbed-2019\myconfig.yaml Contains the following two pieces of info: * Data is going into C:\Users\p-lab.FPHUB\Data . The log is fdi.log in this folder. * We are Using the 2nd, newer AHRS device we bought. It enumerates as COM5, and if it fails to enumerate there is a message in fdi.log that says the connection to the COM port failed. * There are two useful scripts in Data that can be invoked via the cygwin shell: ./clean.sh will clean up any stray files in that folder that look like they are leftovers from an experiment. ./archive.sh will create and move any files in Data that look like they are from an experiment to that folder. 2 scripts run @ windows startup via Task Scheduler: C:\multicast_routing.bat -- removes all multicast routes and adds back only the one on the vehicle LAN C:\fdi.bat -- runs `python -m applications.fault_detection.fdi` The FDI task must be imported to the scheduler from an XML task description, which allows the explicit specification of process priority. The priority of this task has to be higher (i.e. numerically lower) than interactive processes. The usual experimental procedure is this: 1) start an FDI mission via the dash. This will dive, power on payload, run experiments, power off payload, surface. 2) when the mission is finished and galene is on the surface, power the payload (either ssh into galene and echo 1 > /dev/loadA6 or send the same command via the dash) 3) RDP into the payload (port 3300 over ethernet, cell or wifi) 4) kill the Python process using Task Manager (it starts whenever the payload boots, but this time we're only booting the payload to retrieve data, so we don't need it). If it is not running then the AHRS failed to enumerate during this boot. This doesn't tell you anything about the previous boot, which is when the experiment occurred, so check the logfile separately, or look for the presence of output files in Data. 5) open a cygwin terminal and use ./archive.sh to move all the experiment files to one folder. This will also include the current boot's files, which you have to delete manually. They are all time-stamped, so it's easy to distinguish, but the log file (fdi.log) can also help. 6) transfer the folder to some shoreside location. I use copy-paste over RDP, but scp is also installed. 7) shut down windows 8) depower the payload To test FDI manually: * power payload (echo 1 > /dev/loadA6) * using Task Manager kill the Python process, which is running FDI * run FDI manually: in a Command terminal cd Code\lrauv-testbed-2019\ python -m applications.fault_detection.fdi control_override The command line argument 'control_override' substitutes for the control that is normally supplied by the FDI_CONTROL LCM channel. To check out the data acquisition devices individually: * For the AHRS use MIP Monitor * For the DAQ use NI MAX To reproduce environment from scratch: * install Python 3.7 and git * git clone lrauv-testbed-2019; cd lrauv-testbed-2019 ; git checkout galene * pip install --user -r requirements.txt * create a myconfig.yaml that specifies the COM port for AHRS and location for data * install LCM via Microsoft vcpkg - git clone https://github.com/Microsoft/vcpkg.git - cd vcpkg - .\bootstrap_vcpkg.bat - .\vcpkg install lcm - add vcpkg\packages\lcm_x86_windows\tools\lcm to user PATH - add the lcm python files in the \\atlas\ProjectLibrary\Persistence Lab\documentation\lcm\for_sites_packages in the Python site packages, replacing the dll files with those from build.