Announcement

Collapse
No announcement yet.

Bulk reads redux; confirming what is and isn't bulkable

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

  • Alec
    replied
    Originally posted by zain View Post

    Is it just me or does it actually look like Interatvie Opmode is the "normal" that the SDK was born with, and Linear Opmode is something they kludged on afterward because people wanted something that wasn't quite as event-driven and looked more like the RobotC flow that preceded the switch to Android phones? If memory serves there was just Opmode at first. And then LinearOpmode followed. No?
    Yes, that is correct (and very astute considering you are a "non-software mentor").

    Leave a comment:


  • zain
    replied
    Nothing says you can't re-implement the "normal" OpMode structure on top of linear
    Is it just me or does it actually look like Interatvie Opmode is the "normal" that the SDK was born with, and Linear Opmode is something they kludged on afterward because people wanted something that wasn't quite as event-driven and looked more like the RobotC flow that preceded the switch to Android phones? If memory serves there was just Opmode at first. And then LinearOpmode followed. No?

    Leave a comment:


  • Alec
    replied
    Originally posted by alan_16072 View Post
    [USER="160545"]I had a junior programmer that worked for me many years ago that looked quite green in the gills. When I asked him what was wrong, he said "You know how McDonald's has 2 Big Macs for $2. Just because you can, doesn't mean you should...."
    LOL. Same goes for LinearOpMode... Just because you can use LinearOpMode, doesn't mean you should.

    Great book Alan! Thanks for doing your part in rescuing teams from LinearOpMode!!!

    Leave a comment:


  • alan_16072
    replied
    4634 Programmer - I had a junior programmer that worked for me many years ago that looked quite green in the gills. When I asked him what was wrong, he said "You know how McDonald's has 2 Big Macs for $2. Just because you can, doesn't mean you should...."

    This is what I think about implementing a "normal" opcode structure on top of linear..... :-)

    Leave a comment:


  • 4634 Programmer
    replied
    Originally posted by zain View Post
    Alan,

    I too prefer Opmode. Mostly because for a crusty old MechE like myself it seems like the obvious way to do it. And because it let's me introduce the kids to basic stuff like events, state machines, and measurement and feedback in a clear unambiguous way. And since the first team I had started with FIRST FLL then did Arduino projects with me before moving to FTC, doing things with init() then loop() seemed obvious.
    Nothing says you can't re-implement the "normal" OpMode structure on top of linear

    Leave a comment:


  • NoahAndrews
    replied
    Thanks for the update! Consider this an excellent lesson in why calling close() methods often actually matters.

    Leave a comment:


  • zain
    replied
    So I got a moment on the kids' robot and made a progressively more stripped down version of their code. No version ever appeared to run the few lines of code in the stop method. And every result was the same truncated last line of the CSV file. Which struck me as odd. Since if loop() was getting aborted somehow, why should it always have been during the write process for one new line of the CSV file? Certainly before I started taking things out, all kinds of other stuff was going on in loop() before that one try/catch that wrote a long string.

    Thus, I tinkered with one line of code in the stop() method instead. To wit:

    public void stop() {
    try {
    datawriter.write("Stop method invoked at runtime: " + String.format("%.3f", runtime.seconds()) + "\n");
    datawriter.close(); // if this line is not present, the resulting CSV file is truncated on pressing STOP. If it is present, the CSV file is complete and includes text from line above
    } catch (IOException e) {
    e.printStackTrace();
    }
    }


    I figured there was some sort of buffer not being handled at the end. So guessing, I tried the .close() and with the addition of the .close() things all seem to work as expected. And the string "Stop method invoked at..." is the last line of the file, even if the timer stops autonomous and the stop button is not pressed.

    I don't know how the Writer and FileWriter classes work. I just had the kids copy from some examples ya'll linked to a prior question. But clearly the bug was on our end.

    Leave a comment:


  • NoahAndrews
    replied
    It would be helpful to at least have access to your code, so that we can try to reproduce the issue locally.

    Leave a comment:


  • Alec
    replied
    Originally posted by zain View Post
    ... The last thing their main loop does is write a line of data to a CSV file. Whenever we look at that file, it will often have a truncated last line. As though loop() was stopped by some other mechanism and did NOT get to terminate in an orderly fashion upon completion. Furthermore, as a test, I added a write step to their stop() method just now that writes a final line of the form "Stop method invoked at time: " etc etc etc to their CSV file. This also is never part of the file upon inspection. Even if the STOP button is pressed while teleop is running and the file is being updated every loop() as normal ...
    Coach Z, can you try stripping code out of your opmode little by little until there is nothing left but your CSV logger. If the behavior still persists, then I would say it is either a bug in the SDK or a bug in your CSV logger.

    Leave a comment:


  • zain
    replied
    Alan,

    I too prefer Opmode. Mostly because for a crusty old MechE like myself it seems like the obvious way to do it. And because it let's me introduce the kids to basic stuff like events, state machines, and measurement and feedback in a clear unambiguous way. And since the first team I had started with FIRST FLL then did Arduino projects with me before moving to FTC, doing things with init() then loop() seemed obvious.

    But back to stop(). The reason I keep asking (in poorly formed questions it seems) about stop() is that I'm fairly sure the stop90 method in the kid code doesn't do anything.

    Now, I totally get that bad things happen if loop() takes too long. Trust me, it does not in the kids' code. As a histogram I posted above illustrates, their code runs in nominally 20mS. Longer when the OS goes off to garbage collect something at regular intervals. But nothing close to 100 mS or longer.

    I also get how it's *supposed* to work. That once somebody presses the STOP button (and perhaps when the 30 second timer ends autonomous) after loop terminates for what will be its last time, the stop() method is supposed to occur once.

    However... it surely doesn't look like this is the case. The last thing their main loop does is write a line of data to a CSV file. Whenever we look at that file, it will often have a truncated last line. As though loop() was stopped by some other mechanism and did NOT get to terminate in an orderly fashion upon completion. Furthermore, as a test, I added a write step to their stop() method just now that writes a final line of the form "Stop method invoked at time: " etc etc etc to their CSV file. This also is never part of the file upon inspection. Even if the STOP button is pressed while teleop is running and the file is being updated every loop() as normal.

    It has also seemed in the past to my students that commands to halt spinning digital servos and the like in stop() did not happen either. So generations learned to not use stop(). And I sorta forgot about it. Until this thread prompted me to ask.

    Are we sure stop() happens under the conditions it is supposed to?

    Leave a comment:


  • alan_16072
    replied
    I would like to respectfully disagree with 4634 Programmer on one thing. I strongly prefer OpMode over linear OpMode. I have a free book for learning Java for FTC - Available here: https://github.com/alan412/LearnJavaForFTC

    Appendix B describes Linear OpMode and my opinion for why I think it is better to not use it.

    On the subject of your "stop" not being called. If your loop doesn't return within the "stuck time" (you can change it but you probably shouldn't change it to be longer) then the FTC SDK will kill your OpMode and call the "STOP" OpMode. (so "stop()" in your OpMode will not be called.)

    Hope this helps,

    Alan

    Leave a comment:


  • zain
    replied
    That definitely sounds like my impression of how it's supposed to work. But some number of SDK revisions ago, we somehow became convinced it might not. Or not always. Perhaps erroneously.

    I do get how stop() can't happen until loop() completes its last go after STOP has been pressed. So there might be a short delay. But assuming a normally operating loop() are there conditions where event loop might skip stop()?

    How about at the end of autonomous? If the kid's code just keeps looping away in loop(), and the 30 second timer is what stops auto, does the stop() method execute or not?

    Leave a comment:


  • 4634 Programmer
    replied
    Originally posted by zain View Post

    So my poorly phrased question was more along the lines of: When does loop() stop being called and stop() called instead? I would have thought that it would be when the STOP button was pressed. Or when the watchdog fails to see loop() end. Is that not the case? Sometimes it seems to me like it's not the case. Hence my query.
    When the stop command is sent over from the Driver Station, it is held in queue until the main event loop processes it. That can only happen after loop() returns, since calling loop() is one of the things the event loop does. What *should* happen is that after loop() returns and the event loop processes the stop command, it will no longer call loop(), and instead call stop() one time before transitioning to the StopRobot OpMode.

    Leave a comment:


  • zain
    replied
    The whole point of the loop() method is that it should do its thing and then terminate as quickly as possible. If you program the loop() method that way (which is important for additional reasons besides this one), then it won't take long before stop() gets called.
    Yes of course. As you can see in the histogram above, their code typically executes in 15-20 mS or so. As their code reads sensors, thinks, and outputs commands over and over in loop().

    So my poorly phrased question was more along the lines of: When does loop() stop being called and stop() called instead? I would have thought that it would be when the STOP button was pressed. Or when the watchdog fails to see loop() end. Is that not the case? Sometimes it seems to me like it's not the case. Hence my query.

    Are we sure pressing the stop button invokes the stop() method in iterative opmode?

    Leave a comment:


  • NoahAndrews
    replied
    Are you saying that unless the kids code terminates loop() it's not possible to ever have stop() executed?
    4634 has looked at this more recently than I have, but yes I believe that's right.

    And how would they even terminate loop() if iterative opmode is event driven only on button presses at the driver station?
    The whole point of the loop() method is that it should do its thing and then terminate as quickly as possible. If you program the loop() method that way (which is important for additional reasons besides this one), then it won't take long before stop() gets called.

    Leave a comment:

Working...
X