montclairrobotics / alloy

An FTC robot framework designed for both experienced, and inexperienced coders to be able to code highly functional and reliable robots

Alloy

Status: Beta

Alloy is a robot framework designed specifically for the First Tech Challenge (FTC).

Alloy is based off the FRC robot framework Sprocket, but redesigned to abstract away the more complex ideas but still allow for advanced robot functionality.

Note: Alloy is still under heavy development, and not ready or suggested for use in creating a robot

Developed by FTC147 and FRC555

The goal of Alloy is to provide a robot framework that allows anyone, including new programmers, to be able to implement high functioning and quality code for their robots. In other terms, Alloy aims to prevent robot code from being a limiting factor on the performance of the robot.

Alloy is a robot framework designed specifically for the First Tech Challenge (FTC), but is also designed with expandibility in mind. FRC implementation is possible and will be coming in the future.

Alloy is based off the FRC robot framework Sprocket, but redesigned to abstract away the more complex ideas but still allow for advanced robot functionality.

Any information regarding Alloy, including how it works, project structure, as well as in-depth explanation on how to use all of the components can be found in the project Wiki as well as a quick start guide.

Formatting

Alloy uses the Spotless code formatter to ensure that all of the code follows a specific format. It is added as a build step for a gradle build so this means that all code in alloy must be compliant to be merged. Spotless allows for automatic code formatting, just run:

cmd> gradlew spotlessApply
:spotlessApply
BUILD SUCCESSFUL

cmd> gradlew build
BUILD SUCCESSFUL

FAQ

Q. What is the purpose of/how do I use ___?

A. Every class is heavily documented as well as wiki articles explaining the use of more complex/important parts of alloy

Q. I tried to update ___ method using @Update, but it isn't working?

A. The way alloy is designed, is that everything is split up into components, and a method can only be updated if it is within a component. you can read more about this topic Here

Q. What is a component/what is the difference between the components?

A. Different components have different purposes, for example, a control component would be used for an advanced control system, whereas a motor component, or motor ocmponent group would be used to control a drivetrain or manipulator

Q. What if I don't want to use components?

A. Things can be done in alloy without the use of components, but if you are designing code for a specific tool or component on the robot, such as a shooter, drivetrain, or control system, it is highly recommended as components add extra functionality like toggleability, easier debugging, and updateable methods. But again, all of this can be done without the use of components.

Q. ___ isn't working.

A. If you have a problem first see our Troubleshooting guide. If that does not fix your problem you can file an Issue using our issue template, please provide as much information as possible so we can fully understand the probelm and fix the issue.

alloy's Issues

Create JSON file handler to allow on robot code

FTC team 6347 Geared up had the great idea of storing information about the robot code in a json file so it could be edited on the robot phones

I was also thinking about the possibility of having a "SmartDashboard" for FTC that could be used in testing and debugging

Make InputCompnonents more efficient and updates in general

Many input components have un-necessary update methods that will update the output each loop, no matter if they are being read from or not. These can simply be shifted to the output-input (hehe) so that the values are only updated when they are read from

Acceleration Limiting

Add an acceleration limiting step for inputs.
The acceleration limit should take in two differential objects that are able to keep track of the linear acceleration and rotational acceleration

There will be a total of 3 acceleration limiters

• Rotational
• Linear
• Both

An example of the differential objects is as follows

// Get from accelerometer
Differential linearAcceleration = new Differential( () -> velocity);
// Get from Gyro
Differential angularAcceleration = new Differential(() -> angularVelocity);

Although it may be possible to completely bypass the step of creating differential objects to handle the calculation, due to build in functionality of the Accelerometer and Gyroscope APIs

The next challenge in this problem is converting acceleration to power in the motors.
This means that the best way to limit acceleration may be to apply a PID controller to keep the motors moving at a constant acceleration as defined from an Input

This could also be done more simply with a step like

