Date: Tue, 3 Aug 2004 12:11:13 -0400 (EDT) To: Arthur Joseph McClung cc: Alfred Rizzi , Don Campbell Subject: Re: Test Track Woes... Trey; Which supervisor version are you using for these tests? The calibration problem may be due to an older version being used. I don't observe this with our robot with the newest supervisor, but I will go through the code once more as soon as I can. I can't come up with anything obvious from the plots and the descriptions. Apart from the multiple calibration problem, other stuff seems to be some kind of communication problem between the RMCs and the RiSEBus board. I recall you already have a pretty short cable, but we did observe similar (in their craziness, not necessarily in the details) problems with one of our RMCs and short cables seemed to sidestep the problem, even though it is not a "permanent" solution. These kinds of problems are extremely difficult to debug over email. So I am not sure how to proceed. Especially because some of these RMC related problems are related to manufacturing related issues with the boards and assembly, it is very hard to say much with software diagnostic tools. Let me know if these problems are still there or whether they just magically disappeared. The fact that the setup seemed to work a couple days after disassembly ponts to a hardware related RMC problem, in my opinion. Uluc. On Sun, 1 Aug 2004, Arthur Joseph McClung wrote: > Hi all, > We have been running into several issues with the test track leg recently > that have basically brought experimentation here to a standstill. I am > hoping that you may have some suggestions or ideas on what could be going > wrong. > > You may want to download the following pdf for some examples of what I've > been seeing lately: > http://bdml.stanford.edu/~amcclung/Data/Logs/TestTrackLogs.pdf > > Well, starting early last week, we were having some problems with the leg > disregarding the target positions and doing its own thing (see pg1-3). > Many times, this seemed to be trying to move the leg past its 85-90 deg > mechanical limit, or further into the wall that the fixed mount would > allow, both sending us frantically switching off the motor power. After > disconnecting everything and reassembling, everything seemed fine for a > day or so, and we were able to get in some hassle-free testing. > > Then, later in the week, the calibration sequence started acting up. I > started out by checking the hall effect sensor signals on the RMC with a > multimeter, as I moved the magnets near the sensors. After that, I > started logging hall effect and encoder data (see pg.4-5) as I manually > moved the leg to trigger the hall effect sensors. All the sensors and > encoders seem to be working fine and the stack.s logging data, so I was > assuming our RMC is still working fine, but that the stack is sending odd > commands to the motors. > > So, I started logging data as we tried to calibrate. The wing search > during the calibration sequence seems to continue until the leg heads > toward a running configuration, and we have to cut off the power (see > pg.6-7). The only time the leg appears to stop is when the crank starts > in a position near its hall effect sensor. When the crank passes over the > sensor, the calibration stops and the leg thinks it has successfully > calibrated, but the wing angle is related to how far the crank was from > the sensor, and does not leave us in a consistent position as we had > become accustomed to. Looking at the log data, it also seems troubling > that the wing continues to move when the target is constant. > > Another curious behavior that I had noticed earlier happens during > recalibration. If we try to recalibrate the leg, the values that the > stack calibrates to, flip-flop between two sets on subsequent > calibrations. Usually, the leg calibrates to a wing value of 62 and a > crank of 82. Upon recalibration, within the same operator and supervisor > program cycle, the values of calibration change (see pg.8 where I > calibrated 5 times in succession to demonstrate the behavior - the leg is > in the same position at the end of each calibration). > > If anyone wants to look at the data closer, it all can be found at: > http://bdml.stanford.edu/~amcclung/Data/Logs/ > and feel free to ask me to clarify what I was doing in the tests and what > the files are. > > Any help or suggested paths for debugging would be greatly appreciated. I > don.t know much about the inner workings of the RMC and the calibration > routine, but I.m reaching the end of possibilities I can think of. > > Thanks, > Trey > ====================================================================== Date: Sat, 07 Aug 2004 11:17:56 -0700 To: arizzi+@ri.cmu.edu Subject: Re: Stanford RiSE Leg Cc: Arthur Joseph McClung , don campbell , Mark Cutkosky , Al Rizzi , Uluc Saranli , clarkj@stanford.edu, gch+@ri.cmu.edu, Aaron Saunders come to think of it, it's most likely that much of the fatigue life of the encoder wires at this location was claimed during shipping. The test stand and hip have traveled and been shipped in the assembled state with encoder wires pointed up for most of it. So I'm guessing this is not the same problem the guys at CMU and BDI are seeing. Will ====================================================================== Date: Sat, 7 Aug 2004 12:47:21 -0400 (EDT) To: William Provancher Cc: Arthur Joseph McClung , don campbell , Mark Cutkosky , Al Rizzi , Uluc Saranli , clarkj@stanford.edu, gch+@ri.cmu.edu Subject: Re: Stanford RiSE Leg Wow... We have not seen this, but then again, we have not looked for this. The cables in question are relatively well protected and essentially inaccessible on the assembled robot, so I would not have expected this at all. I hope Don and/or Maxon can recomend an easy way to repair this. -Al On August 7 at 08:41:15, William Provancher wrote: > Hmm, it's really surprising to see the encoder wires break like > this. Though if they are going to break, right as they exit the encoder > housing is the place that I'd expect. > > From what I saw, people were being pretty nice to the encoder > cables. Perhaps they are also seeing this problem at CMU? > > > Trey, > Assuming we can fix the cables, perhaps we should put a bit of hot glue or > silicone adhesive on the cables where they leave the housing. > > > Will ====================================================================== Date: Sat, 7 Aug 2004 21:26:23 -0400 (EDT) To: William Provancher Cc: arizzi+@ri.cmu.edu, Arthur Joseph McClung , don campbell , Mark Cutkosky , Uluc Saranli , clarkj@stanford.edu, gch+@ri.cmu.edu, Aaron Saunders Subject: Re: Stanford RiSE Leg Interesting, if true, we have probably "lost" more RiSE parts to transport "issues" than to operation -- well except for the foot flexures :) Either way, I'm planning to take a close look at our motors and cables on Monday. -Al ====================================================================== Date: Mon, 09 Aug 2004 09:17:23 -0400 To: Arthur Joseph McClung CC: Uluc Saranli Subject: Re: Other side of RMC Trey, Thay should be possible in software. I remember a configuration parameter that set whether the hip was "flipped" or not, that might do it. Uluc, do you know the details of this? Thanks, Don Arthur Joseph McClung wrote: > Hi Don, > > The suggestion to try to other side of the RMC seems like a good idea. > As I was contemplating just switching the motor cables and sensor cables > to the #2 slots on the RMC, it occured to me that it will probably try to > control the leg as a left leg, rather than a right leg. Is there an easy > way/jumper setting or simple code variable to change that will allow us > to continue using this leg as a right leg? > > I can probably switch the leg back to a left leg to do some benchtop > testing to determine if the other side of the RMC is working properly. > (That would involve connecting the motor closest to the ground link to > M2B, correct?) But, we would prefer not to switch our entire test track > setup to work as a left leg. > > Thanks, > Trey > ==================================================================== Date: Mon, 09 Aug 2004 09:22:14 -0400 To: arizzi+@ri.cmu.edu CC: William Provancher , Arthur Joseph McClung , Mark Cutkosky , Uluc Saranli , clarkj@stanford.edu, gch+@ri.cmu.edu, Aaron Saunders Subject: Re: Stanford RiSE Leg All, The encoders themselves cannot be replaced, as the assembly is a non-invertible transform! Depending on where the break is, you may be able to cimp on a new connector before the break. if not.... you _might_ be able to carefully remove enough of the casing to attach a new ribbon cable. This might be a very tricky operation.... -Don ====================================================================== Date: Mon, 9 Aug 2004 09:55:30 -0400 (EDT) To: Don Campbell cc: Arthur Joseph McClung Subject: Re: Other side of RMC Well, it is not a very elegant change, but you need to edit two files: RobotCode/Hardware/RiSE_RBHW/HipReader.cc RobotCode/Hardware/RiSE_RBHW/HipWriter.cc In the constructors of these classes, there are statements like the following: _indices[0] = _indices[1] = _indices[2] = 2; _indices[3] = _indices[4] = _indices[5] = 1; which set the RiSEBus indices on the RMC boards for each hip. As you see, "left" corresponds to index 2, "right" corresponds to index 1 on each board. I believe you can simply flip these assignments to access the correct motors. Note that if you connect motors A and B incorrectly, the crank direction will be incorrect. Let me know if this works. Uluc. ====================================================================== Date: Mon, 09 Aug 2004 11:26:17 -0400 To: Uluc Saranli CC: Arthur Joseph McClung Subject: Re: Other side of RMC Thinking of it a little more, it seems to me that you could electrically swap the motor connections and accomplish the same thing. Also, given that the wires to the encoders are shredded, you prbably don't need to try the other side of the rmc! -Don ===================================================================== Date: Mon, 9 Aug 2004 11:35:31 -0400 (EDT) To: Don Campbell cc: Arthur Joseph McClung Subject: Re: Other side of RMC Well, it seemed like some of the other problems they were experiencing were not encoder cable related. I don't know the pinout of the motors, so I am not sure whether the shredded cables are of any effect (i.e. are they index channels and such?) Also, as Don said, swapping the motors may also produce the same effect, but they would still need to change their custom gait RC files to use the left leg instead of the right leg. Trey, if you think that's not a problem, perhaps you could try that first. I am not 100% sure that there would not be a difference due to some other thing that is differentiated in the software between the left and right side hips though. I am getting too old to remember the details of all this software. Uluc. ====================================================================== Date: Mon, 9 Aug 2004 12:20:07 -0400 (EDT) To: Don Campbell Cc: arizzi+@ri.cmu.edu, William Provancher , Arthur Joseph McClung , Mark Cutkosky , Uluc Saranli , clarkj@stanford.edu, gch+@ri.cmu.edu, Aaron Saunders Subject: Re: Stanford RiSE Leg I just took a close look at the RiSE robot at CMU. As best I can see there is no stress/damage to the cables entering the encoders. I suppose in extremely rough opperation there is some chance that they could be damaged, but I doubt we have been able to do anything that abusve to the robot yet. -Al