View Full Version : Swerve with a twist
Harshizzle
28-05-2015, 17:01
So after a discussion with my mentor about swerve drive, we thought of a potentially new drive system that is swerve like but a bit different.
What we pictured was a swerve module where the wheel was extended out from the center of rotation.
(top view- The o represents an axle going through the computer screen).
_
| |
| |---o
|_|
When the wheel is powered, and the o axle is prevented from spinning (perhaps using a brake system), the robot would move in the direction the wheel is spinning.
When the wheel is powered and the o axle is allowed to freely rotate, the wheel would turn in a circle, and could end up pointing in a direction you want it to.
With both those combined, the robot could have holonomic drive capabilities.
The biggest problem I see with this is the weight distribution, as the force would be on the o axle, which would not be touching the ground (or maybe it could hmm...). I also dont see this as very practical for an FRC game, because swerve would probably be much faster at orienting itself.
But this drive system would make every swerve module require only one motor and one braking system, which in some industrial applications, could be better.
Anyway, does this already exist somewhere? If not, thoughts?
What we pictured was a swerve module where the wheel was extended out from the center of rotation.
(top view- The o represents an axle going through the computer screen).
_
| |
| |---o
|_|
Could you please post a hand sketch showing top, front, and side views? I cannot form a confident mental image from that ASCII art.
When the wheel is powered and the o axle is allowed to freely rotate, the wheel would turn in a circle, and could end up pointing in a direction you want it to.
Do you have a way of making sure the robot won't move forward while the wheel turns in a circle? After all the forward force is still there. Maybe you can turn 2 modules at a time, letting the other two modules brake the robot, but that's much slower than a traditional swerve.
The biggest problem I see with this is the weight distribution, as the force would be on the o axle
How about the load on the cantilevered wheel axle?
But this drive system would make every swerve module require only one motor and one braking system, which in some industrial applications, could be better.
Yeah, this is a cool idea.
If you're looking to use less motors though, there's always crab drive
Yeah, this is a cool idea.
If you are confident you have a proper understanding of what the OP is describing, would you be willing to draw and post the requested hand sketch?
orangemoore
28-05-2015, 17:58
I don't see how this is better than swerve drive. Is just sounds more complex.
Harshizzle
28-05-2015, 18:00
Could you please post a hand sketch showing top, front, and side views? I cannot form a confident mental image from that ASCII art.
https://gm1.ggpht.com/Vu9RquG_V3mx0Cyqyx9A9iCgM6N0QNP8EKf0PugA0mmndl_zRx zO9N8oWCak7UQqUlkCJ_TPkVhXwLPlF3AHGNz-Fz-J9V-huZuxuAl7ISzapFxhGito4qkyedziBvQk6SCmYe-YsbWwtCSCaF5U3INf31cCGWyJkIG1sx1XDGQO-1FzzUBt6LH2Nhoev-Ea9qbERttmfocRgIpQp-fnRZdb70wtuY78j6UtWuFhD_SbyChXKZx8SxDb3iVkbwmQMRIz yaCuzga6inXMKWyBhDQNVpDYwFC5jnJdoMyYd2OsvQwwOVRyGb N8wYVvpTD2chK5TiO3UTSpVPsTiXJs27fBAqkcqKtK9f4zQHmN lOgjNl_dHMuG2aT138yCunXT43R8VEqRHSxUFjmcbEb-gtkoiF45AQY37EG6TysEHSLxwX3a9xxwql6jiTBDUViDVuFUoj lXHa7jHsbpREsA6vZ0j_4zM6brBsxT_UJezVGCXMPskJvSPmxw 8tiW5hEHTjPh0ILhdLO-ECDQd2vWwP6sp6YC44cr-480DVIAIiz3UNXKnTbQyFifKFSQDWOqPJWpEBqsGFN5RxJDql3 HHLus-e4J4A-9ZqQ=w1345-h568-l75-ft
Apologies for the darkness, but this is what I had in mind
https://gm1.ggpht.com/Vu9RquG_V3mx0Cyqyx9A9iCgM6N0QNP8EKf0PugA0mmndl_zRx zO9N8oWCak7UQqUlkCJ_TPkVhXwLPlF3AHGNz-Fz-J9V-huZuxuAl7ISzapFxhGito4qkyedziBvQk6SCmYe-YsbWwtCSCaF5U3INf31cCGWyJkIG1sx1XDGQO-1FzzUBt6LH2Nhoev-Ea9qbERttmfocRgIpQp-fnRZdb70wtuY78j6UtWuFhD_SbyChXKZx8SxDb3iVkbwmQMRIz yaCuzga6inXMKWyBhDQNVpDYwFC5jnJdoMyYd2OsvQwwOVRyGb N8wYVvpTD2chK5TiO3UTSpVPsTiXJs27fBAqkcqKtK9f4zQHmN lOgjNl_dHMuG2aT138yCunXT43R8VEqRHSxUFjmcbEb-gtkoiF45AQY37EG6TysEHSLxwX3a9xxwql6jiTBDUViDVuFUoj lXHa7jHsbpREsA6vZ0j_4zM6brBsxT_UJezVGCXMPskJvSPmxw 8tiW5hEHTjPh0ILhdLO-ECDQd2vWwP6sp6YC44cr-480DVIAIiz3UNXKnTbQyFifKFSQDWOqPJWpEBqsGFN5RxJDql3 HHLus-e4J4A-9ZqQ=w1345-h568-l75-ft
Error 403 (http://www.chiefdelphi.com/forums/attachment.php?attachmentid=19057&stc=1&d=1432850604)
You can attach the sketch to your post. No need to upload it elsewhere.
Ryan_Todd
28-05-2015, 18:04
^^^ no image
Also, here's a quick Inkscape job:
Peyton Yeung
28-05-2015, 18:05
I guess I still don't understand how this works.
Somebody already posted a pic, so this would be a repeat post.
I feel like this would introduce a lot of variables which hamper reliability, which are not seen in a normal swerve. Your module pivot becomes a lot more sensitive to variations in terrain, weight distribution, and small variations between the modules, for example. The steering code would be no simpler, and in fact may take on new layers of complexity since your motors are performing double-duty. Some maneuvers, such as spinning while translating, would likely become more difficult to control.
It may seem simpler on paper, but I worry that you're in fact introducing things that will generate a whole lot more trouble for you. In my never-ending quest to learn how to effectively and quantitatively assess design simplicity (ironically, a very complex problem), I've become increasingly convinced that "minimize actuator count at all costs" is a crude and shortsighted way of approaching the problem.
Harshizzle
28-05-2015, 18:13
Do you have a way of making sure the robot won't move forward while the wheel turns in a circle? After all the forward force is still there. Maybe you can turn 2 modules at a time, letting the other two modules brake the robot, but that's much slower than a traditional swerve.
How about the load on the cantilevered wheel axle?
Yeah, this is a cool idea.
If you're looking to use less motors though, there's always crab drive
Preventing the forward movement could have a lot to do with the load distribution on the modules. Braking does seem like a viable option however.
The load on the cantilever would be something to eliminate from this design, that's true.
Crab drive sacrifices individual module control for the loss in motors though.
Harshizzle
28-05-2015, 18:20
Absolutely, this design solves little simplicity wise.
I primarily see its merits in an industrial setting. Repeatable holonomic actions could be performed, especially when engines are large and hard to fit into a compact design.
TheHolyHades1
28-05-2015, 18:23
Are you suggesting something like what I've attached?
19059
I developed this with a former team member for a project earlier, but haven't around to actually programming for it. Below is a photo of the completed system. Admittedly the wiring is a bit messy - we got around to cleaning that up and it looks a lot more functional now, but I don't have any photos of that at the moment. It's sitting in a box, unfortunately.
19060
EDIT: I read through your post again and realize that this isn't quite what you're suggesting. Something like what GeeTwo is suggesting below me seems a lot closer to what you're suggesting.
If I understand correctly, you would essentially be making a gearbox which shifts between two outputs: One would power the wheel rotating against the floor, and the other output would control the orientation of the wheel. To make this work, you would still need a separate shifter control for each wheel to toggle between the states, so you would still need 2N controls where N is the number of wheels. You would also have an interesting time driving and steering simultaneously; you would have to switch back and forth for each steering maneuver. If you're simply after reducing the number of motors, it might make more sense to provide a (reversible) clutch from the drive shaft that can borrow a small fraction of the drive torque in order to steer. I still suspect that the extra complexity of the system would outweigh the reduction in motor count for most FRC purposes.
Repeatable holonomic actions could be performed
Highly doubtful.
The steering is not independent of the direction of wheel speed. You can't make bi-directional steering corrections while maintaining wheel speed. Such actions are required for simultaneous 3DoF maneuvers.
I see GeeTwo said much the same thing in the preceding post.
But I also see there is still much confusion about exactly what the OP has proposed:
When the wheel is powered, and the o axle is prevented from spinning (perhaps using a brake system), the robot would move in the direction the wheel is spinning.
When the wheel is powered and the o axle is allowed to freely rotate, the wheel would turn in a circle, and could end up pointing in a direction you want it to.
... so a clarification by the OP would be much appreciated.
EDIT: I read through your post again and realize that this isn't quite what you're suggesting. Something like what GeeTwo is suggesting below me seems a lot closer to what you're suggesting.
Your original interpretation (and sketch) seems to comport more closely with the OPs original post*:
When the wheel is powered, and the o axle is prevented from spinning (perhaps using a brake system), the robot would move in the direction the wheel is spinning.
When the wheel is powered and the o axle is allowed to freely rotate, the wheel would turn in a circle, and could end up pointing in a direction you want it to.
*assuming there are no steering motors
Are you suggesting something like what I've attached?
If the boxes at the top of the steering modules are motors or servos, I don't think so.
A bit off topic, but your robot reminds me of a linkage drive I played with a few years ago that "shifted" from forward to transverse driving through the regular drive motors. The idea was that the steering of the wheels were coupled so that the left front and right rear pointed the same direction at all times, as did the right front and left rear. Adjacent wheels steered in opposite directions. At one end of the 90 degree range of steering, all pointed "forward" and at the other, all pointed "transverse". When driving forward, the two left wheels were controlled to have the same speed, and the two rights. When driving transverse, the two forwards would match, and the two rear wheels would match. In each of these states, there was theoretically no net torque seeking to shift from one state to the other (practice wasn't so kind). To "shift" from forward to transverse or back, one diagonal pair was driven clockwise, and the other counterclockwise for a second or so. Eventually I realized that it was really just a lobster drive that required four proportional controls. Originally, I had ideas that it could also settle in a "rotate" state halfway in between the other two, but I could never find or hold that state without even more complexity and possible points of failure.
Addendum: also, due to more to lack of fabrication skills and tools than the design, it was probably the ugliest machine I've ever built.
If the boxes at the top of the steering modules are motors or servos, I don't think so.
Good point. I only looked at the first link and didn't see any motors there and so inferred there weren't any.
Good point. I only looked at the first link and didn't see any motors there and so inferred there weren't any.
Ether passes the Turing test! (sometimes he seems too perfect to be human)
TheHolyHades1
28-05-2015, 21:18
Good point. I only looked at the first link and didn't see any motors there and so inferred there weren't any.
The black boxes are steering motors, whose outputs are directly attached to the swerve modules beneath them. There is no clutch / braking system of any sort.
TheHolyHades1
28-05-2015, 21:20
If the boxes at the top of the steering modules are motors or servos, I don't think so.
A bit off topic, but your robot reminds me of a linkage drive I played with a few years ago that "shifted" from forward to transverse driving through the regular drive motors. The idea was that the steering of the wheels were coupled so that the left front and right rear pointed the same direction at all times, as did the right front and left rear. Adjacent wheels steered in opposite directions. At one end of the 90 degree range of steering, all pointed "forward" and at the other, all pointed "transverse". When driving forward, the two left wheels were controlled to have the same speed, and the two rights. When driving transverse, the two forwards would match, and the two rear wheels would match. In each of these states, there was theoretically no net torque seeking to shift from one state to the other (practice wasn't so kind). To "shift" from forward to transverse or back, one diagonal pair was driven clockwise, and the other counterclockwise for a second or so. Eventually I realized that it was really just a lobster drive that required four proportional controls. Originally, I had ideas that it could also settle in a "rotate" state halfway in between the other two, but I could never find or hold that state without even more complexity and possible points of failure.
Addendum: also, due to more to lack of fabrication skills and tools than the design, it was probably the ugliest machine I've ever built.
This reminds me of one of 1640's robot drives, called a "twitch" drive. They credit 1565 for the original idea. You may want to check it out here: http://wiki.team1640.com/index.php?title=Twitch
Harshizzle
28-05-2015, 21:45
^^^ no image
Also, here's a quick Inkscape job:
Yeah, this is exactly what I was attempting to describe.
There are two states, one where the o axle is allowed to coast, and one where it is not.
I agree, for FRC purposes this would create far more problems than it would solve. But I wanted to bring it up for discussion anyway.
This design cannot do simultaneous steering and moving with any sort of accuracy, but in cases when that is not needed (I'm picturing something like an amazon warehouse robot), this could be an option.
This reminds me of one of 1640's robot drives, called a "twitch" drive. They credit 1565 for the original idea. You may want to check it out here: http://wiki.team1640.com/index.php?title=Twitch
Yes, that's the same effect I was talking about. Mine had no diagonal linkages; each wheel's rotation was linked to the two adjacent wheels.
seanthompson
30-05-2015, 00:35
Rather than using a braking system, it seems simpler to me to have a shifting "swerve" drive, where one gear rotates the module, then shift into the other to drive the wheel. This has the same effect of only using 1 motor, and the robot can not move and rotate its wheels at the same time. It also eliminates the need for a braking system, and gets rid of some nasty math. However, it would be a lot of shifting...
Rather than using a braking system, it seems simpler to me to have a shifting "swerve" drive, where one gear rotates the module, then shift into the other to drive the wheel. This has the same effect of only using 1 motor, and the robot can not move and rotate its wheels at the same time. It also eliminates the need for a braking system, and gets rid of some nasty math. However, it would be a lot of shifting...
For ball shifting and dog shifting, when you shift, the other gear becomes free spinning right? So when you are turning your wheels the wheels would be free, which is not much of a problem. But when you are driving, won't your wheels be free to turn randomly? Unless you use a brake...:rolleyes:
MoistRobot
01-06-2015, 12:36
Ether passes the Turing test! (sometimes he seems too perfect to be human)
Or it's becoming even MORE clever and is trying to convince you it's human!
Okay Ether, read the following and respond as quickly as possible-
It's your birthday. Someone gives you a calfskin wallet...
Ryan_Todd
01-06-2015, 16:04
Yeah, this is exactly what I was attempting to describe.
[...]
This design cannot do simultaneous steering and moving with any sort of accuracy, but in cases when that is not needed (I'm picturing something like an amazon warehouse robot), this could be an option.
Thanks for confirming my interpretation.
Personally, I would be less interested in this concept as a "Plan A" design than as a case study in control systems design. As discussed above, this still has the same total number of outputs as a traditional independently-steered swerve drive, but it nonetheless manages to be an under-actuated system; this would therefore save relatively little in cost and complexity, while giving up a fair amount of controllability in the process. If you're looking to save on cost and complexity, after all, it's hard to beat a good old-fashioned skid-steer setup.
Don't get me wrong, however, because I strongly believe that this project would still be completely worthwhile-- and indeed, quite valuable in the real world! The key is to shift gears a bit, and instead view this as a research project.
As a software engineer in the automotive industry, I always need to be mindful of the fact that the real world isn't perfect; things go wrong all the time, and my work needs to be able to take that in stride. As a result, my job is not simply to get my component to work right, but rather to ensure that even if the rest of the system is compromised to the point where my component cannot work right, it will still never work wrong. If that means slowing down the engine to prevent it from overheating (or stopping the engine altogether to prevent it from exploding), then so be it!
This kind of thinking is essential whenever the end user's safety is at stake, and strongly advisable in many other applications.
With this in mind, can you see a way that it might be helpful to have an understanding of how to control a swerve drive platform, even if one or more axes of control are disabled, modified, or behaving abnormally?
(It may, for example, be advantageous to design a swerve drive specifically to allow for the possibility of falling back to an alternative control scheme like the one described above.)
What would be better is a powered caster. By offsetting the steering axis but having it rotated 90 deg from your design you can achieve true Holonomic omnidirectionality. The steering axis imparts a velocity that is orthogonal to your rolling axis. No matter what the configuration of the pods, you can instantaneously move in any direction. There is a nice closed form solution for the inverse kinematics. We built a munition loader for the navy using this approach. I've debated about trying it on a FIRST robot with 3824. Good summer project. I've got a publication on it if anyone is interested
Kevin Leonard
02-06-2015, 08:14
(It may, for example, be advantageous to design a swerve drive specifically to allow for the possibility of falling back to an alternative control scheme like the one described above.)
Dude that would be so cool.
A steering motor burns out, so somehow the robot shifts into using the drive motors for both drive and steering.
I'd love to see that implemented by someone (although probably not on an FRC robot, that sounds far too complex and unnecessary. If a motor burns out in a match, its probably better to just wait two minutes until the match is over and repair it.)
If you want holonomic omnidirectionality (swerve is by definition non holonomic, the system discussed here is likewise non holonomic), here is a link to a fact sheet on a system we developed that uses powered casters which provided holonomic omnidirectionality using conventional tires.
http://web.ornl.gov/sci/ees/eesrd/res/OCILOW.pdf
Its a slight twist on the swerve (e.g. in-line orientable wheels) and the conventional car steering topology discussed here. It's the third option for a powered steering/rolling system. OCILOW - Off-Center In-Line Orientable wheels (e.g. a fancy way of saying powered caster). By having the steering axis offset from the rolling axis and behind the wheel rather than next to it, the steering axis causes a velocity vector that is orthogonal to the rolling axis. Coordinated control of the steering and rolling enable instantaneous velocity vectors in any direction (e.g. holonomic) using conventional tires. You get very cool catenary type coordinated motions of the wheels, no skid while transitioning instantaneously from forward to sideway motion. The system is very robust and is highly redundant. You can still have full holonomic control with only two wheel pods active, the one or two being passive casters. It had a very cool double enveloping worm gear to drive the rolling axis. The challenge is the controls. If you have 4 active pods, you have 8 motors to control 3 degrees of freedom (x, y, theta). However, there is a closed for solution for the inverse kinematics, solving for the instantaneous velocities for all rolling and steering motors giving a desired Cartesian velocity vector (x_dot, y_dot, theta_dot). The cool part is that, no matter what the wheel pod configuration (if you look at the picture, we intentionally got the steering axes all different), it can still instantaneously move in any direction.
My group actually developed the split hub spherical wheel in the mid 1990s which was similar to the mecanum. We built a weapon loading system for the Air Force but the tires would wear out fast. It had a 7 DOF force reflecting arm on a holonomic omnidirectional platform. One person could load a 2000 lb weapon on the wing of an aircraft feeling the wedging and jamming when loading the weapon on the wing pylon. The holonomic motion was necessary for navigating under the wing. Unfortunately, like the mecanum, you have point, rather than surface, contact with the ground so your traction is low and tire stresses are high (not good when handling a bomb). If you really want/need holonomic omnidirectionality and you want to use conventional tires, it's the only way.
swerve is by definition non holonomic
Please post a link to the definition referred to above.
I've got a publication on it if anyone is interested
Please provide a link to your paper, or post it here.
The best paper I've seen was by Wada and Morit, "Holonomic and Omnidirectional Vehicle with Conventional Tires" in 1996 IEEE Int. Conf on Robotics and Automation. Unfortunately, they didn't provide the closed for solution for the inverse kinemtatics . However, figure 1 in the paper says it all. Just take a minute and look at it and it will explain why you will never, by definition, get holonomic omnidirectionality with a swerve.
http://ftp.imp.fu-berlin.de/pub/Rojas/omniwheel/00509272.pdf
I'll dig up our work on OCILOW.
Just take a minute and look at it and it will explain why you will never, by definition, get holonomic omnidirectionality with a swerve.
http://ftp.imp.fu-berlin.de/pub/Rojas/omniwheel/00509272.pdf
The word "swerve" appears nowhere in that paper. Please define what you mean by swerve in the context of your previous post ("swerve is by definition non holonomic").
The word "swerve" appears nowhere in that paper. Please define what you mean by swerve in the context of your previous post ("swerve is by definition non holonomic").
Swerve is what everyone is FIRST is calling the in-line orientable wheel, figure 1 a) in the paper.
Swerve is what everyone is FIRST is calling the in-line orientable wheel, figure 1 a) in the paper.
"Swerve module" is the phrase most CD folks use to refer to an in-line orientable wheel like figure 1 a) in the paper.
"Swerve" usually refers to a vehicle using swerve modules in a particular way.
This is from page 3671 of the paper you linked:
In the past, four wheel steering vehicle[7] has been developed. The vehicle has steering wheels with conventional tires and can move in the omnidirection by orienting all wheels in the same direction
Is the above-quoted description your intended meaning of swerve in your earlier statement "swerve is by definition non holonomic"?
Or are you claiming that a swerve vehicle with four swerve modules -- each of which can be steered and driven independently of the others -- is "non holonomic" ?
Or did you mean something else entirely ?
bobcroucher
02-06-2015, 14:13
My son Bryce, has dreamed of trying to implement what he refers to as "caster drive" for FRC for a couple of years now. It took me a bit of pondering to understand the differences.
It's not that swerves can't move in the same directions, but if you don't want wiggling or squirming in unintentional directions at first, you really need to wait until the steering motors find their correct directions before powering the drive motors. In real use, the steering motors can get oriented up to the maximum required 90 degrees in less than 0.25 seconds, so we don't actually wait. For an FRC weight robot running on carpet, it's just not necessary.
The magic of the caster, is that by gradually mixing the steering rotation and the driving rotation into a cross blended function, you can achieve any motion direction instantly and with zero slip other than that due to the width of the tire. The tire will scrub only slightly due to differing path lengths for the inside and outside of the tire. Think of pushing a cart with 4 casters, not 2 like a shopping cart, you can make it move in precisely any direction with no wheel slippage, regardless of wheel direction. A powered robot is the same mechanically, except that the forces come from the wheels to move the cart, instead of the cart moving the wheels. The key is that any desired vector of motion can be expressed as the weighted sum of the two perpendicular directions created by the steering and drive wheel motors. The downside is that it takes a lot of simultaneous accurate control of both steering and driving motors. Is it worth it for FRC? I kind of doubt it, but I hope someone tries it in the off season some year, and decides to unveil it during build season anyway.
The 1996 paper referred to above has some nice drawings and graphs of the kinematic problem, which I've never seen before. Thanks for sharing.
The magic of the caster, is that by gradually mixing the steering rotation and the driving rotation into a cross blended function, you can achieve any motion direction instantly and with zero slip other than that due to the width of the tire.
"gradually mixing" and "instantly" seem like odd bedfellows in the same sentence.
Suppose I am driving your caster vehicle directly forward and I want to "instantly" go sideways? How is your caster vehicle superior to a properly designed and coded swerve?
Good summary Bob and you're son is extremely bright. The controls actually are fairly easy. Tracking errors are stabilizing instead of destabilizing. e.g. if one of the casters is off, the reaction forces due to the other casters push it in the right direction. We implemented this on a large system for the Navy. It had a 10,000 lb payload capacity and could position loads with sub mm accuracy. When we first powered it up, we didn't have the gains right on two of the drives. We drove it around for days and didn't notice.
One of the items I loved about our drive train was the double enveloping worm gear. We do a lot of printing and I've debated about trying to print the OCILOW drive with a complex worm drive. We had some kids design and print an OCILOW out last year but they used chains for the drive.
"gradually mixing" and "instantly" seem like odd bedfellows in the same sentence.
The motion in the desired direction can begin instantly. However, after the steering has rotated a bit, the lateral motion of rotation changes and "gradual mixing" of driving motion with the steering motion is required.
Suppose I am driving your caster vehicle directly forward and I want to "instantly" go sideways? How is your caster vehicle superior to a properly designed and coded swerve?
Apparently less than 1/4 second. A swerve drive with no trail must first be steered to the proper direction before applying drive to achieve motion only in the desired direction. With trail (offset between the two axes), the steering motion itself begins the motion in the desired direction (along the drive wheel axis).
This is not a meaning of holonomic I have seen before - I suppose it would have to be "having the ability to immediately move in an arbitrary direction while in any arbitrary state"
I guess I should have had my wife edit my sentences.
Correct. If you are going to stop and change direction, swerve is fine. But if you want truly holonomic omnidirectionality, being able to move and rotate in any direction without the swerving action, casters are a better solution. I was just trying to show a different solution. Whether anyone wants to try it makes no difference to me.
If you are going to stop and change direction, swerve is fine.
If you want to make a really tight right angle turn, you're going to have to come to an effective stop anyway because you can only get so much traction. I don't think that the fraction of a second where your steering motor happens to be pushing you in the right direction is going to be worth it in any FRC application.
On the other hand, it may be worth an experiment or two to see if the self-correcting nature of having the wheel trail the steering axis improves drive handling and stability.
6/2 2:38am
I've got a publication on it if anyone is interested
6/2 12:40pm
Please provide a link to your paper, or post it here.
6/2 1:00pm
I'll dig up our work on OCILOW.
Waiting patiently for this paper. Are you still digging?
I checked and it's not online. I've got the pdf, emailed it to another person that requested it. You're settings don't permit me to email you. If you'd like it, send me a request at lovelj@ornl.gov.
Lonnie
I checked and it's not online. I've got the pdf, emailed it to another person that requested it. You're settings don't permit me to email you. If you'd like it, send me a request at lovelj@ornl.gov.
Would you be willing to post it here so others reading this thread can see it as well.
Would you be willing to post it here so others reading this thread can see it as well.
I'd love to be for some reason I can't get the attachment feature to work
I'd love to be for some reason I can't get the attachment feature to work
What browser are you using?
Do you have pop-up windows enabled for Chief Delphi?
At what point in the process outlined below do things go awry?
Step1
Start a new post. Immediately below the editing screen should be a button that says "Manage Attachments". Click it.
Step2
You should get the "Manage Attachments" pop-up window. Click the "Browse" button.
Step3
You should get a "File Upload" pop-up window. Navigate to the folder that contains your desired attachment.
Step4
In the "File Upload" pop-up window, highlight the file you want to attach by clicking on it. The filename should then appear in the "File name" text box. Click on the "Open" button. This should take you back to the "Manage Attachments" pop-up window.
Step5
Your desired filename should now appear in the "Browse" text box of the "Manage Attachments" pop-up window. Click the "Upload" button (the one to the right of the filename).
Step6
Your filename should appear in the "Current Attachment" area of the "Manage Attachments" pop-up window. Click "Close this window".
Step7
When the "Manage Attachments" pop-up window closes, you should be back to your editing session, and your filename should appear above the "Manage Attachments" button in the "Additional Options" section below the editing area. Click the "Submit Reply" button.
.
Thanks for the guidance. I can print a car, develop a holonomic omnidirectional vehicle for the Navy but I can't figure out how to put an attachment on Chief Delphi. Go figure.
Let me know if you have any questions. This is a little dated, was done back in the 2005/2006 timeframe. But I may have the source code for the system we deployed if needed.
Lonnie
The NGMH on Figure 5 used spherical wheels rather than the Mecanums. We developed the spherical wheels about the same time as the mecanums were developed in the early 90's. The big blue machine was a bomb loader. It has a 7 dof force reflecting arm on a holonomic omnidirectional vehicle. We really needed the mobility to be able to maneuver under the wing of an aircraft. This was probably (at the time, mid 90's) one of the coolest omnidirectional vehicles. You could drive it, pull it, load bombs... The arm had a 4000 lb payload capacity.
The funniest experience was we used it to load a B1 which has a bay rather than pylons under the wing. We had to attached a platform and ride the arm, with the weapon, up into the aircraft. My safety officer was worried I'd fall so she chained me to the weapon (not live of course). Sometimes you just shake your head and laugh.
vBulletin® v3.6.4, Copyright ©2000-2017, Jelsoft Enterprises Ltd.