Valor 6800 - 2022 Reveal

Valor 6800 presents our 2022 robot: Diablo

Reveal video:

Technical information: 2022_diablo_tech.pdf (955.0 KB)

Our robot will be competing week 1 and week 3 at Dripping Springs and Austin Texas District events.


Wow!! Amazing job guys!

I am scared we would dent the driver station at that speed!


Looks great! Excited to see you at state!


Super cool. Love how far the team has come in the last few years. If I ever end up in Austin for an extended period of time I’d love to check your team out!


So the shooting and scoring two more balls before the first two y’all shot are returned to the field is cool and all…

But running the intake full speed into the wall?? That’s a new level of robot reveal flexing


Fantastic design, we are looking at making a similar climber, and we have a few questions:

  1. Can you drive over the carpet protector? It looks like your gearbox/elevator is incredibly low to the ground, Would let you drive over it in 1 orientation but not the other. After reviewing some design sketches, it looks like you need every inch of travel on the elevator
  2. Interested in how you handled the articulating arm axle, can you share any screenshots/descriptions of that assembly?
  3. What is the arm made of? Aluminum round with wood epoxied to the inside? We are looking at using a 2x1 1/8" tube instead, for simplicity and increased cross section
  4. How complex is the code? It seems like there are a ton of different commands, interested to hear how much of the climb is automated

1 more question, how did you handle the encoder/stall detection on the neo 550 running the arm? We had some trouble smoking these last year, and my programmers tell me we need an external encoder, but it has 42 ticks per rotation*100 = more than enough??

Not on 6800 or familiar with their design but I can answer the general case: I don’t see why you would need an external encoder for stall detection. 4200 ticks per rotation is higher resolution than you’ll get out of most external encoders.

However, an absolute encoder (as opposed to the relative encoder on the NEO) would possibly be helpful. That would need to be mounted externally such that it rotates less than once throughout your entire range of motion (i.e. 1:1 with the arm, or you could get away with 4:1 if you were only moving 90° for example). Personal opinion is that stall detection based on current thresholds is fairly finicky, and will also necessarily cause some wear and tear since you need to stall the motor against something for a bit. I’d much rather use limit switches or an absolute encoder.

its a little awkward to run it without stall detection, because of how you have to hook onto the next bar. You have to run the arm until it hits the next bar, and since you could be swinging, you can’t easily predict what angle to go to

1 Like

Of course, that makes sense — I was thinking in the context of e.g. an intake arm. Yes, in that case current-based stall detection is probably the way to go, since putting sensors up there would be a pain. You might not even need an encoder for that, but if you were to use one then the integrated encoder in the NEO 550 would be more than enough accuracy.

You should set a current limit on the NEO550, that will prevent it from smoking. Set something like 25A. sparkmax.setSmartCurrentLimit(25)

For stall detection you can look at the output current directly with sparkmax.getOutputCurrent(). This needs a little bit of extra logic because current will spike when you first start moving the motor. But this is simple enough, just check that the current is above some level for some time. You can determine that experimentally.

NEO500 encoder accuracy is more than enough.


The gearbox is indeed incredibly low. 1.25" off the ground to be exact! But its the same clearance as our bumpers, so therefore everything is protected and we do not need to worry about the cable protector. It was done like this to 1) lower the CG as much as possible and 2) yes, gain every inch of extension as possible

1.25" aluminum tubing with a wooden dowel stuffed inside it. And when I say stuffed inside it, it literally was 2 mentors smacking the tube against a concrete floor as hard as they could until it somehow fit…

Funny enough, the lift subsystem has the most simple code of all the subsystems on our robot. We use C++ as our coding language and design everything in state machines - therefore it is all state driven and do not use commands. We use REV smart motion with soft limits, so we just specify the target encoder position, and let the built in motion profiling take care of the rest (assuming it was tuned properly, which it was!). We have manual control as well which is what our driver is using now until we actually have time to tune the automated sequence.

Our source code is actually all public so you can see it here:

Like Will and Zachary have stated, stalling out the neo 550 is not a problem whatsoever. It is geared so heavily that unless you try driving it into the bar for 3 seconds straight, it won’t have a problem.

We have current sensing in other parts of our code, but don’t use it for the lift (yet). We use a circular buffer to keep track of current history within a set timeframe (dictated by the circular buffer size), and take the average of the buffer to determine the current draw. That combined with current limiting will do everything you need it to do

Very much so. I don’t think we will ever go back to using additional encoders since the brushless encoders are plenty. Note: Relative vs Absolute encoders are a different ball game


Thank you so much for the answers, people like you make this community what it is :slight_smile:


I have a problem with shooter. If you are a shooter with a single Falcon and a toproller, will your strength be insufficient?

Adding more motors to a shooter does little to the actual shot, what adding more motors does is improve the recovery time to shoot more shots in rapid succession. A shooter spinning at 4000rpm with one motor is not going to shoot much differently than one spinning at 4000rpm with two motors. Yes a single motor cause more speed to be lost while the ball is in contact with the shooter but this effect is far from enough to cause a single motor to be insufficient.


Thanks. So a single Falcon can shoot the ball about the same distance as a double Falcon?


1 Like

Because of the cancellations and the suspensions, we haven’t tested yet :joy:

1 Like

Many teams only used 1 falcon for the shooter. It is very reasonable, if you gear it correctly


Why did Valor choose C++? Are there noticeable performance gains from it being a compiled language? Is there a good reason for a historically Java based team to switch to C++?