Week 4: Progress?

Today's post will cover 2 parts:

1. Mission Design
2. Ball-Robot Simulation

Part I: I wanna go to space.

Mission design is long. There are countless steps required, and at every step of the way, you have to scrutinize everything you do. Thus, when you are designing a CubeSat, you need to take into consideration every single part of the satellite and expound on why that particular piece was chosen for the mission. Moreover, I learned that there is a silver bullet to writing a good mission design. That is if you have an issue, you can consult "the famous and practical handbook" called Space Mission Analysis and Design. This thing is like a dictionary in size (think thick) and font (think small), but it reads like a handbook. It also has the handy acronym of SMAD, you know, when you get smad.

SMAD, 2nd ed.

So anyways, I tried my hand at a space mission design, which I have scrapped because it wasn't quite in line with what was needed. I also have a handy-dandy PowerPoint presentation that is over 60 slides long that exemplifies what I need to do instead. So, now I will learn how to create a good mission design. Woo-woot! At the end of this, I'll actually have something worth publishing... It will be a great deliverable, and I will soon get over my phobia of writing long-ish papers. Regardless, I am currently looking at C&DH systems, Comms systems, and ADCS systems. From these, I am trying to find the cheapest components with heritage (that means tested by previous space-flights) for these three areas. Window-shopping C&DH is all about finding computers that have a small form factor and radiation hardening. Window-shopping comms systems is all about finding a cheap communication device that do not have an external antenna (because we are mounting the inflatable) and has the capability to operate on the right frequency band. Lastly ADCS is just about finding the cheapest components.

Part II: 90's stuff is so outdated.

I mentioned in my second week that I would be doing something about simulating ball robots. I have continued doing that, and I discovered that creating a virtual world is rather annoying with the outdated Virtual Reality Markup Language (VRML) standard. However, after looking at its sole free successor, X3D, VRML is still nicer to use. I also realized something... Simulating objects might be better done with a game engine that also has a physics engine (simulating physics is hard if you do it from scratch)... Oh well. I have successfully refactored the pre-existing code so that the ball-system can be looped, while changing the center of mass with each step. And I also added a back ground. However, what's annoying about VRML is that it has a weird axis system. Luckily, it is still a right-handed coordinate system, but who makes the y-axis point up? ... The answer? .... People from the 90s. I fortunately found a great cheat-sheet from this one Purdue professor whose website has been moved but links haven't, so he has a bunch of dead webpages... I am a smart cookie, so using super haxxing tricks, I found where his resources were stored in a legal manner. He has some decent VRML tutorials.

Original Simulation:

My Simulation: