Redux Robotics Introduces the Helium Canandcoder

We at Redux Robotics are proud to announce our first product: the Helium Canandcoder. An idea born last year, we’ve spent the last several months making prototypes and field-testing these on FRC robots, and we’re finally ready to release them to teams.

Who We Are

Redux Robotics started when a group of FRC and FTC alumni decided to combine our shared experience and start a company to make performant and open products at affordable costs to teams. The idea grew into Redux Robotics, and the Canandcoder, something that could plug into existing motor controllers, operate on the CAN bus, and simplify the API to the minimum without sacrificing performance for top-end teams. We’re proud to say that we’ve designed our products from the top down, starting with the requirements for low-resource and high-resource and designing something with no compromises. We leveraged our combined experiences as both students and mentors of the program to create something we feel best addresses many of the existing issues in the space.

Helium Canandcoder

The Helium Canandcoder is a CAN-enabled 14-bit encoder with a zeroing button and flexible data port. It interfaces natively with the Spark MAX and Talon SRX using a pulse width output, without fussy adapter boards or cables. If you don’t want to use the data port, it can be easily clipped off to decrease the height and footprint. Wide solder pads make soldering wires a breeze, and the zeroing button allows teams to zero an arm or swerve module without opening any software tools or setting offsets in code. It is directly compatible with many existing and popular products, including COTS swerve modules such as the SDS MK4/MK4i and WCP SwerveX, and we also have a throughbore upgrade package to make it easier to use the encoder on anything with a hex shaft.

The ReduxLib API is designed to be simple to use with simple and easy to understand methods, complete documentation, yet enough flexibility that one can rewrite the classes from the CAN message layer up if desired. We are committed to in-season API stability from the CAN spec all the way up to the Java/C++ classes.

The Canandcoder will be available within the next two weeks at Information about stock, availability, expected restock, and more will be posted to Transparency the moment we get updates. In the meantime, check out for quick links to our API Docs and for documentation on our product! For the programmers out there, we have detailed descriptions of the CAN packets as well as a link to a DBC file here

In addition to the encoder, we are opening up beta test applications for another upcoming product: The Boron CANandgyro, a high performance CAN connected 6-axis IMU. Interested parties can email to be placed on the list.


We have a number of features planned for the Canandcoder to be implemented over the coming months, including:

  • Synchronized readings across devices
  • Microsecond timestamps generated at precisely the same time a measurement is taken, avoiding latency-prone CAN timestamps
  • Automatic latency compensation
  • Advanced velocity filtering
  • And much more

We are always open to suggestions, feedback, comments, ideas, criticisms. Feel free to drop a message on the website, email us at, or reply to this thread, and we will do our best to get back to you. Have a great offseason!


I’m super stoked to see what’s to come, and I’m really looking forward to seeing another encoder option on the market! :grinning:

1 Like

Neat zero feature. I’d love to know more about who the folks behind the product are, as well as what other kinds of products are in the pipeline.

Cool stuff, welcome to FRC vendorland!


There’s at least one thing that will seem really obvious after you notice it.


Who could possibly be behind the Canandcoder and the Canandgyro?


Canan O’Brien


Does the encoder start up with a working getAbsolutePosition method within a reasonable amount of time from boot consistently? One issue we have had with our CANCoders is that they just don’t give you the absolute position, sometimes ever, we have gone entire matches where our robot can’t drive because the get absolute position function just didn’t work, while other times it would start working in the middle of a match.


The encoder will begin broadcasting its absolute position almost immediately from startup. Boot up time is pretty fast, and the same CAN frame delivers both relative and absolute position.


Very exciting on the encoder, we’ll likely want to try them out this fall.

Can you share who owns redux? For some reason I have a mental block about only ordering from FRC vendors where I know who runs them.


As I recall, @Eeshwar is the one running the company, or at least was the most active in promoting it up to its launch.


I believe @Akash_Rastogi asked this as well, so this is a reply to both of you.

Hi there! I am Eeshwar, FTC Alumni, and founder and current CEO of Redux Robotics. I’ve technically done FTC (5 years), FRC (one season), and VEX (2 years), but I’ve interacted with all sorts of FIRST and robotics related spaces. I graduated in the 2021-2022 season, and am currently at the University of Michigan studying CS and Robotics.

I started Redux Robotics in late 2022 to explore the FRC market, having previously had experiences in the FTC market. I am joined by a few amazing people, such as @asid61 who have been incredible to work with. Right now, Redux is a team of 4 people. I’ll let the rest introduce themselves if they want (I don’t like forcing people into the spotlight, but we are are FRC/FTC alumni with experience in a variety of different areas).

It’s been a wild journey to our first product, something I hope to write more about in the future. For now, feel free to ask all the questions you want, and I’ll do my best to answer them!

As for what is in the pipeline: R&D is pretty much nonstop here at Redux. We have the two major products announced now (the Helium Canandcoder and Boron CANandgyro), but we are always looking at where we can go next. If you have any suggestions or features you want to see, please feel free to reach out to us whenever you want, and we will do our best to get back to you as soon as possible.


Zero button is a killer feature. Simple, but saves a lot of software stress.

It’s not clear from the documentation, is the PWM output split out in a solder pad? We found this year that ribbon cable was pretty fragile. It might be nice to solder wires to a Spark Max (breakout board) instead.

The solder pads only have the CAN output. PWM is only available through the 10 pin IDC connector.

If you really wanted to, you could solder a wire to the bridge pads underneath the IDC used to select the output pin. Those are connected to the PWM output. Small pads though, so I’d use good strain relief.

Boo. That’s a sad oversight.

Seems like an aware compromise rather than an oversight.


What testing have you done to ensure that the reset button doesnt get accidentally triggered during a big hit? How hard is it to accidentally hit? Can it be disabled?

  1. It has been run in competition and we have not had issues with the zero button getting accidentally triggered. As a note, it needs to be held for 2 seconds to trigger, so it won’t be triggered by an accidental jolt.

  2. It is not easy to accidentally press, the button itself is small and the case makes it harder for something to press it by accident. It would take a very small piece traveling at just the right speed and direction to cause it to reset (very unlikely)

  3. It can be locked (disabled) from our configuration client


Good idea, alternatively there are vibration rated buttons, but this is a much easier and cheaper solution.

Great stuff! Excited to see another vendor with what appear to be quality products coming out!

1 Like