Giter VIP home page Giter VIP logo

Comments (3)

mattallen37 avatar mattallen37 commented on June 2, 2024

Thanks for bringing up these points. I'll try to give explanations.

The encoder position values are not accurate enough to require the precision offered by floating point values. To demonstrate the encoder position accuracy, grab a wheel connected to a motor, and mildly rotate back and forth without actually turning the motor/encoder. Due to the gearbox backlash, the wheel will rotate maybe 1 degree or so. Providing a value that is more precise than it is accurate is not necessary in my opinion.

Regarding the motor speed feedback (in degrees per second), due to timing tolerances and refresh rates in the firmware calculating the value, I can't guarantee better than 1 DPS accuracy. From a practical standpoint, 1 DPS resolution is equivalent to about 0.16 RPM resolution, which in my opinion is precise enough for anything people will be doing with the GPG3 drive motors.

In PR #161 I added reset_motor_encoder() which is a simpler way to reset the motor encoder values.

I want to avoid adding encoder reset to reset_all() for several reasons. Since reset_all is typically called at the termination of a program, if the wheels continue to rotate a little (e.g. the motors were running at 100% power when reset_all() was called), the encoders will be reset, but then they will count e.g. another 90 degrees as the motor is coming to a stop, making the reset pointless. Another reason is that sometimes it's handy to have the encoder values remembered between programs. For example, if you have a robot start at a specific location (0cm) on a measured line, drive 25cm and then terminate the program, if you then run a program to tell it to drive to the 15cm mark, it will know that it needs to drive backwards 10cm (15cm - 25cm = -10cm) rather than driving forward 15cm (which would put it at 40cm).

I would agree though, that based on the name, reset_all should indeed reset the encoder values as well. Perhaps I should go ahead and add encoder resets in reset_all, and then create another method that just stops everything (float motors and servos, turn off LEDs, and unconfigure the Grove ports).

from gopigo3.

christianrauch avatar christianrauch commented on June 2, 2024

Thanks for going into that detail.
I am still wondering if the rounding when getting the current encoder values and setting the offset
offset = int(int(encoder / self.MOTOR_TICKS_PER_DEGREE) * self.MOTOR_TICKS_PER_DEGREE)
doesn't add up after many calls to reset the encoder.

Wouldn't it be simpler to just set the encoder values on the controller to a given value? E.g. a method like set_encoder(port, value) could be used to reset the encoder or to restore a previous encoder state.

from gopigo3.

christianrauch avatar christianrauch commented on June 2, 2024

I just thought about the use case of setting the encoder values after starting another program:

For example, if you have a robot start at a specific location (0cm) on a measured line, drive 25cm and then terminate the program, if you then run a program to tell it to drive to the 15cm mark, it will know that it needs to drive backwards 10cm (15cm - 25cm = -10cm) rather than driving forward 15cm (which would put it at 40cm).

This really only makes sense when using either linear (move forward/backward) or angular (turn left/right) movements only. If you translate and rotate arbitrarily, restoring the encoder values does not make sense at all. Consider the two cases: (1) driving forward 10cm and then rotate 90 degrees, and (2) rotate 90 degrees and then driver forward by 10cm. In both cases, your both wheel encoders will provide the same values, but the pose (position and orientation) of the robot in the world will be different. Restoring the encoder values after a program start does not provide any useful information in these cases.

So in the end, I do not see a benefit of setting the encoder values other than resetting them to 0, if you want to compute your position (based on wheel encoders) from a new starting point. I propose to remove the method offset_motor_encoder (because I do not see a valid use case) and include a method for resetting the encoder values to 0.

from gopigo3.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.