============================================================================ Subject: Re: Leg limits and setup From: "G. Clark Haynes" To: Arthur Joseph McClung Date: Fri, 25 Jun 2004 17:38:34 -0400 ---Executing: shownonascii This message contains non-ASCII text, which can only be displayed properly if you are running X11. What follows may be partially unreadable, but the English (ASCII) parts should still be readable. > Very exciting work presented today! Its starting to look more and more > like we have a legit project. I think I remember hearing that wing angles > above 75 may cause joint conflicts, thus the robot climbs with legs at > 45deg and returns the legs at 30 deg more (ie. 75deg). I just wanted to > verify before we begin any testing on the new leg, and put some safety > checks in the interface that easily creates RC files for CustomGait use. Yes, Joel and I started out doing joint limits at 80°, but the wing hits a hard limit, and also scratches against a gear. The actual hard limit occurs somewhere around 80°, but there's also a lot of play in the gears, so we settled at 75°. YMMV. > Also, I was hoping to get the new leg up and running sometime next week, > so I was wondering what might be the best way to get some advice on the > hardware setup (email or should I try to schedule a phone call to > you/Uluc/Aaron/other about getting everything in the right place). I'm mainly a software guy, starting to get some "real robot" experience. Uluc, Don, and Hal are the main electrical guys. If Uluc has time, you should contact him first and foremost. Good luck! ============================================================================ Date: Mon, 28 Jun 2004 10:11:28 -0400 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/200401 13 X-Accept-Language: en-us, en To: Arthur Joseph McClung Subject: Re: Hardware setup for RiSE leg X-B2B2C-MailScanner: Found to be clean X-B2B2C-MailScanner-SpamCheck: X-Status: Arthur Joseph McClung wrote: > Hi Don, > > We happily received the new leg and hardware earlier this week, and I am > in the process of having some undergrads finish up some testing on the old > track this week, for a rollout of the new leg next week. In preparation > for that, I may need some help getting all the pieces together in the > right places. For ease of description, I have included pics of our > current hardware. Our current stack is configured for RHex use, and I'm > guessing that several of the top boards may need to be replaced by the new > motor control and power boards. I'm just not certain which boards should > be swapped and what connectors go where. So I was wondering what might > be the best way to get some advice on the hardware setup (email or should > I try to schedule a phone call to you/Uluc/Aaron/other about getting > everything in the right place). Trey, All that you need in your stack is the cpu, power supply and the RiSEBus Bridge card (optionally, you may want wireless as well). I think that there are possible address-space conflict with the RHio card, so you should remove that card at least from the stack. The RMC connects via the 6pin (5wire) connector. You will likely want to extend this cable! I use H2021-ND (H1504-ND terminals) and H2051-ND from digikey. There are 4 possible places that this connector fits, the correct one it that which is closest to the power regulator. For power, use a WM3600-ND (with WM2500-ND terminals) to a bench supply (16v, 3A). I recommend that the power to the PC/104 supply and the power to the RMC be electrically isolated from each other to avoid ground loops. The motors should connect to the headers marked M2A and M2B (the motor closest the ground link should connect to M2B). The 8 pin connector should connect to the header marked "Sense2" on the RMC. Extending this lead might be a bit tricky, as the connectors are not digikey parts. They are Harwin Datamate (4+4) connectors, I think they may be available from newark. I think email works pretty well, if you aren't in a huge rush. -Don ============================================================================ Date: Mon, 05 Jul 2004 10:23:41 -0400 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/200401 13 X-Accept-Language: en-us, en To: Arthur Joseph McClung CC: Uluc Saranli , "G. Clark Haynes" , Haldun Komsuoglu , Aaron Saunders , Alfred Rizzi , Mark Cutkosky Subject: Re: Setting up the new leg in Stanford X-B2B2C-MailScanner: Found to be clean X-B2B2C-MailScanner-SpamCheck: Arthur Joseph McClung wrote: > Hi Uluc, > > Thanks for the tips on setting up the hardware to work with the new > leg/hip. I plan on tackling this a bit this weekend and have something > working by Mon. I think I have a good idea of how to configure the boards > for the stack now, and I've made cable extensions for all the necessary > connections (I think). I was wondering it the cable length will be an > issue in any of these cases. I have made the following extensions: > > 4'6" long serial-type cables to the 2 enocoder/motor cases (to go from our > workbench to the test track) > 4'6" long cable from RMC Sense to sensors (Hall effect) > 8" long cable from RMC to stack > 3' long cable for power to RMC > > What type of power does the RMC require (voltage, current), and can this > be the same as the stack power? 15v, 6A will do nicely, and it "should" be different than the stack power to eliminate ground loops, though I don't really know how serious a requirement this is. > > Also, in terms of software, I think I may have an idea of what needs to be > done, but it would probably be good to verify first. I have already > copied most of the contents from the CF card to a backup CD in case we > ever need to go back to the old prototype for some additional testing. > So, it seems that I should change the environment settings (in .profile) > to match the RoboDevel settings. Then, copy the new RoboDevel structure > to the stack and do a make clean and make. Please advise me if I'm on > track or not. (Would it be easy to set up a separate CF for the new leg, > and just interchange them if we need to change platforms? - Dont know how > hard it would be for me to install QNX on it since we dont have a usable > version running on any of our machines, I think we have QNX 4 on 1 rarely > used, outdated machine here.) I would strongly recommend against compiling anything on the lippert, it takes forever and causes excesive wear on the flash disk. If you have an old machine lying around, I'd strongly recommend installing a more recent QNX on it and compiling there. > > Will and Miguel reconfigured the leg from a left leg to a right leg (to > work with our test track setup) by changing a few things around with > Aaron's help. After the reconfiguration, I'm not certain which place to > connect to the RMC (Sense 1 or 2 and M1A/B or M2A/B). You should probably connect it to Sense 1, and M1A/B. A/B assignment should swap from what I previously told you...M1A to the motor closest to the ground link. > > The final step being to connect the leg and RMC, cross my fingers and hope > for the best. > > One final thing before I forget again - how difficult would it be to get a > digital output to correspond to leg activation. We are currently using > this as our LabView trigger to start data collection. it may be pretty tricky, there are no digital outputs on the RMC that are available fot the user. You could possibly attach a wire to one of the LEDs; the orange portion turns on when the motor drives get enabled. (this is done in the firmware, I think, not at the PC side, so there should be pretty low latency between the motor activating and the LED turning on.) You guys had asked about measuring the motor current with the labview system....I'll see what I can suggest sometime today. -Don ============================================================================ Date: Mon, 05 Jul 2004 10:30:51 -0400 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/200401 13 X-Accept-Language: en-us, en To: Arthur Joseph McClung Subject: Re: Setting up the new leg in Stanford X-B2B2C-MailScanner: Found to be clean X-B2B2C-MailScanner-SpamCheck: Oh, something that I forgot to mention: please avoid plugging the motors into the RMC while it's powered up (by either the batteries or the RiSEBus connector) -Don ============================================================================ Date: Mon, 5 Jul 2004 11:41:21 -0400 (EDT) X-X-Sender: To: Arthur Joseph McClung cc: "G. Clark Haynes" , Haldun Komsuoglu , Aaron Saunders , Don Campbell , Alfred Rizzi , Mark Cutkosky Subject: Re: Setting up the new leg in Stanford > 4'6" long serial-type cables to the 2 enocoder/motor cases (to go from our > workbench to the test track) > 4'6" long cable from RMC Sense to sensors (Hall effect) These cables are quite long and I am not sure whether they would cause problems or not. especially for the encoder signals that come from the motors, this may be a problem. Furthermore, the cable may add significant resistance to the motor terminal voltage command, which would change and limit the performance of the control. Try them out first and if you observe problems, you could shorten them, I guess. > 8" long cable from RMC to stack > 3' long cable for power to RMC These sound fine to me. > What type of power does the RMC require (voltage, current), and can this > be the same as the stack power? I am not sure whether Don sent you the RMC document or not, but there are two distinct power sources required for the whole system. The RMC's have a bunch of digital and analog circuitry, which take their power directly rom its connection to the stack. The power cable coming out from the RMC is purely for the motors. It is fed into the motor drives and that source will be the one where all the motor current is drawn from. That is why you need a separate power supply with high current capability. You could use a motorcycle battery for this, but that would be 12V instead of 15V and that would make the performance of the control suffer a little bit. You would need to change some configuration values. Alternatively, you could get rechargable hobby batteries we use in RHex with which you would be able to obtain 15V. I don't have the part numbers for those but perhaps people from the group could chime in with pointers. > Also, in terms of software, I think I may have an idea of what needs to be > done, but it would probably be good to verify first. I have already > copied most of the contents from the CF card to a backup CD in case we > ever need to go back to the old prototype for some additional testing. > So, it seems that I should change the environment settings (in .profile) > to match the RoboDevel settings. Then, copy the new RoboDevel structure > to the stack and do a make clean and make. Please advise me if I'm on > track or not. (Would it be easy to set up a separate CF for the new leg, > and just interchange them if we need to change platforms? - Dont know how > hard it would be for me to install QNX on it since we dont have a usable > version running on any of our machines, I think we have QNX 4 on 1 rarely > used, outdated machine here.) As Don suggested, I strongly recommend against compiling any sources on the stack. I believe you already have a user in bassoon.msl.ri.cmu.edu, so if you don't want to install a local QNX compile host, you could use that machine for a while. Essentially, all you need on the stack's CF is the supervisor executable, the configuration files and the proper environment variable settings. RoboDevel/README.txt explains the environment variable settings. RoboDevel/RiSE has scripts to copy the supervisor and config files from the compile host to the stack (in particular, upload_sup.sh and upload_config.sh). So, in summary, these are what you would need to do: - Edit your .profile on bassoon based on instructions in README.txt - Checkout (or update) RoboDevel on bassoon - make clean and make in RoboDevel (with the proper variable settings, this should compile the RiSE code) - On the OCU(Operator control unit) laptop, checkout or update RoboDevel - make clean and make on the OCU's RoboDevel - Login to the stack as root. Create a user called "rise". - Edit .profile for the rise user on the stack based on instructions in README.txt. This will make sure that you have the right variable settings for executing the supervisor. Whenever you need to run the supervisor, you will need to login as "rise" and the "su" to root. - Assuming you have the control stack in peer-to-peer mode with the wireless: - On the OCU, go to RoboDevel/RiSE and run "upload_sup.sh amcclung@bassoon rise@stackname" "upload_config.sh amcclung@bassoon rise@stackname" - This will transfer the supervisor executable and config files from the compile host (bassoon) to the stack. Note that all the config files on the stack will be overwritten, so make sure to save the ones you have changed on the robot. - ssh to rise@stackname - su - cd Roboevel/RiSE/Supervisor - run ./start.sh At some point, I will write more detailed instructions for these in the official documentation, but until then, let me know if any of this did not make sense and I can elaborate on the details. The thing is, with all the different groups, different network and host setups, it is really hard to write a single documentation to cover all possibilities. > One final thing before I forget again - how difficult would it be to get a > digital output to correspond to leg activation. We are currently using > this as our LabView trigger to start data collection. As Don pointed out, one of the LED's on the RMC (the red one) lights up when the engines are enabled. This does not necessarily correspond to when the legs start moving, or when the custom gait mode is enabled, but it should be better than nothing. On the RMC, there is a "combo" LED, which has a yellow and red LED on it. The yellow one toggles when the RMC receives communication packets from the stack. The red one indicates whether the motor drives are enabled or not. I hope this helps. Uluc. ============================================================================ Date: Fri, 9 Jul 2004 18:47:09 -0400 (EDT) X-X-Sender: To: Arthur Joseph McClung Subject: Re: Setting up the new leg in Stanford X-Status: Trey; The file you need to edit is RoboDevel/RiSE/RobotCode/Hardware/RiSE_RBHW/RiSEBusHW.cc on bassoon. The reason I cannot change it myself and commit is because this change will be only specific to your experimental setup. Anyway, in that file, you will see a section which looks like: risebus[RBHW_FrontBus] = new RiSEBusDriver( RBHW_FrontBus ); risebus[RBHW_MiddleBus] = new RiSEBusDriver( RBHW_MiddleBus ); risebus[RBHW_RearBus] = new RiSEBusDriver( RBHW_RearBus ); risebus[RBHW_BodyBus] = new RiSEBusDriver( RBHW_BodyBus ); In this section, comment out the last three lines. These lines create drivers for each of the buses and the card we sent you only has one bus functional. After commenting them out, put in the lines: risebus[RBHW_MiddleBus] = NULL; risebus[RBHW_RearBus] = NULL; risebus[RBHW_BodyBus] = NULL; to make sure that the software does not try to access them. I have not actually tested this, but I think it should work. Note that the software will be thinking that the leg you attach is one of the front legs. Whether t is the left or right one depends on which axis you attach it to on the RMC. Let me know if this works. I will be heading home now, but I will check email. You can also reach me on my cell phone (412) 915 1835. Uluc. On Fri, 9 Jul 2004, Arthur Joseph McClung wrote: > Hi Uluc, > I am just getting back into the lab for real work today, and continuing > the process of getting the new leg operational. I am running into > a continual error message that just fills the screen: > > RiSEBusDriver : Failed to collect node info!!! > > I am currently using all of the original length cables (so there > shouldn't be a cable problem). > > After starting the GUI with: > ./start.sh 3000 bailorgana > I start to get the messages. From here I can click connect to > activate all the modes, but I'm not sure if its safe to continue. > > Any ideas on the error message, is it just looking for the other > motors and boards? > > Thanks, > Trey > -------------------------------------------------------------------- Uluc Saranli Postdoc, Robotics Institute http://www.cs.cmu.edu/~ulucs Carnegie Mellon University phone : (412) 268 3260 5000 Forbes Avenue fax : (412) 268 5571 Pittsburgh, PA 15213 email : ulucs+@cs.cmu.edu ============================================================================ Date: Sat, 10 Jul 2004 11:36:27 -0400 (EDT) X-X-Sender: To: Arthur Joseph McClung Subject: Re: Setting up the new leg in Stanford X-Status: Trey; I will have to run some experiments myself today to see what may be causing the problem. I will let you know if I can locate the problem. Otherwise, the last resort would be for me to test the second bridge board that I had built here and send it to you guys. Iknow that one has one of the channels faulty, but it would be possible to assign that to be the "body" channel and disable it, which would not cause problems. One thing you can look at to see whether the RMC board is receiving any messages is whether the yellow LED on the RMC is flashing. It will looks like it is on because it would be flashing at 500Hz. I will let you know what I can find out. Uluc. On Fri, 9 Jul 2004, Arthur Joseph McClung wrote: > Hi Uluc, > > I have tried a version with the changes you suggested, and it seems to > cause the stack to hang each time. As soon as I run './start/sh' on > the stack, it freezes. The last screen message is 'MsgLogModule > initialized'. > > Also, even when I try to run the code w/o the changes, I am getting no > response from the motors when I try to Calibrate. > > Any suggestions, > Trey > ============================================================================ Date: Sat, 10 Jul 2004 15:12:08 -0400 (EDT) X-X-Sender: To: Arthur Joseph McClung Subject: Fixed the issue X-Status: Trey; I just tested and committed changes to HipReader.cc and HipWriter.cc which were neglecting to check the pointers to the RiSEBus drivers for being NULL. I tested it on the robot and it seems to be working when I set the pointers for the middle and rear buses to NULL. Give it a try. By the way, the best way to see whether the communication with the hip is working or not is to wiggle the leg manually and see whether the encoders are responding or not. You should see the dials on the health interface (once connected) move appropriately with the motion of the wing and crank. If that does not work, do not even try to enable the motors because that probably means the communications are not working properly. Let me know how it goes. Uluc. ============================================================================ Date: Sat, 10 Jul 2004 20:07:23 -0400 (EDT) X-X-Sender: To: Arthur Joseph McClung Subject: Re: RMC problems in Stanford Based on your descriptions, your setup seems to be correct. First, answers to your questions: > Are the V(voltage) and I(current) measurements at the bottom of the > Health monitor for the power to the motors? These are not yet correctly operational. You can just ignore the readings. > Does the dial represent crank angle and the bar represent wing angle, > with corresponding degrees readings below? Correct. > What are A,B & D and what are the green and red boxes on the > side of the numeric angle values? These are motor A and B and drive temperatures. Not yet operational due to bus bandwidth issues. > Is there just ONE connection between the RMC and the stack (6 wires to > RiseBus)? (that ALWAYS connects to the matching connector near the > voltage regulator?) Yes. If the LEDs are flashing, then I can only assume the connection is correct. There is one potential trouble, which is the 5V supply to the node. To my knowledge, the bridge that you had should have this properly wired up. Just in case, I will send you the pinouts for the bridge and you can check whether the 5V is being properly delivered to the RiSEBus connector. > The only other data connections to the RMC are the Sense1, M1A and M1B > connections, is this true? Well, either side should have worked fine. Both MCUs are being powered up and being communicated with, so I either one should work fine. > Does the encoder power come from the stack? ( or is it necessary to > have the 16V motor power on also to get the encoders working?) Yes, it comes from the stack. The RiSEBus cable ships GND, 3.3V and 5V to the nodes (i.e. RMC) as well as two cables for signal. The sixth cable is a duplicate ground. > Should the encoders be working after I have 'connected' (clicked > CONNECT) to the robot prior to calibration? The encoders should be working as soon as you execute the supervisor, but they will only be visible in the user interface once you click on CONNECT. The thing I suspect strongest is the 5V supply to the node, which was a problem we had here in CMU in the first couple days of the robot. I will send you the pinout of the connector later tonight. If that turns out not to be the problem, there isn't a whole lot I can do without having access to the RMC board. You can try the other two encoder connectors to see whether you get any response from them or not. One pair is for the front right hip, the other pair is for the front left hip. The associated sense connectors are labeled 1 and 2 (or 2 and 1, I am not sure which one is which). I will try to send you some more software changes that may help us debug any obvious issues, but I cannot think of too many things that could cause the problem. Worst case scenario, we may need to do some FedExing around next week. Perhaps it is a firmware issue as we never had the chance to test that RMC with the stack here in CMU. Uluc. On Sat, 10 Jul 2004, Arthur Joseph McClung wrote: > Hi Uluc, > > The program seems to be running now, but the Health monitor does not > show any changes. Before the latest code update, the voltage seemed to > be be a constant 15.6V, now it remains at a constant 10.8V. Also, the > encoders do not seem to be working. I have tried all 4 combos for M1 & > M2 (A/B) for motor and Sense 1 & 2 connections, just in case some > weren't working, or a node was malfunctioning. For each setup, I > powered everything up and connected (clicked CONNECT) to the stack, > then wiggled the leg around, but did not 'Calibrate'. > > BTW, the connection between RMC and RiSEBus seems fine, I see the 2 > green LEDs illuminated after I start the Supervisor on the stack. > > Any ideas on other things I should check to debug the encoder situation? > > Thanks again, > Trey > ============================================================================ Date: Sun, 11 Jul 2004 09:56:43 -0400 (EDT) From: Uluc Saranli To: Arthur Joseph McClung Subject: PC104 bridge schematics and RiSEBus pinout Trey; I have attached the schematics for the PC104 bridge. If you need the schematics and documentation for the RMC, only Don can provide that due to the NDA agreements. Page 9 includes the pinout for the RiSEBus connector, which is as follows: 1 -> SDA0 2 -> SCL0 3 -> GND 4 -> VDD (3.3V) 5 -> GND 6 -> VCC (5V) The 6th pin appears unconnected in the schematics because Hal did some routing trick that requires an external jumper. Please check whether all these signals are coming through correctly, especially the 5V. If not, it is highly likely that that is our problem. Otherwise, we will see. Uluc. ============================================================================ Date: Sun, 11 Jul 2004 18:19:00 -0400 (EDT) X-X-Sender: To: Arthur Joseph McClung Subject: Re: PC104 bridge schematics and RiSEBus pinout Trey; On the bridge board, there is supposed to be a via hole which is right by where the sixth pin of the connector is soldered. That via, I believe, has 5V and should be jumpered to the pin to supply the 5V. This is apparently a "hack" that Hal had to do to be able to do the routing of the board. Anyway. doing that jumpering should solve the problem. I had thought, as Hal had put that board together himself, it was already done, but I guess it was not. I discovered the necessity of this a couple days after we had shipped you the board. Anyway. On an unpowered board, you can check that that via is connected to the 5V supply with a voltmeter. And then, once plugged in, you could make sure it has 5V. Yoyu can then solder a little piece of metal jumper to the 6th pin, which should supply the necesary 5V to the RMC. the 2.5V is probably because of other connections in the RMC, I don't think it is any "short" or anything on the bridge board itself. Uluc. On Sun, 11 Jul 2004, Arthur Joseph McClung wrote: > Uluc, > Looking at the RiSEBus board, the 6th pin really appears to be unconnected. > I'll try to send a pic in a couple of hours. > -Trey > ============================================================================ Date: Mon, 12 Jul 2004 09:18:32 -0400 (EDT) X-X-Sender: To: Arthur Joseph McClung Subject: Re: PC104 bridge schematics and RiSEBus pinout Cool! The calibration position you described is correct. Following calibration, you should see that the health monitor angle displays jump and you should see that the wing and crank angles are correct relative to the specifications in CONVENTIONS.txt under RoboDevel/RiSE As for the mode switching, currently, the mode supervisor looks for all the legs to detect successul calibration. Until I find a more elegant solution, you will need to change one more file in your bassoon instance of RoboDevel. Go to the file RiSE/RobotCode/Behaviors/modes/RiSECalibMode.cc. There, you will see three functions: RiSECalibMode::isCalibrating, RiSECalibMode::isFailed and RiSECalibMode::isCalibrated each of which loop thrugh all six legs to determine overall calibration status. Change those to only look for leg 0 or 3 (depending on whether your motors are connected to the left or right hip). Leg numbering is also explained in CONVENTIONS.txt. That should do it. Be very careful not switching modes until you are sure that you have got this right. Otherwise, with wrong calibration, the wing angle will servo beyond physical limits of the mechanism, which may stress its structure. If you do notice the wing hitting hard stops, disconnect power right away to avoid damage to the hip assembly. Stopping the supervisor will do it too, but disconnecting power disables the motors faster and is safer. After all, we don't know whether all the bugs in the firmware are cleaned up. Also, your RMC has a slightly older firmware, which does not have a couple of the minor fixes we did very recently. Let me know how things go. Uluc. On Sun, 11 Jul 2004, Arthur Joseph McClung wrote: > Uluc, > I think that did it. After connecting power to the pin, the encoders seem to > work fine now, and I can get motion now when I 'Calibrate'. > > What position is calibrate supposed to leave the legs in? (in the simulation,> they seem to be straight out, parallel to ground, but on this leg it is approx> 45deg wing, with the top of the crank around 1PM, directed back toward the > motors, is this ok?) > > Is there anything special that I need to do to access the other modes? (after > calibration, only leg #4 becomes calibrated and the others remain BUSY. i > suppose this keeps me from activating other modes with uncalibrated legs) > > Getting closer to fully operational! > Thanks, > Trey > ============================================================================ Date: Mon, 12 Jul 2004 09:18:32 -0400 (EDT) X-X-Sender: To: Arthur Joseph McClung Subject: Re: PC104 bridge schematics and RiSEBus pinout X-Status: Cool! The calibration position you described is correct. Following calibration, you should see that the health monitor angle displays jump and you should see that the wing and crank angles are correct relative to the specifications in CONVENTIONS.txt under RoboDevel/RiSE As for the mode switching, currently, the mode supervisor looks for all the legs to detect successul calibration. Until I find a more elegant solution, you will need to change one more file in your bassoon instance of RoboDevel. Go to the file RiSE/RobotCode/Behaviors/modes/RiSECalibMode.cc. There, you will see three functions: RiSECalibMode::isCalibrating, RiSECalibMode::isFailed and RiSECalibMode::isCalibrated each of which loop thrugh all six legs to determine overall calibration status. Change those to only look for leg 0 or 3 (depending on whether your motors are connected to the left or right hip). Leg numbering is also explained in CONVENTIONS.txt. That should do it. Be very careful not switching modes until you are sure that you have got this right. Otherwise, with wrong calibration, the wing angle will servo beyond physical limits of the mechanism, which may stress its structure. If you do notice the wing hitting hard stops, disconnect power right away to avoid damage to the hip assembly. Stopping the supervisor will do it too, but disconnecting power disables the motors faster and is safer. After all, we don't know whether all the bugs in the firmware are cleaned up. Also, your RMC has a slightly older firmware, which does not have a couple of the minor fixes we did very recently. Let me know how things go. Uluc. On Sun, 11 Jul 2004, Arthur Joseph McClung wrote: > Uluc, > I think that did it. After connecting power to the pin, the encoders seem to > work fine now, and I can get motion now when I 'Calibrate'. > > What position is calibrate supposed to leave the legs in? (in the simulation,> they seem to be straight out, parallel to ground, but on this leg it is approx> 45deg wing, with the top of the crank around 1PM, directed back toward the > motors, is this ok?) > > Is there anything special that I need to do to access the other modes? (after > calibration, only leg #4 becomes calibrated and the others remain BUSY. i > suppose this keeps me from activating other modes with uncalibrated legs) > > Getting closer to fully operational! > Thanks, > Trey ============================================================================ Date: Mon, 12 Jul 2004 14:02:52 -0400 (EDT) X-X-Sender: To: Arthur Joseph McClung Subject: Re: PC104 bridge schematics and RiSEBus pinout (fwd) X-Status: Hmm. The crank should always end up close to where the hall effect sensor is. As I said before, you can check by ensuring that the crank angle displayed after calibration matches with what the actual crank angle is on the leg with reference to CONVENTIONS.txt. If not, I would worry that the hall effect sensor on the hip is not fully operational. Does the crank, during calibration go more than 1 revolution? What should happen is the wing going up and seeking the wing hall effect first. Then, the crank should start rotating and after at most one full revolution, it should stop right at where it goes over the hall effect sensor. Uluc. On Mon, 12 Jul 2004, Arthur Joseph McClung wrote: > Joel, > > In light of Dan's recent email, maybe I should direct my latest simple > question toward you.... > > After calibration, should the legs be in the same position every time? It > seems that the wing angle is always close to 45 deg (by CONVENTION.txt), > and the crank varies - 0deg, 90 deg, 120 deg, -10deg, etc. Just want to > verify before I try anything. > > We discovered a few unforseen hurdles this weekend (related to using just > 1 leg and a small hardware issue), so testing on the new leg has yet to > begin. Thus, there probably not be any new data from this end on leg > and foot usage at the telecon today, but hopefully some by the end of the > day. > > Thanks, > Trey ============================================================================ Date: Mon, 12 Jul 2004 18:34:41 -0400 (EDT) X-X-Sender: To: Arthur Joseph McClung Subject: Re: Setting up the new leg in Stanford X-Status: Trey; Earlier, there was a software stop which made sure that the wing DOF did not get past the hall effect trogger. However, this limits the maximum wing angle to about 65 degrees, which is way too low for climbing purposes. So, we had to disable that and we now rely on correct encoder readings for avoiding the hard stops. By the way, I am fairly certain that the calibration module would report failure if the crank hall effect sensor was not detected. So, unless both the wing and the crank sensors fail, there should not be any danger apart from miscalibration. Actually, if nothing got screwed up in the modifications I suggested to the CalibMode, you should not even be able to switch modes in case of calibration failure. Uluc. On Mon, 12 Jul 2004, Arthur Joseph McClung wrote: > Joel, Aaron & Uluc, > (anyone feel free to chime in with advice on any part of my message) > > OK, it seems to be functioning decently now. But, the crank was > definetely not stopping above the magnet earlier, I guess I just need to > keep an eye on it when we're doing the calibration. Also the mounting > arms for the wing angle hall effect sensors seem to be unconstrained. I > can move both of them freely with my hand. Did we miss a screw in the > re-assembly or it there something else? It looks like they could be fixed > relative to each other, and then both relative to the rest of the frame. > How does software handle hitting the hard stops, does it care if it > reaches a hall effect sensor, or just continue in a gait? > > Thanks, > Trey > ============================================================================