Maybe we should make another class which acts like a stopwatch but cannot be reset?

Change it from BinarySearch<T> to BinarySearch<T implements Comparable>. This way, instead of making BinarySearch#search take an ugly lambda as a parameter, we can have a BinarySearch#searchFor method that uses Comparable#compareTo under the hood to determine if the current object is higher or lower than the target object.

#15 (comment)
If we are using JitPack (mentioned by @andrewda), we probably want to start tagging commits with the current version. I think we can probably agree Semantic Versioning is the best route, but how should we execute this? Should we have some automatic tag system with Gradle or do it manually? I think manual is probably the best option to avoid mistakes, but I am not completely sure. What are your opinions?

This should allow for greater separation of the core API from WPILib-specific helper methods and logging utilities.

Ideally, we would have subprojects for

• The core API
• WPILib-specific utilities
• FTC-specific utilities
• The GUI for viewing PP logs
• A Path-creation GUI

I vote no since this unnecessarily intertwines updating when we might not want to update all sub recordings at the same time... the main recording shouldn't know when sub recordings should update. However, is this makes everything a lot cleaner (i.e., in the visualizer) it might make more sense to do this...maybe.

Concerns the following class: RampUpSimulatedMotor

Problem
The way ramp-up motors currently work is each time a velocity is set for a motor, it must be within dv of the previous set motor or else the motor is actually set to lastVel + dv or lastVel - dv depending on if the desired velocity is less or greater than the current velocity.

This is mainly for voltage localization where the set velocities need to be continuous-like to be able to accurately localize the robot.

However, this current method creates inconsistent behavior in scenarios with special commands with a period of less than 20ms.

Take an extreme scenario. A command is called once every ms. The motor can ramp up much faster per unit time than in a 20ms loop. Of course if you take the other extreme if you have a 1s loop (for some weird reason) the motor would ramp up extremely slow.

This is partially needed... the motor set velocities wouldn't look that continuous if we asked how much faster can the motor get in one second... the motor never is set at intermediate velocities during that 1s time.

Possible Solution
provide a max dv and a max dv/dt parameter for the motor so we can't get insane acceleration when commands are really fast.

It seems like the stop tolerance needs to be REALLLLLY LOW to pass unit tests... investigate to see if this is a bug

it looks like it is looking at the current line where the lookahead is on. This might be wanted though?

Cause unknown to me right now.

complains that a START_ARRAY token is found instead of a {

This might not be needed. If you look at the example project, it can just be contained in RobotData.

PeriodicAction overrides IAction#run()with its loop logic. However, this is kinda bad because some dumbo might not know that he can't override Periodic#run(). Is there a good solution to this?

Concerns the following classes:

• InstantSimulatedMotor
• RampUpSimulatedMotor
• StaticFrictionSimulatedMotor
• BoundedSFSimMotor

The line of motor classes extending each other is a little janky right now and does not appropriately encapsulate isolated behaviors for each motor. This could be done a lot better. Possibly by having some motor velocity processor interface.

Suppose I have the following unit test

   @Test
    public void testActionGroup()
    {
        AtomicInteger atomicInteger = new AtomicInteger(0);

        Simulation simulation = new Simulation(1);
        ActionGroup actionGroup = new ActionGroup();

        DelayedAction delayedAction = new DelayedAction(TimeUnit.SECONDS, 1, ()->atomicInteger.compareAndSet(2, 3));
        delayedAction.onFinish(() -> System.out.println("1 done"));

        DelayedAction delayedAction2 = new DelayedAction(TimeUnit.MILLISECONDS, 10, ()->atomicInteger.compareAndSet(0,1));
        delayedAction2.onFinish(() -> System.out.println("2 done"));

        DelayedAction delayedAction3 = new DelayedAction(TimeUnit.MILLISECONDS, 150, ()->atomicInteger.compareAndSet(1,2));
        delayedAction3.onFinish(() -> System.out.println("3 done"));

        actionGroup.addParallel(delayedAction3); // second
        actionGroup.with(delayedAction2); // first
        actionGroup.addSequential(delayedAction); // last

        simulation.add(actionGroup);
        simulation.run(TimeUnit.SECONDS, 100);
        Assert.assertEquals(3, atomicInteger.get());
    }

In it's current state, it will pass, However, if I move the addParallel call below the addSequential call like so

        actionGroup.with(delayedAction2); // first
        actionGroup.addSequential(delayedAction); // last
        actionGroup.addParallel(delayedAction3); // second

then the test will fail, because the last action doesn't run

Is this a problem? I understand that there should exist at least some rules for the ordering (e.g with should go before the addSequential that it runs with, but delayedAction3 should still run.

We do not need to depend on the entirety of GradleRIO. (we don't need the task gradle deploy for example)

We need a standard order for all processes in IActions... probably

init() -> while(!isFinished()){execute()}

at the time of writing, there were 30 TODO's and I expect the number to increase as I continue writing documentation and noticing things that are off

We should figure out a good way to keep the default code format in .idea/ but also make it so people's IDEs don't keep having "commit wars" on what .idea/ should be.

It might make sense for people to add plugins to the Visualizer module rather than having to modify source. Why?

• The visualizer will be the only module run directly from a client (i.e., it isn't some part of a larger jar like ezAuton Recorder/Core/WPILib...)

• it would be pretty 🔥for people to be able to add plugins to easily get more visualizers. This allows for easily adding/removing like plugins on mc servers.

We should have a maven repo for ezAuton. Should it be hosted on GitHub or some other source? @ritikmishra

Although we should probably keep the main Core and API code in Java, it might be interesting to add another Kotlin module which adds extension functions and utility functions (i.e., operator overloading) to be able to use ezAuton easier w/ the best language in the world.

Right now if the magnitude of acceleration/deceleration from point n to point n+1 is too low to complete the segment, the code will just throw an exception. We should add implementation for smoothing acceleration/deceleration between multiple waypoints, so we can easily have the fastest motion possible between more than two waypoints.

The timestamp that is read on a TimeWarpedClock can be changed by calling TimeWarpedClock#setStartTime. This may create issues where

1. A task is scheduled for timestamp X
2. Before timestamp X, TimeWarpedClock#setStartTime is called
3. Instead of running at timestamp X as expected, the task is run at some other timestamp Y.

A solution would be to only set the starting timestamp when calling the constructor, or only allowing setStartTime to be called once.

It's not even the official logo

Ideally we'd have a separate ez-auton logo or at least a generic image of a robot or something

and combine into one class so code is not 💦💦💦💦💦

To reproduce

import com.team2502.ezauton.utils.RealClock;

import java.util.concurrent.TimeUnit;

class Scratch
{
    public static void main(String[] args)
    {
        long init = System.currentTimeMillis();

        RealClock.CLOCK.wait(TimeUnit.MILLISECONDS, 5000);

        System.out.println("(System.currentTimeMillis() - init) = " + (System.currentTimeMillis() - init));
    }
}

Expected behavior: Main waits for 5 seconds, and then a number around 5000 is printed

Actual behavior: The number of milliseconds it took for RealClock.CLOCK.wait() to happen is printed, then some time happens, then an IMSE is thrown.