public DTInput getOutput(DTInput input){
    Angle angularOut;
    Vector linearOut;
    if(linearAcceleration > targetAcceleration){
           linearOut = input.getTranslation().scale(1 - (scalar)(targetAcceleration - linearAcceleration));
    }

    if(linearAcceleration > targetAcceleration){
           angularOut = input.getRotation().scale(1 - (scalar)(targetAcceleration - angularAcceleration));
    }

   return new DTInput(linearOut, angularOut);
}

Or something along those lines. I will implement and test various implementations for this. And update on this thread

Create version 2.0.0-beta that implements use of components in all parts of Alloy

There are many implementations that can be rewritten using the core idea of a component, as the component ideology of the project has developed over time, i believe possible rewrites of certain aspects are needed, including the actual component classes themselves

Debugger should have levels

All debuggers should have different levels so that the user can switch between how much information they are getting

Optional Naming in components for debugging

Most of the time, naming for debugs is implemented on the class level. By having an option to set the name at the superclass level (Component class). This could be made much more straightforward, and scalable
Ex:

private String name;

public void setName(String name){
    this.name = name;
}

public void debug(){
    // Whatever Debug code is there
    Debugger.debug(name, debug);
}

Names will not be handled in the constructor, as they are optional

Add automatic code formatting for uniform code format

Alloy should have a uniform code format throughout to reduce errors and increase maintainability and readability as well as enforce a standard throughout the project

Here is a link to a good code formatter that can be used with Gradle: https://github.com/diffplug/spotless/tree/master/plugin-gradle

Include Tolerance in BangBang Correction

Make it so that bang bang corrections have a tolerance in which they will return no output
if(error < tolerance){
output = 0
}

Rolling back code

I'm not sure how exactly this would be implemented, but the general idea is that, when an error is detected in the code, that would stop the robot from running properly, the code would store and check previous versions of the code that works, and would swap out the code.

This would probably require a robot reboot, either automatically or by the operators, but it is still better than having a robot dead mid-match because of a code crash, there could also be manual resets to allow the drivers to revert back to previous working code, in case of a runtime error, that can only be detected by a human (eg, inverted controls, wrong speed scaling, etc).

The system would probably store 3-5 versions of past code, that will undergo automatic and manual checks. For example, if code crashes either during a match or in testing it will automatically be tagged as "Bad" code. Code that was ever manually reverted would also be marked as bad. The user would also be able to version their code, to eliminate all code from previous versions, for example, if there was a physical change to the robot that would prevent all past code to stop working, it would all be tagged as bad so that even code that was technically "working" would not be deployed for a robot that it didn't work for.

Again, like I said I don't really know how this would be implemented, and I'm almost sure that it will be a project on its own, and there are many problems that have to be worked out, like how the code would almost definately need to be stored on the RIO so that there aren't long transfer times putting new code on the robot. And even though, no matter what, replacing the code on the RIO would definately take time, valuable time that the robot is immobile for, a 20-second loss is a lot better than a 2-minute loss if the robot becomes dysfunctional at the beginning of the match

Motors do not disable when disabled

Motors need a rework to work as components

Updater does not update methods in a per instance basis

The updater needs to update each method for each instance, rather than updating things from a static context

Fix package reference for autonomous

Need to figure out how to get the package for auto modes

Utils for alloy

In alloy, there is going to be an included Utils class that contains common rather simple self-contained algorithms to aid in writing code. For example, a constrain method. What other methods should be added?

Fix Modules to acutally set the offset

Add robot setup and init as separate methods to allow for multiple teleop modes

Currently the only teleop mode is default the robot class. This can be worked around but there is no easy way to do it. Add an abstract robot setup class that is separate from the teleop init so that different teleops can extend the robot class.

Change setDriveTrain and getDriveTrain methods in Alloy Subclasses

setDriveTrain() and getDriveTrain() methods are not implemented in the alloy subclasses. They should be implemented to get and set the static drivetrain

PID Wrapping

The PID inputs need to be wrapped so that for example, a gyro at 350 degrees, does not make a full circle to go to 10 degrees.

Updater does not access non alloy classes

Because the updater is using reflections, it cannot access non-alloy classes. There are 2 ways to do this, have an Alloy.cfg that keeps track of any extra information, like the location of the files, and I think there is a way to get the file path using reflections