FRC Neural Network - HELP

I created a neural network. 3x8x16x8x2. Activation is tanh.

It took in delta encoder values one for each dt side, a millisecond clock value scaled for a 30 second auto between 0 and 1. The outputs were two values between -1 and 1

I scaled them up to -12 and 12 voltage-current values to control each dt side.

For back-propagation, I wrote a recorder to capture the voltages of the motors at every watchdog interval using a customized mutex timing lock (thread-safe), then scaled the values and back-propagated them into the net.

Doing a recording of the dt values, the clock, the voltage values was what I wanted to be the equivalency to a ‘path’. Then after say 10000 training iterations, the path would now be “stored” in the brain of the network.

To at runtime all the auto would do is preload the brain dat file, and during auto just passin the delta values, and a clock value and get the supposed voltages the talonsrx’s needed to stay on path.

It just spun in circles.

When playing back the recording, (ie letting the robot drive the recorded path) I got smooth results.

The AI is supposed to help with corrections in the path (floor, wheels, carpet threading). The thing both the recording and pathfinder can not do.

If anyone is interested in paring on the side to help develop something like this, I have a baseline multi-threaded neural network c++ that runs very smoothly even in large networks. Hit me up.

1 Like

I’m having a bit of a hard time understanding what exactly you’re trying to do, so I’ll lay it out what I think it is here and you can correct any misunderstandings I have before I give any advice.

  1. You have a hand written multi-threaded neural network implementation with backprop.
  2. You are feeding it an array of [t, left delta ticks, right delta ticks] or something similar. And here delta ticks means how many ticks you are away from where you want the wheel to be or something else?
  3. You want to output 2 voltages to apply to each motor.
  4. You are training it on X (how many?) recorded sequence of these values from an auto.

It looks like the goal here is to use a neural network as a feedback controller for autonomous, is that correct?

1 Like

This sounds like a very interesting idea. I have a little experience with using neural networks in FRC (This past season, we attempted to use one to control our flywheel speed.). There could be several things causing the robot to spin in circles:

  1. Not enough training data
    The goal is to have the neural network to create a smooth interpolation of all of the training data. If you don’t have enough data, it won’t be able to do this.

  2. Neural network too small (not enough neurons)
    If a neural network is too small, it will not be able to create a good model of the data.

  3. Neural network too large (too many neurons)
    If a neural network is too large, sometimes it will just memorize the training data so that there won’t be good (if any) interpolation between the values.

Also, the issue may be that you are using too many hidden layers in your network. I recommend starting with one or two hidden layers and then increase as needed. It may also help to gather some data for testing as well. This can be used to determine how accurate the neural network is.

1 Like

How many times did you record a trajectory? If it’s only a few then your NN might be memorizing those and not interpolating.

Also out of curiosity, why did you go with a neural network approach as opposed to something simple like a RAMSETE controller?


