RiSE Leg Status

The RiSE leg is currently DECOMMISSIONED!
The RiSE prototype leg is currently NOT ACTIVE
(Note: The RiSE leg is one leg from the current robot design)
(Note: The RiSE prototype leg is a acrylic mockup of the real leg, used by Stanford for early tests)
Link to emails (attachments):

---

Latest News (02/21/05)

• The laptop has been reconfigured to handle both the full robot platform and the single RiSE leg
  • The single RiSE leg acct is 'riseold'
  • The full RiSE platform acct is 'rise'
• A new acct was made to just handle the RiSE leg
  • The environment variables were updated for the new acct to compile properly
  • The RoboDevel tree was successfully compiled under the 'riseold' acct

---

Next steps

• Mount the test track to the new climbing wall
• Mount the servo motor to the new wall
• Mount the control stand (to hold the RiSE stack near the track) to the new wall
• Continue with testing

---

History (reverse chronological order)

• Had to redirect symbolic link to a different RiSEPanel to get OCU working properly
  • Used RiSEPanelNEW080904.cfg to eliminate 'Amulet_Error'
    • Switched to 06/05/04 version from a backup on THEDARKSIDE
  • In the dir RoboDevel/RiSE/Operator
• Needed to do a 'make distclean' on RoboDevel/Libraries/fltk to prevent the tree from trying to access stuff in the 'rise' tree, and causing compile errors (02/21/05)
• Copy the previous RoboDevel tree to the new 'riseold' acct (02/14/05)
• Backed up the current working RoboDevel tree for the single RiSE leg before Feb05 SwRI trip (01/26/05)
• Re-made the sensor wiring connector for the leg hardware(08/16/04)
  • The crank hall effect sensor wire had a flaky connection to the connector
    • The multi-strand wire had many borken strands and this caused intermittent contact to the connector leads (see pictures [1] [2])
    • The connector probably was not meant to endure as many connects/disconnects that we do with the test track
  • All wires had to be cut to repair the connector
  • A new connector and wire extension were added for the repair (see pictures [3] [4] [5])
    • Hot glue and zip-ties were added near the end of the connector to reduce damage from use
  • New connector WORKS!!! - Test track is back up!
• Having trouble with calibration on the crank (8/13/04)
  • Switched to desktop setup for debugging
  • Hall effect sensor seems sketchy (bad cable?)
    • Documented in logged data (calibI.mat)
    • Probed RMC w/multimeter as magnet was passed over sensor (3.3V->~0->3.3V)
  • Magically started working all of a sudden on desktop (w/all test track cabling - ie. long cables)
  • Reassembled leg on test track, but still not calibrating crank
    • Crank hall effect shows intermittant response to magnets (at RMC level probe)
• See StanfordFootDesignTests for flexure/foot issues related to testing (8/13/04)
• Fully reassembled the RiSE leg on the test track (8/9/04)
  • WORKS! - Ran gait #13 successfully
• Repaired the encoder cables by replacing the original cable (see pictures [1] [2]) (8/9/04)
  • Cut some ribbon cable and added a 10pin connector
  • Soldered a new cable onto the encoder board (see pictures [3] [4])
  • Reassembled encoder housing and added hot-glue to cable base (see picture [5])
  • Tested the connection to the board
  • Tested the calibration routine w/stack and seems to be fine
• The encoder cables seem to have at least 2 broken wires
  • Upon careful inspection (see pictures [1] [2]), one of the motor encoder wires seems to have a few broken wires as a result of excessive stress
    • POSSIBLE CAUSES:
    1. When the leg is mounted, the cable side with 2 broken wires is the topmost
       • The weight of the extended test track cables and the general motion of the cables during testing may have just worn out these side wires over time
    2. Testers may have over-estimated the robustness of the cables and not handled them as gently as required
  • Upon further attention to encoder readings, they appear to work (ie. both change values when the leg is manually moved), but they change with the same magnitude, different signs (ie. (-1,1),(-5,5),(-23,23))
    • This called for a closer inspection, where only one motor was moved at a time, and later led to noticing the damaged cable
  • This may explain why the leg was intermittently working somewhat recently, depending on how the setup was assembled
