Sunday, May 24, 2015

Mango Scooter

Ah, the boringness of working at minimum wage at a convenience store while, at the same time, wrapping up my job as a FIRST Robotics team manager! The nice part about it is all the money it brings!

Now, since I have absolutely no self control when it comes to buying making related stuff, especially when stuck with a boring job for a while, I ordered a bunch of stuff off Hobby King. After lurking Charles Guan's blog for years, I knew I wanted to make a silly electric powered vehicle. A kick-scooter looked like the safest (yeah, right) and cheapest way to make an exploratory project about electric vehicles, that is, a project where I start with the main part (in this case, the motor and speed controller) and make it run, instead of starting, as every engineering projects should: with a problem description and a requirement table.

For this purpose, I chose the following ICBM: Turnigy Aerodrive SK-3 6354; which I believe, if I understand right, is a close relative of Charles' Melon Motor. Since it's only a relative, and it's name clearly also has to start with M, I will now christen this motor; the Mango Motor, and as such, Mango Scooter.

Kind of looks like a Mango, right?

This motor has the following specs:

  • kv: 260 RIP'EM (RPM) per volt
  • Max Voltage: 37 Volts
  • Max Power: 2360 W (About 3.16 HP) I doubt it can actually output that much mechanical power, I don't doubt it can eat that electrical power though
  • Max Loading: 70 Amp
  • Internal Resistance: Supposedly 0.023 ohms, I kind of doubt it.

To go with it, I got a "100A" Red brick ESC, why 100A while I only got a 70 amp motor you say? Because:
  1. Safety Factor
  2. It's Cheap Chinese Stuff so it's probably gonna explode as soon as I put current through it.
  3. It's entirely made of MOSFETs (Whatever those are) And (almost) no heat dissipation.
Literally a bick of MOSFETs

...Thinking about it, I should probably have went for 150 or something.

Let's see how fast that could go...suppose a 10cm diameter wheel and direct drive. 10 cm is nice and round.

At 35 Volt, because a 37 volt battery would be at 37 volt only for the first few minutes anyway, the motor spins at 9100 RPM. Thanks to the 10 cm diameter wheel, that's 285 740 cm/min or 171.44 km/hour.

Hey, that's nice! I don't need to go that fast though!...and the motor can't even start if I leave it like that anyway. The red brick controller is a sensor-less controller, as such, it can't know where the motor poles actually are, and which poles needs to be switched. What it means is that the motor just won't work if the inertia it sees is too big, or if the motor is going really slowly. In both cases, we need reduction, so that high speed is actually good.

Here's some interesting reduction cases:

  • a 9x reduction in 2 3x stages reduction gives a nice 19km/h
  • a 12x reduction with a 3x and a 4x stage gives 14.25 km/h
  • 16x reduction with 2 4x stages is 11 km/h
Now, the question is, which is the lowest reduction I can get that will still let the motor start. I will need to test in order to answer this...which will require me to get a bigger iron, because my little 50 watt sparkfun hakko-copy iron just doesn't have the thermal weight to solder those beefy connectors.

Now, obviously I didn't just buy a mango off Hobby king. I always wanted to make a quadcopter, and try my hand at writing the control code for it myself, so, I bought 5 itty bitty motors too! (along with their ESC, obviously)

Here's one of them next to their big brother Mango:

Thinkpad for scale?

So that will be fun. Next week, I will be introducing one more project i've been working on.

Sunday, May 17, 2015

Re-entry simulator - Part 1

Ages ago, I've had to make a launch simulator for a multi-staged rocket. The goal was to find the efficiency of multi-stageg rocket compared to single staged ones. That simulator was pretty simplistic; 1D (altitude only), no easy way to change initial conditions, lift was neglected, and, as it was only 2D, there was no way to change orientation or go into orbit.

Now, for my space sciences class (Phy-2100), I have a homework that requires me to calculate the re-entry window of an Apollo capsule so that astronauts don't feel more than 6,5G. Now, I had 2 ways to do it: either calculate a few values by hand and easilly find the maxima and minimum, or do it the Kerbal way; Trying every possibilities and see which sticks. So I took my old Simulink program, and used that as an excuse to fix the problems with it.

