Things FRC teams do better than NASA

Hey all,
I have an internship at MSFC this summer, as a result of working at a NASA facility there is a lot of news that is pushed around within the agency, some of it internal links, some of it not. This is an example of the latter.

NASA/JPL’s flagship rover, Curiosity, has reached a milestone where it’s wheels reach ~60% of usable lifespan. There are holes in the wheel skins, there is some separation of the grousers (traction ridges). That’s all well and good because the rover will reach the terminus of it’s primary mission trek at around the 40-50% wheel life remaining mark. So far no problem, but here is where the baffling stuff begins.

Even before 2013, when the wheels began to show signs of wear, JPL engineers had been studying how to reduce the effects of the rugged Martian surface. On level ground, all of the rover’s wheels turn at the same speed. But when a wheel goes over uneven terrain, the incline causes the wheels behind or in front of it to start slipping.
https://www.jpl.nasa.gov/news/news.php?feature=6887

So if I’m reading this right- all wheels spin at the same RPM. Since Mars is obviously not a flat surface there will be some side loading, wheels temporary bearing next to none/ more than their fair share of the load, some traveling up an incline while others are on flat ground, etc. but all the wheels spin at the same rate regardless.

Now in our perfect little world of FRC we have a nice flat playing surface, at least for the most part, this allows for the good ol’ tank style drop center drivetrain, which is FRC’s way of limiting some of these effects, (among others, no hate omni wheel crowd). Now obviously Curiosity > FRC robot and marsRover.hasEngineeringTradeoffs() returns True But since this is a software “solution” (not that there could be a hardware solution) one would think that this would have been part of Curiosity’s drivetrain code since day one.

You may be surprised how often hardware is launched into space without proper code, and sometimes hardware is rescued with clever code. But due to the scale of this mission I was somewhat taken aback that one of the most significant parts of what makes a rover a rover - being able to move - was not perfect and was seemingly so simplistic. Many FRC teams take wheel performance/lifespan into account when designing their bots. Yes there are some very well established rules of thumb that you will be hard pressed to find an exception that breaks those rules. And yes, the FRC community has had a lot of brain power move through it’s channels over the years, collectively dwarfing that of curiosity rover design team. But many a FRC drive train CADer, or pit crew member, or mechanical systems mentor would consider ways to limit wear on wheels over the lifespan of their robot. The solutions for dealing with the problem between a Martian rover and a FRC bot are vastly different, but the thought process is there. If anything this proves why keeping FRC on you’re resume is important to employers.

What other instances can you come up with that industry, in particular NASA, could take out of FRC’s book? I know that I am grossly over-simplifying the Curiosity rover situation, but all I’m looking for is things that FRC teams consider/do on a regular basis that may not have as significant of weight on design challenges in the real world.

Regards,
Skye Leake

I would highly recommend not bashing a place you intern for (and may want a full time job at) publicly with titles like “Things FRC teams do better than NASA”

Those engineers spend thousands of work hours on and years of schooling compared to high schoolers who can only hope to be working on awesome technology like that one day.

Duly noted, but I stand behind my initial post.

You are totally right about the title being a bit aggressive and “click bait-y”, that was by design. The content of the first post is a different tone entirely and reflects my surprise that wheel speed wasn’t individually controlled, not that that necessarily means anything on the internet…

As for potential employers seeing it… let them, at least they know I’m outspoken if I see an issue. Better than dropping a 2.5Billion dollar paper weight on Mars.

RT!

But actually, please be careful what you post on the internet, especially if you are saying anything negative about current or potential employers! All it takes is a quick google search of your name for an employer to find a reason not to hire you!

Ah yes the $2.5billion paperweight other FRC alumni helped design (including from my own old team).

Please tell me more.

On another note on why this thread is a terrible idea, it is also highly undermining the amount of research that went into that specific design trade off.
If you look into the trade off more you will realize it was a very thought out decision and not one that was undermined.

Specifically-

I can assure you NASA is going through every safety factor imaginable and launches into space with the intent through their various contractors and suppliers of performing the best of their machine’s (rocket, rover, satellite, ect) ability.

Also comparing a wheel on Mar’s wear and tare to an FRC bot that literally gets run for 4 months compared to a wheel that gets shot off in a controlled bomb to another planet on a surface that no one has ever felt before is not only a stretch but ridiculous.

