{"id":88,"date":"2012-02-19T23:19:46","date_gmt":"2012-02-20T04:19:46","guid":{"rendered":"http:\/\/www.mcgurrin.com\/robots\/?p=88"},"modified":"2012-02-19T23:19:46","modified_gmt":"2012-02-20T04:19:46","slug":"measurement-precision-versus-control-precision","status":"publish","type":"post","link":"https:\/\/www.mcgurrin.info\/robots\/88\/","title":{"rendered":"Measurement Precision versus Control Precision"},"content":{"rendered":"

Spent some time today chasing down a problem that’s probably obvious to experienced developers, but it wasn’t to me, and I’ll guess to other newcomers.\u00a0 There’s obviously a limit to both the position and heading precision that can be obtained purely through odometry based on wheel encoders.\u00a0 For distance traveled in a short delta of time, the precision is a function of the smallest fraction of wheel rotation you can measure and the wheel diameter.\u00a0 For heading, it’s also a function of the wheelbase (the distance between the wheels on each side).\u00a0 The heading precision tends to be much poorer than the distance.\u00a0\u00a0 For example, if I can measure 1\/8th of a revolution of a 1″ diameter wheel, I can measure increments of 1\/8 x pi x 1 = 0.39 inches.\u00a0 If the wheelbase is 4 inches, and I’m using tank style steering, then the smallest heading increment I can measure is pi * ( 1\/8 * 1) \/ 4 = 0.098 radians or about 5.6 degrees.\u00a0 That lack of precision is one factor in the errors that can build up very quickly when making a number of turns.\u00a0 (Slippage can also be a major contributor to the error). \u00a0 [The Using Dead Reckoning section in Enabling Your Robot to Keep Track of It’s Position<\/a> from Ridgesoft has a good explanation of this]<\/p>\n

When trying to use dead reckoning to turn, you typically can’t get the measured heading to exactly match the desired heading due to these precision limits, so you have to set a window defining “close enough.”\u00a0 So far, so good.\u00a0 In my case, I’m using interrupts to count clicks on each of two wheel encoders, so I could be sure not to miss a unit.\u00a0 All was working well.\u00a0 In tests, I’d see 0 or 1 click of the encoder on each wheel each time my Arduino code executed the main loop and updated the position and heading.\u00a0 I set my “close enough” threshold accordingly.\u00a0 Then I added doubled the resolution on the encoders and added a lot of serial.print() commands when in debugging mode.\u00a0 Suddenly my formally working robot, which now had more precise navigation, would go haywire.\u00a0 It would often work fine, but at other times it would spin around in multiple circles when turning to the next waypoint or avoiding an obstacle.<\/p>\n

It took a lot of debugging to figure out the problem. With interrupts now occurring with twice the frequency, and the execution loop slowing down due to numerous serial print statements, there were often 3-4 encoder clicks per update. \u00a0 This meant that the robot was sometimes turning 4x more than the maximum precision of my measurements between execution of the appropriate code in the main loop.\u00a0 Therefore it would sometimes, by luck, hit within the good enough window when turning, but other times it would be below the window on one pass and above it the next, and therefore keep turning and turning until by luck it hit within the window.\u00a0 My control precision<\/strong><\/em> was only 1\/4 of my measurement precision<\/strong><\/em>.<\/p>\n

I’ve done three things to adjust:<\/p>\n

    \n
  1. Ensure that don’t have the debugging serial.print() statements in except when doing a “bench test.”\u00a0 (see the use of the #if preprocessor directive if you’re new to C or Arduino programming).\u00a0 That speeds up loop execution.<\/li>\n
  2. Slow down the turning speed of the robot.\u00a0 By turning slower I can get the control precision to more closely match the measurement precision.<\/li>\n
  3. Relax the window slightly, making control a bit sloppier, but ensuring I don’t miss the window if adjustments 1 and 2 weren’t sufficient.<\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"

    Spent some time today chasing down a problem that’s probably obvious to experienced developers, but it wasn’t to me, and I’ll guess to other newcomers.\u00a0 There’s obviously a limit to both the position and heading precision that can be obtained … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[3,8,20,7,4,21],"_links":{"self":[{"href":"https:\/\/www.mcgurrin.info\/robots\/wp-json\/wp\/v2\/posts\/88"}],"collection":[{"href":"https:\/\/www.mcgurrin.info\/robots\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.mcgurrin.info\/robots\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.mcgurrin.info\/robots\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.mcgurrin.info\/robots\/wp-json\/wp\/v2\/comments?post=88"}],"version-history":[{"count":3,"href":"https:\/\/www.mcgurrin.info\/robots\/wp-json\/wp\/v2\/posts\/88\/revisions"}],"predecessor-version":[{"id":91,"href":"https:\/\/www.mcgurrin.info\/robots\/wp-json\/wp\/v2\/posts\/88\/revisions\/91"}],"wp:attachment":[{"href":"https:\/\/www.mcgurrin.info\/robots\/wp-json\/wp\/v2\/media?parent=88"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.mcgurrin.info\/robots\/wp-json\/wp\/v2\/categories?post=88"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.mcgurrin.info\/robots\/wp-json\/wp\/v2\/tags?post=88"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}