Quote:
Originally Posted by kamocat
Interesting.
What sort of bugs does this catch for you? Does it simply tell you you need to turn further here, or stop sooner here?
Or is it meant to catch bugs in your navigation subVIs?
Or is it used for timing purposes? (you must fit all your autonomous into 15 seconds, unless you continue during Teleop)
Is this only used for testing autonomous, and not Teleop?
You ARE using encoders and a gyro on your robot for feedback, aren't you? Or is it entirely time-based?
|
Almost all driving is controlled using encoder/gyro feedback. The simple robot model takes the motor commands from the autonomous software, calculates the robot speed, heading, distance travelled, and X,Y position. The heading, distance travelled (and speed if wanted) are fed back to the autonomous software as sensor readings (gyro/encoder readings). Thus, a complete closed loop simulation can be done.
It helps to debug all of the navigation software (position calculation) as well as the control software. For example:
- does it drive the correct heading?
- are their any sign errors / accidental positive feedback loops?
- does it go forward when it's supposed to go forward, backward when it's supposed to go backward.
- does it properly exit the maneuver and sequence to the next maneuver?
- does it drive an arc properly and exit properly from all starting headings and ending headings? (if you have an arc maneuver as one of the driving maneuvers)
- does it properly go to an XY coordinate? Does it do so without going too far out of the way? Does it "track" instead of "home"? (if you use Go To XY)
- do the timed manuevers (such as delay, hold position, timed appendage motor commands (like roller claws)) exit at the proper time?
- do any interacting exit conditions (such as OR logic between time and arm/elevator getting to the desired position) work properly?
- etc.
It's pretty cool: you can code up come cool autonomous control, run the simulation and see the robot go running off and crashing into a wall (virtual wall, of course). Check the code and go "duh - here's a sign error". Correct the error, re-run the simulation, and it does what you expect. You then realize how nice it is not to have real robots crashing into real walls as you do your debugging.
The biggest thing is that if you were afraid to do something complicated (like mapping the floor into X,Y coordinates), you can do all of your software testing in simulation before the robot is even built. Get as fancy and complicated as you want - you don't need time with the real robot. It translates to the real robot quite well as long as everything is feedback controlled.
Never done feedback control? Here's your chance - get it all working in simulation where you don't have to worry about breaking the robot with your trials and errors.
Simulation can be a great tool. It takes a little up front investment, but the payoff is > 10x what you put into it.