LINUX ENVIRONMENT STUFF
==============================================

CVS (Concurrent Versions System) Notes
----------------------------------------
Commands used from Linux machine with CVS variables set

Basic Commands (ie. cvs add )
   * add =   add file to list of CVS known files
   * remove = removes file from CVS list of known files
   * commit = send all locally changed files
   * update = get all changed files
Other Commands
http://www.loria.fr/~molli/cvs/cvs-tut/cvs_tutorial_toc.html#SEC1

UPDATE character flags
   * ? repository is unaware of file
   * M locally modified
   * A locally added, but not committed
   * R removed local copy (use CVS remove to remove from list)
   * U new file from repository
   * P the file has been patch (CVS will merge changes from different section)
   * C conflict

To get a user directory from CVS, use 'cvs co users/amcclung'
CVS has plenty of space, so use different directories for various programs
Common command: cvs update RoboDevel



VI Editor
----------
Used on LINUX and QNX

Basic Commands
   * :x (save & exit)
   * :q! (?<=>save w/o exit)
   * i (insert mode)
   * ESC (back to command mode)
Other Commands
http://www.cs.rit.edu/~cslab/vi.html

Common command: vi 



EMACS Editor
-------------
Can use 'EMACS &' to get window and continue w/terminal prompt
Can use EMACS ANGE to edit files remotely
Format to remotely open files: <~//login@machnie:{file location}>
Example of use locally at CMU: ~//bassoon:/home/users/amcclung/...
   * Make remotely on bassoon, then copy executable to stack (ssh -1 bassoon)
Basic Commands
http://www.stedwards.edu/science/baker/help/emacsonly.html



SCP - Secure Copy
--------------------
Use to securely copy files

Can create script to do the SCP for you (.sh script)
   * see 'copy_files.sh' on BASSOON

Usage: 'scp  :'



SimSect - Integrator Engine - Hexapod Model
------------
Compilation of modules on Linux results in SimSect model (ex. USERS/AMCCLUNG/TEST01)
SimSect RC is different from standard RC
PDF Document, derivation details
   * i=leg1, i=0,no contact   i=1, contact
   * j=leg2, j=0,no contact   j=1, contact
Not recommended for single leg model
   * would have to define model state transitions (touchdown, takeoff, other states, etc.)
   * ground contact model will be involved w/SimSect
   * SimSect code is without good documentation (just wait to CDL from Clark & Jonathan)



