Shop OBEX P1 Docs P2 Docs Learn Events
ActivityBot Rotation functions — Parallax Forums

ActivityBot Rotation functions

RsadeikaRsadeika Posts: 3,837
edited 2014-09-22 14:30 in Learn with BlocklyProp
I am trying to develop a relatively accurate function for rotating the robot. From the Learn site, which lists 0.284 as the tick value for one degree, I tried to expand that where I would type in a command(rdistance) and the rotation value, and hope the rotation is more or less accurate. It seems that for the smaller values, like 90, I get a fairly close rotation, but for the larger values like 180, it is way off. I also tried using 'float ticks=(d*0.284);', which made it even worse. I thought by using 'float' that it would calculate to 0.284 as opposed to the integer version which would be 3, I think. So, I need some input from the more experienced on this, anybody have some more accurate way of achieving this?

Thanks

Ray
    else if(!strcmp(inBuff, "rdistance"))
    {
      readStr(rpi,inDuff,10);
      pause(100);
      int d = atoi(inDuff);
      //d = (d * 25.4);
      int ticks = (d*0.284);
      drive_goto(ticks,-ticks);
    }

Comments

  • twm47099twm47099 Posts: 867
    edited 2014-09-22 07:49
    I found similar behavior when I started using the activitybot. After calibrating according to the instructions I found I had to make some further adjustments. I don't have all of my notes with me but according to some calculations I have programmed into my tablet:

    I had to adjust for the spacing between the wheels. Mine was not the same as listed in the Learn page. It was 106.2mm. I also found my Bot did not go exactly 3.25 mm/tick
    I assume everyone's is different depending on how firmly they mount everything. Actual turning radius is important. I also ran some tests as I made changes.

    My calculations for turning (modified slightly by test results) show that I had to add 8% to the calculated number of ticks to get my desired degrees. Instead of using trimset I used my calibration values in my programs calculations. I found that worked pretty well, but it does mean that my programs using that method may not give exactly the same results on a different bot.

    Tom
  • RsadeikaRsadeika Posts: 3,837
    edited 2014-09-22 08:32
    For the rotational accuracy to improve, I have a feeling that I might have to add a compass. But I am still concerned as to why, when using float values, the actual rotation does not become more accurate? As for the straight distance travel, I am not sure as to how that could be improved, unless you implement a Ping device and then use that to correct the actual distanced travelled. But, then you would probably introduce some new problems because of the echoing distortions that might occur.

    Ray
  • edited 2014-09-22 10:37
    Hi Ray,

    Make sure to cast any floating point values as int before passing to abdrive functions.

    Int to float

    float floatVal = (float) intVal;

    Float to int

    intVal = (int) floatVal;

    As for in accuracies, you'll want to examine how many spokes/spaced have actually passed by the sensor. You'll want to do one set of tests if it involves inconsistencies in the number of spokes that have passed, but a different set if it has to do with errors within a certain hole/spoke region. I usually take a very small slice from a sticker to mark the staring and ending spoke/hole that should be in front of the sensor before/after the maneuver.

    Andy
  • RsadeikaRsadeika Posts: 3,837
    edited 2014-09-22 12:13
    Thanks for the tips Andy, but that did not help. It seems like you have drive_goto() setup where it only takes in non-decimal point numbers. So, whatever I do with the .284, it will always get rounded, so in my particular function it will not work correctly, or at least what I expect it should be. It almost seems like I have to go with predetermined numbers, like your examples in the chart, which makes what I want to offer somewhat awkward. I have created a similar function called fdistance which I will have to double check too see if in fact it is going the specified distance.

    Ray
  • edited 2014-09-22 14:04
    Hi Ray,

    Neither the hardware nor the abdrive library functions are designed to take anything other than integer values. The hardware is designed so that the wheel can count a total number of spokes, but does not have a way to perceive if it has traveled 0.125 spokes, for example. So, the abdrive library has int parameters that allow you to tell it to go some integer number of spokes/spaces and positions the wheel somewhere within that spoke or space.

    If you have a distance calculation you want to make, you can use floating point values. For example, you can declare a floating point value that's 3.25 (for 3.25 mm per spoke), and then use it in distance calculations. But your result has to be converted to the nearest integer value. The integer value can then be passed to an abdrive function.

    Andy
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2014-09-22 14:30
    Ray,

    One thing you can do to finesse the rotation angle is to diminish one of the arguments to drive_goto by one so that they have slightly different magnitudes. That will cause the bot to rotate by a little less than it would have otherwise, without any perceptible forward or reverse motion.

    -Phil
Sign In or Register to comment.