So it looks like SampleRobot has been deprecated but not really documented.
A little hint here:
https://github.com/wpilibsuite/design-docs/projects/1
It is still listed as valid in the new 2018 docs:
https://wpilib.screenstepslive.com/s/currentCS/m/java/l/599697-choosing-a-base-class
But after updating everything today, no joy in eclipse It is gone.
We liked the control of that base – is there is no direct replacement?
Sheesh. RobotDrive also changed, but that at least seems to be documented.
Between WPILib and CTRE updates, it’s like learning a whole new language.
I’m not sure what you mean. SampleRobot is still in the eclipse new project wizard and still in wpilib and recognized by eclipse.
Maybe some screenshots would help.
Well, our code is now broken after updating everything (java/frc-2018-update…) and I see (attached pic). OK.
When I hover over SampleRobot I get get the dialog (2nd attached pic).
If I accept that, it add the @SuppressWarnings(“deprecation”) above the class def. Yeeeaaahh, not sure the implication of that, but it just does not seem like a good solution.
@SuppressWarnings(“deprecation”)
public class Robot extends SampleRobot {
(yada, yada)
Hmm.
It isn’t documented on Screensteps but it is in doxygen/javadoc. Screensteps tends to lag behind because we don’t have many editor seats for it.
Just fyi, that thing is a bit old. We don’t use GitHub’s project feature.
If I may, how did your team use SampleRobot? If there’s a use-case we missed, we want to know about it. In my team’s case, we did the looping and control flow ourselves with SampleRobot because we wanted to run our code at a consistent interval, not whenever DS packets showed up. We replaced it with TimedRobot and small state machines for control flow in AutonomousPeriodic(). I still teach my students how the control flow of the layer underneath works, but TimedRobot is more convenient.
That was my doing actually (sorry). It provides a much cleaner constructor interface and organizes the inverse kinematic relations in a more logical way. Now WPILib has room to grow to things like SwerveDrive. 
I can assure you more stuff is coming on this front as well as motion profiling. When exactly is determined by how much time I have to contribute.
Your code isn’t broken, and it still compiles. Deprecation is a warning, not an error. That is, deprecation is a strong hint to the user that they should be using a non-deprecated thing instead, but it isn’t removed yet. We deprecate things before removal so people have time to upgrade.
Thanks for the insight Tyler. We used SampleRobot so we had a predictable loop timing – not at the mercy of some system-related constraints that could make it sporadic. We were reading lidar distances and such and wanted some more periodic control over our main loop.
That was my advice to the programmers – for decades I have written embedded code tightly-coupled to the hardware and I always want to be able to throttle the loop speed as meets the needs of the project.
Perhaps it is overkill for FRC, as most everyone uses iterative and seems happy with it.
Where is the new TimedRobot base defined? I don’t see it here:
https://wpilib.screenstepslive.com/s/currentCS/m/java/l/599697-choosing-a-base-class
thx, gil
Here is the Javadoc for TimedRobot if that helps:
http://first.wpi.edu/FRC/roborio/release/docs/java/edu/wpi/first/wpilibj/TimedRobot.html
Thanks for the link Evan – I had just stumbled on the cpp doxygen but had not found the java info yet.
TimedRobot looks like a perfect replacement for our needs. I will toggle a DIO and put a scope on it to see how it behaves over a range of loop delays.
A muuuch better solution than using a deprecated-but-still-valid bit of code (and having to defend the rationale behind it).
Now onto the RobotDrive tweaks, finding out if 2018 update fixed the broken I2C transactions we had to work around last year, figuring out why the radio config utility can only do a firmware update and not actually update the radio’s config (this was a problem last year as well, but seemed to work after 5 or so attempts, even at the regional kiosk, but I digress).
thx
If you discover this still exists, file a bug on GitHub with a test case and we’ll get the relevant people involved.
Sure Tyler. What I found last year was that I could not get the i2c transaction working on the roborio, or even the register read (both of which use a repeated i2c start) – the clock line would hang low for about a second and then it was done. This prevented me from talking directly to my sensors in their native i2c fashion.
However, I found that a simple write-only or read-only i2c method would work on the 2017 roborio distro, so I used that as a work-around and added a teensy (tiny arduino-ish module) onto an mxp board as an intermediary coprocessor and off-loaded the sensor interface. Sometimes you just need to do what it takes to get the job done. It worked well.
I have been using i2c since the early 90’s so this is not new territory – I have never had as much trouble getting a device to work as with the roborio. I will test it again with the 2018 code. I have the needed storage-scope/logic-analyzer… to test it properly.
thx