On a related note, did you consider using simpler machine learning techniques, such as a linear/polynomial regression or random forests? Neural networks are fantastic tools but without very large datasets they tend to memorize the data (called overfitting) instead of learning the underlying patterns.

  1. Correct, it has been tested, the net itself is (thread-safe)
  2. [
    ms clock for a 30-second auto-scaled form 0 to 1,

delta encoder position left dt at that very moment (because of watchdog the values range from like -5 to 5 encoder tics when running full speed across the field so I divided by 5 to scale between -1 and 1),

delta encoder position right dt, same thing.
3. 1 current voltage for each drivetrain side, obviously a 6 motor drive train, one or two of the desired motors would be the inverted voltage value
4.Roughly 10000 epochs of the entire recording. (It took 20 minutes)

Yes, and for it to beable to adapt quicker than anything path finder can do.

I think you are right in the fact that I don’t have a correct topology for this size of data. That’s something that requires much more further testing.

I didn’t want trajectories, not even something that took one of the recordings, and smoothed it out to be a trajectory. I wanted to record a path/treg, pass it into a neural net to train. Then just call the nn to give me an either better/more refined path. But still, take the path it was trained on.

That’s what I don’t believe it is doing at all. The goal is for the neurons and weights to be the “path”, It has to have some sort of memory to do that. In terms of other things to try, I am really looking for a Neural-network to be involved rather than just some complex math for regression. I need to find a solution because the dateset is as small as I can make it, I need I believe to find a correct topology to get it functioning…

For a neural network to work well, you need the exact opposite for training: a very big dataset.


I’m still confused. From what I can tell, you’re driving the robot manually, taking recordings of encoder measurement changes and timestamps, and having the NN reproduce that on the robot and correct for errors? If that’s the case, I don’t see why you’re avoiding using a trajectory. Its very simple, and in fact you could make one that passes through points on the NN. Also, I will say that encoder deltas may not be enough to robustly control the robot. RAMSETE also keeps track of x and y of the robot on the field, and that’s the only way to guarantee it’ll get to where it needs. Otherwise, any small error will cause a deviation from what you want that can’t be corrected for.

Also, about this, neural networks are just really fancy regression. You take input data, try to map it to known output data by minimizing some cost/loss function

1 Like

I meant the data itself is in the smallest format, the recordings last 30 seconds, at 20ms intervals that’s roughly 1500 iterations of storing 5 data points, the 3 inputs and the two back propagation values. Say that’s 5 floats at 4 bytes per float, all stored in binary instead of ASCII, that’s roughly a 29.29 mb file. Which is ONE epoch. that then 5000 or 10000 times training is an insane amount of time. not even considering the rest of the networks topology. Say if one epoch takes 1 sec to train on and back propagate, that’s 5000 seconds or 1.4 hours for one set of training. Not realistic numbers but I’m just saying a max of 1 second to do that on the roborio is a lot of processing time.

Are you training nets on the RoboRIO?

You understand it perfectly. Except for the reasoning that the neural net would be the thing doing the correcting in an active sense.

That’s what I’m thinking, I am open to other data values to be passed into the set but I used encoder values to give the robot position, the clock as a program timestamp, and delta values to give it a sense of velocity.

A trajectory does it fine, very well to be quite frank. The challenge and eye-opening project for years to come would be if I or someone else can get this working. No one but I has my neural net code. Its been optimized over the past few years to run on such a small computer like a roborio during runtime, that’s my leg up on the FRC AI community.

Yes and the reasoning is more active testing, I cant make a recording save it, open it on my big powerful pc, train it. SSH over the brain file and then reload it to test. I felt if I could make the net multi threaded and more robust, It would function on the roborio as intended.



Couldn’t you also use a coprocessor for this?

1 Like

I see what you are trying to do, but I don’t think it’s actually doing this. You said that you are taking encoder data and timestamps as input (if I understand correctly). These are going to allow your net to control wheel rotation. If traction is lost, for example, your net will decrease voltage to maintain the same wheel rotation speed as expected at that point in time. The problem is that wheel rotation speed is not the same thing as robot movement, due to the factors such as traction loss, bumping, etc. that you are trying to compensate for. I don’t know what sorts of sensors and data you collect on your robot, so I can’t advise a better metric, but selecting different metric(s) to optimize (instead of or in addition to encoder data) might allow your net to better control robot movement rather than just drive train movement.


Okay, I think I see what you mean. So it’s more of just a demonstration of what a NN could do in FRC so you could use one for something else then?

It’s possible the reason it’s spinning in circles is that your data is fundamentally noisy. So when you run it on the robot, you’ll get different encoder data than you did in your recording. Depending on the weights and biases of the network, your activations might be approaching 0 or 1 which would definitely cause it to spin. Maybe try graphing applied voltage over time on the dashboard? You would really need more than 1 recording to get anything meaningful. But then the problem becomes human error in reproducibility. Also, how well are you validating your network before testing?

Also, about that, I’d just like to remind you about rule R15 and similar rules other years’ games have

If I understand it correctly, it seems like you can only keep the code to yourself if it’s not on the robot if you’ve been developing it for multiple years. So just make sure that whatever you’re doing complies with the rules, this one particularly is very easy to forget. But then again it’s basically never enforced so you could argue it doesn’t matter lol

1 Like