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