• The RiSE leg is having trouble w/calibration
  • The wing search for the hall effect continues to move until it is necessary to cut the motor power
  • The encoders respond to manual leg manipulation, and the logged data resembles what is seen on the leg
  • The leg seems to be ignoring the targets (not holding constant when target is constant)

• Would like for calibration to have less significant wing setting
  • Just pull the track back against its torsional spring during calibration, of course with your other near the power switch
• The test track is up and fully functional
  • People other than Trey have been able to use it with ease
• The track distance from wall should be adjusted for each test setup
  • To account for aggressive calibration
  • To account for foot size/depth
• RiseLegClimbingParameters has been updated to describe the trajectory parameters
• RiseLegTestInstructions has been updated to give step-by-step test procedures
• The datcyl OR foot prototype can easily be exchanged
• Carpet backing and foam similar to CMU tests are available for testing
• Updated the software for easier test track use
  • Debugged GUI w/ new Test Track button
    • Added "rise_test_track.rc" to gait_list.rc on bassoon (to be uploaded by upload_all.sh)
    • Modified GUI with Panel editor and saved RiSEPanel.cfg on lordvader
  • Altered GaitBuilder code to produce properly formatted RC files for Test Track button use
    • Added ';' to GBwritegait.m formatting to have usable files
• Altered RoboDevel code for Stanford use
  • Mode manager will now only look for leg#3 (#4 by convention) for calibration
  • All buses and nodes will not be continually polled (ie. no continuous error messages on screen)
• The RiSE leg is mounted on the wall
  • Calibration was successful with cable extensions
  • Its important to watch the messages and keep a hand on motor power in initial testing
    • Watch for strange syncronization messages and harmful motions
• The RMC cable was fixed
  • The green wire come out of the soldered crimp on the RMC to RiSEBus cable
  • Soldered it back in place
• Shortened the motor/encoder and sensor cable extensions to the RMC board to ~20in
  • Tested cables for continuity
  • Tested on benchtop - seems to work OK, but continue to pay attention
• After Calibration, only the connected leg (#4) was recognized as calibrated
  • Other operational modes were not accessible with uncalibrated legs, namely the CustomGaitMode
    • CustomGaitMode contains the gaits that will be used for the Stanford Test Track
  • The mode manager was set to only look for a specified leg (test leg #3)
• The RMC did not seem to be recieving 5V for the encoders to work properly.
  • Vdd is 3.3V as desired
  • Vcc is nominally 3.3V, then drops to 2.55V when the supervisor program is started on the stack
    • Vcc powers the encoders
  • After receiving pinouts on the RiSEBus, it was found that a jumper was missing that supplies Vcc=5V to the encoders on the RMC
    • The jumper was added and the encoders work fine now
    • The leg can now be "Calibrated" in the GUI
• The RiSELeg encoders did not seem to be responding. Thus it was not recommended to activate the leg.
  • All encoder connections were tried on the RMC (M1A? , M1B? , M2A? , M2B? )
  • Both sensor connections were tried in conjuction with the motors (Sense1, Sense2)
  • The RMC seemed to be communicating fine to the RiSEBus board (the green LEDs pulse @ 500Hz)
• The single node issues has been resolved
  • Upon activation, the stack was giving: RiSEBusDriver : Failed to collect node info!!!
  • The body, mid and rear leg nodes were set to NULL
  • The code was updated to determine that some nodes are not present
  • Code was updated and recompiled
• Power supply
  • The dual supply power supply was used to give 16V & 3A (may need 6A?)
• Longer cables
  • The cable extensions were made
  • 4.5ft encoder cables (2)
  • 4.5ft sensor cable (hall effect)
  • 8in RMC to RiSEBus
  • 3ft power to RMC
• Connectors for longer cables
  • Ordered connectors from DigiKey and Newark Electronics
  • Add part no. here
• Reconfigure stack
  • Remove RHio, Motor controller boards
  • Add RiSEBus board

-- AMcClung? - 11 Jul 2004