First was making it simpler to change initial conditions. That was pretty straightforward; I simply changed some values to be inputs from the workspace. The initial conditions I added are:
  • Initial speed (Absolute value and angle)
  • Initial weight of propelant
  • Initial altitude

Next was turning my 1D sim in that was an headache. I'm not great at setting up motion equations, so the following took a few textbooks; along with wikipedia, to set up and make sure I understood. Movements, especially relative motion, and in polar coordinates to boot, are a pain.

First was setting up my hypotheses:
  • Coordinates are geocentric.
  • The earth surface is a round shell at mean earth radius inside of which relative speed is forced to 0. That shell rotates at 1 turn per 23 hours and 56 minutes.
The equations of movement for polar coordinates are the following (From Wikipedia, because it's easier to copy paste than trying to do rdotdot in blogger):

 \mathbf{r} = (x, \ y ) = r (\cos \varphi ,\ \sin \varphi) = r \hat{\mathbf{r}}\ ,
 \dot {\mathbf r} = (\dot x, \ \dot y ) = \dot r (\cos \varphi ,\ \sin \varphi) + r \dot \varphi (-\sin \varphi ,\ \cos \varphi) = \dot r \hat {\mathbf r} + r \dot \varphi \hat {\boldsymbol{\varphi}} \ ,
 \ddot {\mathbf r } = (\ddot x, \ \ddot y ) = \ddot r (\cos \varphi ,\ \sin \varphi) + 2\dot r \dot \varphi (-\sin \varphi ,\ \cos \varphi) +  r\ddot \varphi (-\sin \varphi ,\ \cos \varphi) - r {\dot \varphi }^2 (\cos \varphi ,\ \sin \varphi)\ =   \left( \ddot r - r\dot\varphi^2 \right) \hat{\mathbf r} + \left( r\ddot\varphi + 2\dot r \dot\varphi \right) \hat{\boldsymbol{\varphi}} \  = (\ddot r - r\dot\varphi^2)\hat{\mathbf{r}} + \frac{1}{r}\; \frac{d}{dt} \left(r^2\dot\varphi\right) \hat{\boldsymbol{\varphi}}

And as such, our forces equilibrium is the following (Again, from wikipedia):

F_r = m \ddot r -mr \dot {\varphi}^2 \
F_{\varphi} = mr \ddot \varphi +2m \dot r \dot {\varphi} \ .

Now, in order to make my things simpler, I need to isolate the acceleration terms.

Now comes the question: what are my forces? and what information do I need to calculate them?
The forces I've chosen to model are the following:
  • Drag (Dependent on speed, atmospheric conditions, and geometry)
  • Lift (Dependent on the same things as drag)
  • Thrust (Depends on ISP, Chamber pressure, angle and atmospheric conditions)
  • Gravity (Depends on altitude)
Just for the sake of completeness, here are the things I neglected/assumed:
  • The pilot is not Jebediah Kerman
  • For this particular case, Drag and lift are hardcoded, and are only dependent on altitude. They are based on this paper:
  • Trans-sonic effects (Additionnal drag between mach 0.8 and 1.2) are neglected
  • Capsule dynamics (Roll, pitch, yaw and such) are neglected. Capsule is assumed stable at a 25 degrees flight angle.
  • Flow is supposed incompressible below mach 1. Past mach 1, the drag coefficient depends solely on altitude.
  • No control whatsoever (although this could easilly be added later, along with the capsule/rocket yaw pitch and roll)
  • The atmosphere is the standard atmosphere, but it also has a speed, which depends on the altitude. It is 0 at 100km, and the same speed as the earth's shell at sea level. The distribution is assumed linear for now. (Hint: it's not, but that's easier to estimate)
Allright, now that everything is set-up, time to code my life away!

For now I got the orbit part mostly functionning, except for a weird "bug" where my orbit precesses. It shouldn't. I'm guessing it might have to do with rounding errors...time to debug!

EDIT on may 19th: Since it's been less than a day from my previous post, I thought I'd just edit it. I found my bug. Gravity was acting weird, because I had re-used my gravity calculator from my first launch simulator, I had added an "arbitrary" Earth Radius constant. As such, my gravity force was getting lower and lower and lower, due to it adding an earth radius every time! Which explains the precession.

Here's how it looks so far

It works, it's a circle tracer!