RC - Configuration Files
-------------------------
Many of the standard RC files are at SWRI/CONFIG/DEFAULT/*.RC
RC files do not compile, they are just editable text files
String and float variables can be specified in RC files
SimSect RC file use is different from standard RC

Use the CUSTOMGAITMODULE class to create path profiles
   * parameters (node(time),angle,dir(motor),stop flag)
   * NODE = time
   * ANGLE = motor position
   * DIR = direction of motor, leaving the node (-1=-ve, 0=closest, 1=+ve rotation)
   * STOP = determines if this node should be used as a transition point between gait modules
   * In the GUI, SPEED is used to stretch profile (period)
   * Various profiles can be defined, but must maintain same period

Use commands to get RC variable in code
   * see HTML document for additional documentation
   * include default values in case the named info does not exist
   * ie. V=GETFLOATSYMBOL("name",default val)
Reading config files is like adding to a dictionary
   * all variables from RC files go into same space
   * you must call a specific name (ie. name variables appropriately)
   * good to get variables in INIT function rather than control loop/UPDATE 
      * getting variables from RC can be time consuming
   * can also use C++ file operations to read text file from MATLAB (2 columns of data)
      * need to determine how to get values into correct form for use in code

RC file placement can prevent another file from being read
   * The search path for READCONFIG files:
   * 1)current dir 
   * 2)$CONFIG_DIR 
   * 3)$ROBOT_DIR

Modify TREY_GAIT.RC to redefine leg profile in AMCCLUNG_TEST (on RHex stack)
   * The source file for TREY_GAIT.RC is TEST_EXAMPLE (TEST_GAIT.RC)
   * similar modification for POSCONTROL.RC for sin amp/period control
Search for "custom_gaits" to determine where TREY_GAIT.RC is added to GUI
   * GAIT_LIST.RC (MAYBE) diff structure on the stack (SWRI->Supervisor)
   * This file seems to list all .RC's that should be loaded


LOGGER - Data acquisition on stack
----------------------------------
Can save variables or various hardware values thru GUI selection
   * ie. desired leg angle, actual leg angle, velocity, current, torque, battery, pos[i]
The stand alone LOGGER is SWRI_LOGGER in RHEX/OPERATOR
   * use SWRI_LOGGER in a way similar to the linux host './start.sh'
   * Usage : SWRI_LOGGER 3000 robotname(or IP)
Variables should pop up in LOGGER window after stack connects

Use the PROXY to enter variables into LOGSERVICES
   * can include code vars for logging via LOGSERVER
   * see AMCCLUNG_TEST.CC & CONTROLLERMODULE.CC example

Commands to route stack messages to host (NOTE: Al & Uluc set this somewhere?)
   * MSG_LOG_CLI 3000 host 0 2555 , this will route messages to terminal
   * 3000 is the port, 0 and 2555 are priority codes



RHEX General
-----------------------------
Useful commands
   * ./START.SH -D   = start the stack program, disabling the keyboard except for Ctrl-C
      * NOTE: Have to be root on the stack
   * ./START.SH 3000 robotname(or IP)   = start the host GUI and connect to robot
      * Use the version in RHEX/OPERATOR to get GUI

See ROBODEVEL/README.TXT for description of code hierarchy 
   * 3 main directories are RHex, Libraries, RiSE
   * the user interface GUI is in OCUCODE 
   * RHex specific code is in ROBOCODE

Position control is generally used 
   * see INCLUDES->POSITIONCONTROL.HH for description of control
   * see POSCONTROL module (HTML documented)
   * use POSITION[I], then derive VELOCITY[I] (take derivative, see POSCONTROL example on stack)

Hall effect sensors are the two connections coming out from the motor
   * different wires are for different mounting positions of the motor (L,R)

Gains are in MKS units
Time variables in code are DOUBLEs, the units are SECS
Use UNDERSCORE for internal parameters (as convention)
Gyro calibration message does not mean anything
   * generally. no text is printed during stack run
The function MMMESSAGE is bad since it takes lots of memory/time to display
   * other message forms - MMWARNING, MMFATALERROR


RHEX Modules
------------
RHEXADDMODULE 
   * ??standard modules for encoder and position control are generally included
   * ??for standard operation, all parameters are defined
   * Must actuate one module before MainLoop is called
   * Compile modules separately (using Makefile in the directory)
      * this produces an executable
   * Modules are specified with a pointer, period, priority, and type (related to priority)
   * see MODULEMANAGER.HH for priority ordering  (logging, sensing, computing/actuation)
      * guidelines for priority ordering
   * SUPERVISOR is just another module that keeps track of the others (updated at 1ms)
   * see HTML doc -> Module class for additional info


RHEX Hardware
-------------
Frame modules w/INITHARDWARE and CLEANUPHARDWARE for any HW layer (SimSect, Robot) to work properly
   * module calls are blind to hardware implementation
For long, non-motor related program processes, disable DRIVE.ENABLE (motors)
   * Motor should only be enabled when in use, otherwise disable
Look in DRIVEHW.HH for DRIVE.ENABLE function
Usage example CLASS::INSTANCE->DRIVE.ENABLE(1,--)
Can use DIGITALHW class/library to access LEDS on stack
   * include DIGHW.HH, then control w/SETBYTE(0,LEDBYTE)


RHEX GUI Notes
--------------
Can use panel editor (FLAME by Jay) to alter GUI menus
   * NOTE: Use 'Dismiss' as OK must SAVE TEMPLATE to make changes permanent
Can SAVE PANEL to overwrite RHEXPANEL.CFG (same loc as below?)
   * look in /OPERATOR/... for RHEXMODES.CFG (lists all modes)
User can use GUI->SUP to remotely start/stop stack & connect
Various custom gaits variations can be selected by moving the slider
   * L GAIT = less than -0.5
   * NEUTRAL GAIT = from -0.5 to 0.5
   * R GAIT = greater than 0.5


Other
------------
QNX is on stack, that's why code must compile in QNX
   * much better than RT Linux

QNX setup stuff
   * location of network settings /etc/rc.d/ rc.local
   * ROUTE ADD DEFEAULT (gateway settings)
   * use IFCONFIG  to set (or check) up the network setting
   * Usage: IFCONFIG ETH0
   * look at .PROFILE settings for proper environment settings
      * may also be in ENVIRONMENT.SH (use . .ENVIRONMENT.SH to execute&update the vars)

EXAMPLES dir has code to test various parts on hardware, under TESTTOOLS on the new tree
   * these examples just create simple modules and execute locally w/o linux host (ie. another machine)

Useful Commands
   * SHUTDOWN -F   = To reboot quickly
   * SHIFT-Q-Q    = Exit GeomView
   * ESC-ESC    = Auto-complete on QNX
   * ~.       = Terminate QNX (or Linux) login or program that may be hung
   * MAKE DEPEND   = Recompile and recheck dependency files for updated headers
   * MAKE CLEAN   = Remove the object files (file tree)

MAKEFILE editing
   * add .CC files to EXEC
   * add depending .CC in SOURCES (see example)

EXT PROFILER can be used to define other profile transitions (other than cubic splines) 
   * documented in HTML

Send ?s to Uluc for Q&A



Code Update Cycle
-------------------
1) Edit files either locally and copy to QNX machine (bassoon@CMU) or remotely on QNX machine
  -Secure remote login:      ssh amcclung@bassoon.msl.ri.cmu.edu
2) Compile and debug files on QNX machine
3) Commit changes to CVS folder (ie. copy files to CVS repository)
4) Copy source files and executables to RHex stack (use scp or COPY_FILES script that Uluc wrote)
5) Run directly from stack, or from Linux host


File Description
-------------------
AMCCLUNG_TEST.CC
   * adds PROXY module, CONTROLLERMODULE
   * uses nodes and angle to specify leg trajectories
   * uses TREY_GAITS.RC => TREY_GAIT.RC
   * uses CONTROLLERMODULE.CC

AMCCLUNG_TEST.RC
   * sets rhexloggerbasefile to POSCONTROL_TEST

CONTROLLERMODULE.CC
   * uses CUSTOMGAITMODULE and LOGSERVER
   * reads TREY_GAITS.RC

TREY_GAIT.RC
   * Describes a set of gaits (or leg profiles)
   * 3 turn (gait) options - neutral, leftturn, rightturn
   * can define times, angles, directions, stop_flags for many structs (to be used as leg profiles)
   * the smoothing and gains can also be set

TREY_GAITS.RC
   * Lists the custom gait RC files to load

POSCONTROL_TEST.CC
   * uses ProfilerModule
   * uses pos[i] and vel[i] definitions to define leg trajectories
   * uses timer to dictate position and stop
   * sends counter to LEDs
   * currently uses SIN function

Somecode
---------
May want to reintroduce TIMER, then grab CONTROLLER after KEYHIT
   * MMKEYBOARD is not good if called every ms on the stack (try 50ms)


TODO
===============

Primary path
---------------
Edit code to read file "profile_gait.rc"
Change MATLAB outfile file to be similar to TREY_GAIT.RC
Check on binary output

Secondary path
---------------
Check on GUI status
-standard gaits
Compile with new custom RC files for GUI

NOTE:Added line for TWikiChanges 02/10/04

-- AMcClung? - 28 Jan 2004