TBH tuning issues

VEX V5 General Discussion General Forum
#1

My team has a single flywheel launcher that we have programmed to run on what we call “manual control”. This basically involves not using any sensors to set the flywheels speed, and we usually set it to about 80/127 motor power. If we load the balls at a consistent rate, we can make 60% of our shots, and the 40% are due to human error and not loading them at the right time (if we wait too long, the flywheel goes too fast and we overshoot, if we don’t wait long enough it undershoots)

So we figured that it was time to implement a TBH or PID code to try to keep our launching at a consistent speed. For now, due to the fact that it is simpler, we are going with the TBH code. We programmed it in, and did our best to fine tune it by adjusting the gain and by adjusting the speeds the launcher is to be set at. If we launch about 50 balls, we miss the first ten due to either overshooting or undershooting (one run it will always overshoot, and the next it will always undershoot) then the next 20 will make it in almost with 100% accuracy, then the last 20 or so are all over the place.

We ruled out any issues with battery voltage (even though the code should compensate for that already) and we tried adjusting the gain more as described in the thread about TBH tuning that was recently posted, but no matter what we do we cant seem to find that sweet spot.

Bpalms had stated that “Once you do start tuning however, it essentially takes 5 minutes to get the value right, and your flywheel should be golden.”

we have been trying for over a month and just keep getting frustrated with coding and usually get burned out for a few days, then revisit it.

I also tired this method of tuning posted by VEX9185:
First, I would double the number. It will now be 0.0005. Now run the flywheel and shoot some balls, while writing velocity into the debug stream. Then, use an Excel (or whatever you prefer) spreadsheet to make a graph. See if the speed up is overcompensating. If it is, lower the gain by 0.0001, and raise it if it can gain more. Keep tuning. I would go for 0.000X0 or 0.000X5 because that is relatively quick to get to.

Nothing seems to be working, and we have been struggling with this for awhile. It seems like it should be pretty simple to get this down, so would anyone care to share ideas for how to get the proper Speed Values to launch at, and the proper way to go about tuning the gain? We are guessing at the values and experimenting with the gain, and i feel like we are managing too many variables at once… any help would be MUCH appreciated and i would also like to know if anyone has actually had success with the TBH code. Thank You!

#2

Try making a graph of your RPM to see how it is reacting. This really helped my team push it to go as fast as it can go. Right now I would estimate that we can shoot about a ball per second with about 85% accuracy.

#3

How did you determine what values to launch at? did you come up with values first, or adjust gain first?

#4

We ran our motors at a set speed, the adjusted so we made shots pretty consistently (fire rate does not matter here). Next we created a speed test program that set the motors to that power and calculated the rpm. Then we just plugged the values into our competition project and tested and adjusted as necessary. We were able to get it up and running pretty quickly without a graph, as we already had a pretty good feel for the robot, since we had a PID controller on it before. The TBH gain should be a a little more than your PID gain. After we had it up and running, we just used the graph to optimize it even more.

#5

After testing and coming up with values for launching, in what manner would you suggest we go about graphing results to adjust our gain? We have not successfully programmed a PID so we are working on our gain for the first time. How should we go about making a graph of the RPM while making shots? how will we use this to help adjust our gain? sorry, our club is very new to the more advanced programming

#6

Visualization is a powerful thing.

To graph the RPM you want to write debug stream line commands and log a bunch of values. Make sure you are waiting at least 10ms between log points.

Log the program time, the calculated RPM (instantaneous computation or leveled rpm is up to you), motor power, gain value, etc.

Make sure you have a delimiter in between each value. I prefer using the | symbol.

Save to a file or copy/paste into Excel or Open office

Parse the data into columns. text to columns, choose the delimiter, and output the columns.

Graph the RPM and motor power versus time on the X axis. You will need to use two Y axis or two graphs for showing RPM and motor powers.

You will then see the oscillation of wheel speed as the algorithm adds or takes away power versus the RPM. It takes a little time for the motors to react to your power changes and a bit longer for the wheel speed to get to what you want.

As you adjust your gain values you can see the take by half reacting accordingly.

You may want to run some controlled tests near the target RPM so you can see the step values a new motor PWM value gives you. In theory you will be speeding up and slowing down to achieve that in between target RPM since the PWM signal will increment by 1 and that may yield a set RPM difference of more than you like (depending upon your gear ratio and friction). So know you what you are able to achieve with your set up as far as fine tuning goes.

#7

Thank you! that is a very helpfull explination, the only thing i am left wondering is how to properly send my variables to a debug stream? After some research i found the code


writeDebugStreamLine("int x is: %d", x);

But i do not understand the


("int x is: %d", x)

line
would you be willing to explain how to tell it to send out basic variables to the stream? if i wanted it to send out my (SensorValue[launcherS]) value, gain, and my MotorPowerSigned, how would i go about that?

#8

I think you can think of %d as sort of a placeholder for where the variable will go. This website has a good read with all the format identifiers (or what goes after the % depending on what you are printing): https://www.lix.polytechnique.fr/~liberti/public/computing/prog/c/C/FUNCTIONS/format.html

So what you are writing is print the string “int x is: %d” and when you go to print the string, replace the %d (which I believe stands for decimal) with the value of the variable after the “,”. So you could say:


writeDebugStreamLine("I am writing the value of the variable RAND: %d", RAND)

To write the value of SensorValue and gain and MotorPowerSigned you could create a small function that checks and writes the values:

void WriteDebugStreamInfo()
{
	int sensorvalue = SensorValue[launcherS];
	writeDebugStreamLine("SensorValue: %d | Gain: %d | MotorPowerSigned: %d", sensorvalue, gain, motorPowerSigned)
}

or something like that :stuck_out_tongue:

#9

You forgot to put the variable values for the %d to fill in…

For the parse to work correctly in Excel, leave out the labels each time. Trim out the spaces as Excel can mess up on that too. You can write a header line.

Call this once to put in the headers for Excel. Easier than doing yourself but you have to stay on top of it as you change what you log.


void initDebugStreamInfo()
{
	writeDebugStreamLine("nPgmTime|gain|motor_val|sensorWheelValue");
}

Then call this any time you want to write debug info. You can pass it in as variables or grab them inside the function.

I suggest using a USB A-A cable between the cortex and joystick to allow for maximum data rates. The keys sometimes can’t keep up and you end up trimming out partial lines in Excel.

void WriteDebugStreamInfo(int gain, int motor_val)
{
	int sensorWheelValue = SensorValue[launcherS];
	writeDebugStreamLine("%d|%d|%d|%d", nPgmTime, gain, motor_val,sensorWheelValue);
}

Having the nPgmTime (or you an use system time) makes the graphing against time possible.

#10

Wow… well that went well :stuck_out_tongue:

I guess I did say “or something like that” :smiley:
FIXED

#11