Quote:
Originally Posted by apalrd
I will disagree with you on this one.
Our 2011 robot has about as much code running the drivetrain as it does running the elevator/claw system as a whole (minibot is separate, and much smaller).
Why?
Closed-loop drive control has a few blocks to it, logic to coast out stops, logic to hold position, gain scheduling based on shift state, etc.
Autoshifting has a block to it, its a lot of tuned logic operations.
Lift piston management has a few blocks, to lift the rear wheels when turning, and another one to lift the inner one in an arc.
HMI has a bunch of blocks, for arc management, speed derating at high elevator positions, drive line inversion, and such.
The elevator and wrist, on the other hand, has:
A really big state machine that actually runs the elevator
A reality check that prevents driving through the elevator with the wrist (or the wrist with the elevator), some of the going backwards logic.
A P controller with gain scheduling
An anti-stall-death algorithm
What I'm saying is that the little code things you write to optimize performance in the drivetrain add up to the one really big state machine plus a few other blocks you write for the mechanism. For us, the optimization effort is worth it, I guess that depends on your teams coding resources.
|
I'll say this: 90% of all our code was probably put into the drive; my mentor said that this year's robot was probably the smoothest driving robot our team has made. That says something about really putting effort into it. I admit, the code for rest of the robot was pretty much chopped together in an hour. The drive took weeks of optimization and yet I was still not able to optimize it to the best I can because a lot of my time went into testing sensors and stuff like that.
Quote:
Originally Posted by Cuog
My first question to you is what machining capabilities do you and your team have? You'll need someone experienced in machining to thousandths of an inch accuracy. And preferably someone who has experience working with gears. I can tell you it will take an incredible amount of talent to make a working swerve module with a drill press and a hacksaw.
Second PID loops are great and all, but there's a lot more to it than that. To make an intuitive setup you'll need to figure out exactly what way you want to map user input to outputs. There are about 10 ways to do it that will work, but a lot fewer that are considered good. Again you'll need to scale these inputs usefully.
My first time programming a omni directional drive it was very easy. It took only 3 lines of code(4 omni wheels at 90 degrees from one another). And yeah it worked first go kudos to me. Then one of the drivers said what happens when we turn, tapped the joystick full left for a second and the robot spun in place at 14 feet per second with its arm sticking out 4 feet almost hitting several people. Ok that's easy to fix, just tone down the spin modifier. That worked to keep it from being a death trap, but then thanks to slowing its turn, getting a smooth strafe/twist couldn't happen over a certain speed because the twist modifier couldn't twist enough.
In the end my pretty little 3 lines of code which worked turned into a pretty large function to control the omni bot properly. And I didn't even use PID, not to mention there's a little bit more to keep track of in a swerve drive.
I'm sure you're thinking pfft that's nothing, I got this. You probably will get it eventually, but keep in mind the sheer number of stumbling points waiting for you, and if you attack it with the same arrogance I read in your posts, you'll lose a lot of the people whose help you will need to complete the project.
|
I have everything in my head. Yes I am arrogant, but from years of just living, I noticed that people tend to talk things up. Like how calculus is "so hard" or how physics was such a hard class. It usually ends up not as hard as they say it is. Like what you went through omni. I went through the same thing (it was the first system I was assigned to code), but I find those as minor discomforts. I do see what you are saying, but those are expected.
Well, I am saying that I am not scared of 30 file projects with thousands of lines of code. I actually like doing that; that is the whole fun of coding. It is those times that I feel like quitting and bashing my head on the wall that really satisfies me. It's because you really have to experience suffering before you know what joy really is like. I like tackling big projects head on.
As far as machining capabilities go, I can probably call somebody up to help make it and teach the team.