Re: More Mule then Rover?
I'd be careful with the "all will ____". None of my large controllers will do any such thing if they lose either analog or PCM.
But regardless - I don't really care what motor controller you decide to use. I was just curious.
The real meat there was PID and filtering.
Re: More Mule then Rover?
Quote:
I'd be careful with the "all will ____". None of my large controllers will do any such thing if they lose either analog or PCM.
Adrenalynn
You are correct, That line should read "All the low cost units I looked at so far"
I should have "First project syndrome" tattooed on my forehead so everyone knows my
information is very limited, I do appreciate it when I'm corrected .
I also come to agree with you about the drive not being the problem.
I do have sweet feedback
Q axis to +/-.006 Deg.(incremental encoder 10000 x 4 CPR )
A axis to +/-1 Deg. Abs.(Phidget 3/3/3)
X axis +/- .010"(incremental encoder 600 x 4 CPR with 8" wheel)
The answer can be found in properly using the feedback in software.
A good example of why I suspected the Dec/Acc as the problem. If I turned off it's X axis feedback
it would Acc as programed, if I then turned it back on while the drive was at it's max set point the
testbed would continue bucking between Acc/Dec trying to catch up to the PID. while that problem
did not show up with the Sabertooth drive. but that could be dealt with in software, simple as pause
the program if the Analog voltage gets to the max set point.
My bad!
Tommy
Re: More Mule then Rover?
Tommy the mower look good your way ahead of me.
Im approaching it from the Navigation standpoint first cause if I cant get it to stay in the yard by itself and not run over the flowers and hit the trees this is futile project and will just be a RC lawnmower which aint so bad either.
Also i would like to enter it in the robo Magellen contest here at Chibots
If I Can get that sorted I will then just build a custom mower deck probably a tripod design with 3 wheel steering and the mower being in the center of the tripod. See design pic of powered castor.
I been researching the tires and rims online and there are not may choices so I will build two adaptors to run wider tires which are a couple buck on sale at harbor freight and there is a lot of choices for tires.
I been researching the Drives online and I really like the Saxbertooth 2x50.
I thought about using the P and G drives but it will be too much work, and they dont seem to be intrested in supporting the robotics community plus the combat robots have really sorted all the issues out already its just a matter of how much money I want to spend on a drive.
So I will replace it all in 3 weeks with the sabertooth drive after I save my pennies.
http://forums.trossenrobotics.com/at...1&d=1283816023
Re: More Mule then Rover?
Quote:
I been researching the Drives online and I really like the Saxbertooth 2x50.
jdolecki
I also have the hots for a Sabertooth 2x50, but can't seem to find one, I got the sabertooth 2x25
for my original design for a mower deck, 3 Scott classic reel mowers powered by two motors,
the earthwise 20" i'm using for tests is a cordless 24vdc which made interfacing a breeze. I'm
using the sabertooth 2x25 to trouble shoot my drive software, but I have to be careful with it.
Tommy
Re: More Mule then Rover?
Quote:
I also have the hots for a Sabertooth 2x50, but can't seem to find one, I got the sabertooth 2x25 for my original design for a mower deck
If I already had a 2x25, I think I wold look at paralleling in another set of MOSFETs to increase the current capacity.
Re: More Mule then Rover?
Quote:
If I already had a 2x25, I think I wold look at paralleling in another set of MOSFETs to increase the current capacity.
zoomkat
I looked at it, but as I get older connecting to surface mounted boards seems to be getting harder.
Fact is I'm going back to the P&G for a main motor drive, the Sabertooth 2x25 is going to run the
motor on the linear actuator to raise and lower the third wheel?, the other channel could be used
to raise or lower a snow plow blade.
Tommy
Re: More Mule then Rover?
The below motor controller might be a less expensive alternative to the sabertooth. How much current does your linear actuator require, and does it contain an internal pot?.
http://secure.oatleyelectronics.com/...94c2bcce5d0560
Re: More Mule then Rover?
Quote:
How much current does your linear actuator require
zoomkat
All I can do is guess at this point, the device was made by SKF but all the motor
characteristics are not listed, on close inspection it seems they were never printed
on the label. they did have a wheelchair manufacture's label and part number, but
when goggled, gives me the GPD of china.
My best guess is it stalls at @10-15Amp, with @2-4Amp no load.
Quote:
and does it contain an internal pot?
The actuator has no internal feedback(just 24vdc gearmotor connected to a ball screw), but I did get one analog tilt senor, a reed tilt switch and
two limit switches which I'm sure I can find a place for.
Tommy
Re: More Mule then Rover?
Quote:
Fortunately, you're not building a mobile CNC
What if it was?. or at least I thought of it that way.
If I was going to have an industrial robot(Fancu,Yaskawa..ect) do a job for me chances
are I would program it in G-Code.
Simple example:
N010 G90; (this line sets Abs mode, G91 would be incremental)
N020 M4; (this line would turn on the spindle CW, in my case it would turn on Mower)
N030 A190.5 S10; (this line tells A axis to go to 190.5deg at 10deg per sec)
N040 X123.250 F10; (this line tells X axis to go to 123 1/4" at 10" per sec)
N050 M3; (this line would turn off the spindle , in my case it would turn off Mower)
%; (End of program a M99 would have it repeat the program)
The sweet thing about G-Code is it can be edited with notepad, excel or any text editor,
also there are lots of CAD/CAM programs to automate G-Code programing and implementation.
theres been a big push in the manufacturing industries over the last ten years in digitizing parts
to aid in CAD/CAM production, and they have made good progress, why can't them systems or
methods be used for this type project.
Quote:
Also i would like to enter it in the robo Magellen contest here at Chibots
jdolecki
I wonder if you used the above thinking, would it improve your chances of winning?
Tommy
Re: More Mule then Rover?
Quote:
Originally Posted by
Tommy_T
theres been a big push in the manufacturing industries over the last ten years in digitizing parts
to aid in CAD/CAM production, and they have made good progress, why can't them systems or
methods be used for this type project.
Because an autonomous mobile robot is *not* a CNC machine. For at least 2 major reasons:
- With CNC, dynamics are not as important -- a single motor controllers movement in a single axis. When you move the X-axis, you don't get angular rotation or Y-axis drift. With your robot, which uses differential drive, there are two motors whose difference in speed controls angular velocity -- driving forward in a straight line means the motors have to be perfectly in sync at all times (something that generally can't be achieved all the time, for instance, if the robot hits a rock on one side, that wheel suddenly loads up a bit and it will take a short time for the PID to catch up).
- With CNC you are firmly attached to your frame of reference. If you want to know your location within the real world, you need to measure travel relative to the world -- but the odometry from encoders is only one part of it. Even if you were able to get the motors perfectly aligned for all time, how are you going to make sure the wheels *never* slip, ever, in a million years? Because that's what dead reckoning would require -- if you have wheel slip, you'll eventually get off the intended course, and you need to correct for that.
The typical approach to mobile robot navigation is to maintain sensor readings in a locally consistent frame of reference (one centered around the robot, or a frame maintaining the odometry), and then to *localize* the robot periodically through the use of some sensor (typically a laser scanner, GPS + filtering techniques, or a visual approach). By localizing the robot, you cancel out the error in the odometry/drivetrain.
Now, you could build a G-code interpreter on top of such an approach in order to give motion commands, but underneath it, you'll need a localization routine (especially for something like RoboMagellan, where the distance and terrain covered are sure to impede any dead reckoning approach).
-Fergs