Announcement

Collapse
No announcement yet.

Questions about multithreading

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    A friend programs for low comp power embedded systems. He uses lookup tables since he can't afford the computation time. Seems a lot easier, especially for our purpose where this is nowhere exact, you're roughly approximating a motor response.

    Last year's tank program example includes a scale method that matches an exponential function using a lookup table. A lookup table has the advantage that you can easily tweak the numbers to more closely match real world motor response, or make it completely different to meet your needs.

    https://en.wikipedia.org/wiki/Lookup_table

    Comment


    • #17
      Now we are talking the right approach. First identify the perceived problems, then analyze them to identify if they are real and not red herrings or irrelevant details. After that evaluate the realistic solutions for the problems. It could be in mechanics, electronics, or software. In software, the simplest solution is often the best.

      For repeated control loops, a 8-12 bit accuracy is most often adequate. If you are trying to reach perfection and go over 12 bits you are wasting your time and possibly creating unnecessary new problems. In that sense, even a rough lookup table is often excellent solution.

      Please, avoid over engineering.

      Cheers, Ollie

      Comment


      • #18
        Thanks for the input everyone. I'll have to ponder and see whether multithreading will really be worth it for our use case.

        Comment


        • #19
          Originally posted by mikets View Post
          So if you take vision out, there is no good reason to use more than one thread. That's why in the TRC library for FRC, we only have a single thread doing cooperative multitasking but we have a second thread doing vision.
          We are looking at doing this as well. Could you share some example code of how you are running vision in a separate thread communicating back to the main thread?

          Comment


          • #20
            Originally posted by caseyz View Post
            We are looking at doing this as well. Could you share some example code of how you are running vision in a separate thread communicating back to the main thread?
            So far, we only have vision thread support in our FRC library and not FTC (yet). Vuforia is new this year, we decided not to use it because other means seem more effective and reliable. So we are not going to divert resources in adding support for FTC this year. Our FRC video thread support is also written in Java and is using NIVision. It shouldn't be too difficult to adapt this to Vuforia (or OpenCV). If you are familiar with Vuforia (or OpenCV), I assume you just want to check out how to make a separate thread "safely" working with the main thread, then you can just look at our FRC code and do similarly. Basically, the vision thread will be on some sort of "available frame notification". When a frame is available, it will process it and produce the output (usually, the target position X, Y and Z). You will allocate two target position objects. One is "owned" by the main thread, the other is owned by the vision thread. So when the vision thread processes a frame, it can safely put the result into its own target position object without fearing resource contention. Then in the main thread, when it needs a new target position, it will acquire a synchronize lock, this will prevent the vision thread from accessing its target position object temporarily, then you swap the target position object. The main thread now has a fresh target position object and the vision thread has the other one. Obviously, there are a lot of little details such as having a "valid data" flag in the target position object to indicate if the target position object contains fresh valid data. And the call to "swap" the objects must look at this flag to decide if it really should swap them (only when there is valid fresh data). Now if you understand what I am talking about (e.g. the concept of synchronize lock) and confident you can do it, go ahead and play with it. But if you are confused and lost then I suggest you defer this as a post season project.
            Our FRC vision thread code can be found here.
            https://github.com/trc492/Frc2016Fir...FrcVision.java

            Comment

            Working...
            X