And why did NASA use really expensive motors? Don’t they know 775pro and CIMs are cheap? You can make a much lighter system with 775pros as evidenced by CD trends.

I state the absurdity of the comparison several different ways over the course of the post. I know full well space hardware is over engineered, over analyzed and undergoes more design reviews than easily counted. FRC and NASA have very different agendas and requirements for a successful product. returning to my statement:

I know that I am grossly over-simplifying the Curiosity rover situation, but all I’m looking for is things that FRC teams consider/do on a regular basis that may not have as significant of weight on design challenges in the real world.

Wait, did you just curiosity a 2.5 billion dollar paper weight…

Also, pro tip for when you are looking for a real job, being out spoken about a potential issue and doing so in the proper channels is ~very~ different from publicly bashing a crowning achievement of an organization you work for

I assume Skye is referring to the Mars Climate Orbiter in this instance. At least, I hope so.

its_time_to_stop_posting.jpg

They should have tested the rover on Regolith to understand a low gravity situation…

I think this is the main argument against everything you’ve said. When engineers build complex things like NASA rovers they spend hours perfecting it to the best of their ability. The article says they spent 18 months testing it, so I think it’s safe to assume it’s not as simple as


if wheelSpeed > average
    slowDown()

There is a lot that must be done and tested on these rovers, since once they’re in space, that’s it. No changing wheels, no patching holes in the treads, nothing. This was probably not something overlooked, but they probably had to figure out a solution that wouldn’t make things worse. I’m surprised someone in the organization For Inspiration and Recognition of Science and Technology doesn’t recognize the amazing feat that thousands of people have worked so hard to create.

For the non-“bashing Skyehawk for things that clearly weren’t what he was saying” portion of the thread… stating the obvious, what FRC teams do is far faster than the design process at most engineering companies (using lots of benchmarking and design heuristics). The result is robots that are heavier, costlier, and far more or less robust than they would be in a more “normal” design competition. Really, just about everything is thrown out the window in order to build a robot quickly, that can perform a task well for a few minutes at a time (and even the latter is rarely done as well as expected).

Other tidbits: I suppose FRC teams tend to do fewer design iterations and make larger changes from iteration to iteration. You could also argue that FRC teams teach better than engineering companies, but in my experience, the frantic pace of the build season doesn’t help in optimising that aspect of the challenge. Based on the posts in this thread so far, I’d also say NASA and FRC teams inspire strong opinions similarly well.

I was not, although that would have been a prime instance to speak up vs keeping quiet.

I worded something a bit poorly:

This probably should have been stated:

… Better to be outspoken about a potential issue than risk dropping a $2.5B paper weight on Mars.

I was not inferring that Curiosity is itself a $2.5B paper weight. It’s a fabulous piece of hardware.

EDIT:

Wow, that cuts pretty deep. Sorry I appeared to come across in such a way that I was seeming not acknowledging Curiosity as a great achievement of modern space exploration…

FRC does build speed and major changes better.

However, unlike most FRC teams, NASA isn’t usually trying to finish their robots on the launchpad (Thursday at the event, in FRC terms). They’re long done and inside their fairings.

NASA also does more of their big changes back in the prototyping phase, rather than in the final-product phase.

Oh, and NASA also coordinates with many other space agencies to either fly their resources or get NASA resources flown. When’s the last time your FRC team coordinated getting parts from 20+ different teams onto their robot, and parts from your team to those same 20+ different teams to fit o their robots? (That’d be the approximate scale–about half the teams at the event, about half the space agencies around.)

Yeah, I’d say that NASA knows what they’re doing, in ways that FIRSTers may have a hard time figuring out. Sometimes it takes a while to get enough seniority/experience to know why things are the way they are.

Excellent point about pulling together everything required for the final product from all over the globe, when a project is spread out as far as that there seem to be certain engineering practices that are “locked in” simply because there is no viable alternative.

What do you base this conclusion on?

Hello PayneTrain,

This link isn’t showing on my computer. Could you help me figure out what’s going on or maybe send me it somehow?

Best Regards,
RM

I’m guessing the NASA SE Handbook. But what do I know? I’m just #StirringThePot.

(Sorry, summer CD is boring and need to see some drama)