Looking at using both the 50mm & 100mm in a project I'm doing. Xander would probably be the best to answer, but if others have comments, please share.

1) Wondering what additional functionality is added by the RobotC Driver library vs. just programming them as direct motors. I've heard that their encoder readings are different than a normal NXT servo, is this correct? Also, I believe the stall circuitry is not detected properly when just programming them as a standard motor so extra care needs to be taken to ensure you don't try to extent/retract beyond its limits. Is this correct? The Firgelli examples provided with the 3.0b1 library state that ramping is not yet implemented. Is this true? Any idea when/if this will be done? I have a few older driver versions of the library and was wondering if anything specific has changed to the Firgelli code in 3.0b1? I'm not currently using RC 3.51 (but can if necessary).

2) How many encoder counts do you get for the full range of movement on the 50 & 100 versions? What is the approx. length/encoder count? Using the driver library, what is the minimum tick count that can be programmed & successfully executed? I need to move it incrementally (in as small of a tick count as possible) and extend/retract repeatedly and maintain my position. Should this be possible? What problems could I run up against?

3) Unfortunately, my application does not allow me to use the full range of the actuator so my minimum & maximum positions are different than the full-scale values. Given this (and the fact that it does not include an absolute encoder), I'm guessing the best initialization method at program start will be to drive it to a home position so I can be sure it's at the proper home (also necessary since there is no manual movement possible even when powered OFF, so there's no way to manually move it to it's home position). Any ideas on what would be the best sensor approach to use for the home switch to help ensure I can set a reasonably accurate starting position in all cases? I guess the best approach would be to run it at very low speed to allow the code to stop it quickly once home is detected. If the stall detection is included in the driver library, would it be possible to drive it to a hard stop and detect the stall and shut it down there to set the home? If I do this, is there any danger to the actuator? Whatever method I use, I just need a reasonably accurate starting position set each time the application runs.

4) Is the interface to these digital? If so, does anyone know the I2C mapping? Firgelli doesn't appear to provide a datasheet or any information about the actuators.

5) I know this is probably more suited to Firgelli, but when using their NXT-G block in manual mode the movement of the actuators is really herky-jerky (just have their block set in manual in an endless LOOP block). Guessing it has to do with time delays associated with reading the NXT buttons and then jogging the actuator. Does anyone know if this is normal?

1) Wondering what additional functionality is added by the RobotC Driver library vs. just programming them as direct motors. I've heard that their encoder readings are different than a normal NXT servo, is this correct? Also, I believe the stall circuitry is not detected properly when just programming them as a standard motor so extra care needs to be taken to ensure you don't try to extent/retract beyond its limits. Is this correct? The Firgelli examples provided with the 3.0b1 library state that ramping is not yet implemented. Is this true? Any idea when/if this will be done? I have a few older driver versions of the library and was wondering if anything specific has changed to the Firgelli code in 3.0b1? I'm not currently using RC 3.51 (but can if necessary).

I implemented stall detection by checking the current encoder count against a previous count over a specific interval. I am not aware of any stall circuitry but possibly there might be some inside the LA. I have not implemented the ramping simply because I haven't had time. Not many have expressed a burning desire to have it implemented, you're probably the second person to ask about it. It doesn't have very high priority at this moment. No code has changed for quite some time. I have a preproduction LA and it apparently behaves very differently from a standard production variant.

Quote:

2) How many encoder counts do you get for the full range of movement on the 50 & 100 versions? What is the approx. length/encoder count? Using the driver library, what is the minimum tick count that can be programmed & successfully executed? I need to move it incrementally (in as small of a tick count as possible) and extend/retract repeatedly and maintain my position. Should this be possible? What problems could I run up against?

I think it's 2 ticks per mm, so you do the math I'd say the minimum is probably 4 or so. As I said before, YMMV as I have a preproduction one.

Quote:

3) Unfortunately, my application does not allow me to use the full range of the actuator so my minimum & maximum positions are different than the full-scale values. Given this (and the fact that it does not include an absolute encoder), I'm guessing the best initialization method at program start will be to drive it to a home position so I can be sure it's at the proper home (also necessary since there is no manual movement possible even when powered OFF, so there's no way to manually move it to it's home position). Any ideas on what would be the best sensor approach to use for the home switch to help ensure I can set a reasonably accurate starting position in all cases? I guess the best approach would be to run it at very low speed to allow the code to stop it quickly once home is detected. If the stall detection is included in the driver library, would it be possible to drive it to a hard stop and detect the stall and shut it down there to set the home? If I do this, is there any danger to the actuator? Whatever method I use, I just need a reasonably accurate starting position set each time the application runs.

I tend to use a LEGO touch sensor to null a position. I'd use the stall detection as little possible

Quote:

4) Is the interface to these digital? If so, does anyone know the I2C mapping? Firgelli doesn't appear to provide a datasheet or any information about the actuators.

No more digital than your NXT motor

Quote:

5) I know this is probably more suited to Firgelli, but when using their NXT-G block in manual mode the movement of the actuators is really herky-jerky (just have their block set in manual in an endless LOOP block). Guessing it has to do with time delays associated with reading the NXT buttons and then jogging the actuator. Does anyone know if this is normal?

/** * firgelli-linearact.h provides an API for the Firgelli Linear Actuator. This program * demonstrates how to use that API. * * Changelog: * - 0.1: Initial release * * TODO: * - Add ramping support (being worked on, has a few bugs) * * Credits: * - Big thanks to Firgelli for providing me with a Linear Actuator to play with! * * License: You may use this code as you wish, provided you give credit where it's due. * * THIS CODE WILL ONLY WORK WITH ROBOTC VERSION 3.51 AND HIGHER. * Xander Soldaat (xander_at_botbench.com) * 15 february 2010 * version 0.1 */

I'll test to see what happens. If it can't be STOPPED, how can I implement a FIND HOME algorithm? I'll need 2 STOP points, 1 MIN (Home) and 1 MAX (at my MAX extension of the Actuator). This is basically an XY table, here's a couple images of my rig (note that the stops are not yet integrated):

OVERVIEW:

TABLE DETAIL:

Should I do something like this (need to do small moves to ensure I don't overrun the HOME position):

1. Start retract MOVE with a small tick count (say 4) & low speed.2. When isDone() returns TRUE, check to see if HOME or MAX reached.3. If HOME, quit.4. If MAX, do a retract MOVE with a larger tick count & greater speed to get close to HOME. Then start again at 1.5. Otherwise, LOOP.

I can assume the actuator starts somewhere between the MIN & MAX (so I can begin by retracting) but I guess there is a small possibility that it could have been moved below the MIN or above the MAX. Above MAX will be taken care of by above pseudo-code but below MIN won't. I won't implement this to start, but I guess I'd have to use isStalled() to check to see if the motor reaches the MIN end-stop first. Then, if isStalled() returns TRUE change the direction of the homing code to do an extend instead of a retract. With such a small move, will isStalled() still detect a stall condition? Does isStalled() maintain a stall condition even after the current move has completed? It would be good if it did, so it could be checked after the STOP to determine if you bumped into something.

When your isStalled() function returns TRUE, do you automatically STOP the actuator?

Bit of an aside, but is there a reason you named the retract functions with an extra t in the name (i.e. like FLACtretractLA)?

OK, thanks for the STOP option. With regards to STOPPING, how quickly should the actuator actually STOP? Guessing it still makes sense to move it pretty slowly to help reduce momentum and allow it to STOP as soon as possible. I can adjust for this a bit with the actual position of the STOP sensors but I need it to STOP at basically the same location each time.

Can you also comment on the isStalled() questions at the end of my last post.

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum