DPRG List

 [DPRG] Turning methods Message index sorted by: [ date ] [ thread ] [ subject ] [ author ] Previous message: [DPRG] RBNO - Tue Jul 29 Next message: [DPRG] Turning methods Subject: [DPRG] Turning methods From: Ed Paradis legomaniac at gmail.com Date: Wed Jul 30 00:02:13 CDT 2008 ```Hello everyone! Tonight at the RBNO I got Tankbot to run a UMBmark test. It was more a proof of the robot's ability to navigate to way points than a true attempt to measure the performance. One thing Tankbot did incorrectly was that it would occasionally hit a way point and turn 'the wrong way', inducing a large amount of slippage error. Essentially it would execute a -270 degree turn instead of a 90 degree turn. I know this is a problem in the code, but instead of fixing this problem, I'd like to jump straight towards what I feel is the heart of the matter: how to execute turns. What are the methods that any one has used to execute turns in a list of way points? Does anyone look ahead to the next way point and try to 'get clever' with the turning? Because of the geometry and general restrictions of the frame of Tankbot, I'd like to execute beautiful sweeping turns, instead of coming to a dead halt, scratching and scraping as it spins in place and racks up huge errors in encoder counts. They're really not that huge, because the 'bot can do a pretty good square, considering no tuning. For the record, here is the raw data from the test. Notice that it performs much much better clockwise than anticlockwise. clockwise turn #, X, Y 1, 2, 3 2, -2, 6 3, -5, 10 4, -7, 10 5, -5, 18 anticlockwise 1, 4, 15 2, 3, 26 3, 13, 36 4, 19, 42 The X and Y values are in inches from the starting point. The square was 60 inches on each side. This is rather small for Tankbot, because it is almost 2.5 feet long! The anticlockwise numbers are so far off because the robot would always "do a spin" on the second turn. It keeps track of its movement no matter what, but what it is recording begins to deviate quickly when spinning in place. Track speed is varying with battery voltage, although it shouldn't. This is due to the control system hitting "max" and letting the PWM sit at 100%. In other news, the networking issues with the on-board wireless router have been fixed, and you can log into the robot about 30 seconds after power on. Ed ``` Previous message: [DPRG] RBNO - Tue Jul 29 Next message: [DPRG] Turning methods Message index sorted by: [ date ] [ thread ] [ subject ] [ author ] More information about the DPRG mailing list