Motor gimbal rotation matrices

This gallery contains 3 photos.

Gallery | Leave a comment

Improved rocket data OCR

I gave up on training Tesseract because I couldn’t figure out how to make the open source training tools work, so I downloaded a 45 day trial of the LabVIEW Vision toolkit and had decent success after training the time, velocity, and altitude fonts. The LabVIEW Vision toolkit has a training GUI that’s intuitive and easy to use if you want to train a new language from images. Training the time and velocity font was very effective: for the time font, I trained 112 characters total, with as few as 3 samples for some characters, and the program recognized 100% of the NS11 times and velocities correctly.

The altitude font was more difficult. The kerning of the altitude font led the OCR program to interpret a digit followed by a comma as a single character, with the combined digit-comma character reported as unknown. For example, 177,024 would be identified as 17?024. However, the Vision toolkit “count objects” function (which i think is called blob detection in image processing parlance) would correctly identify each individual character, but it would report them out of order. For example, it would count 7 characters in 177,024 but it would identify them as 0 1 7 7 2 4 ,. Since it reported the detected object region of interest, it was a simple matter to sort them left to right and then run OCR character-by-character.

The final difficulty on the altitude font was “ghost characters”. Because the altitude changes quickly and my image acquisition process is crudely take a screenshot every second, the altitude images have characters that are a combination of one or more digits. No amount of training solved this problem and after much training on the altitude font, I could only identity 94% of the NS11 altitudes correctly (all incorrect altitudes had a ghost character). I think an OCR engine with a more sophisticated neural network (like Tesseract) and font library would handle this problem better. Downloading the video and running OCR on the individual frames is another solution, and would deliver higher resolution data.

Ghost characters (e.g. a “ghost” of a 1 appears behind the 2)

I downloaded the NS10 webcast and repeated the whole process; the OCR routine recognized 100% of timestamps, 99.1% of speeds, and 95.8% of altitudes “correctly”. Correctly means the identified point wasn’t obviously wrong and I didn’t go back manually to check the screenshot and fix it. The velocity errors were due to confusion between 6 and 8, and the altitude errors were all ghost characters.

Here are the corrected NS10 and NS11 data: ns10ns11data
ns10ns11data
Image | Posted on by | Leave a comment

Speed and altitude from New Shepard webcast

The Blue Origin webcast has speed and altitude data vs. time, so I tried to download it and automatically parse the data with Tesseract.

1. Take screenshot of the webcast once per second.
2. Crop the time, altitude, and speed data. This is easy because the text regions stay in the same part of the frame for the entire webcast.
3. Convert the RGB images to black and white. Use the formula 0.30*R+0.59*G+0.11*B = a grayscale value between 0 and 255. Tune the cutoff to get a crisp black and white image, e.g. if the intensity is greater than 190, make the pixels pure black.
4. Save the resulting black and white image as .png.
5. Run Tesseract on each .png and save the Tesseract output to a .txt file.

screenshotflowchat

It works okay (67% altitude correct and 94% velocity correct out 478 points), but struggles with 3 vs. 5 in the altitude font. I’ll try to train Tesseract on each font (altitude uses one and time/speed use another) and see if that works.

blogdata

Posted in Uncategorized | Leave a comment

1DOF sounding rocket

Apropos last weekend’s Exos launch, what does it take to build a reusable VTVL sounding rocket? Start w/ a 1DOF ascent-only simulation w/ a few realisms added:

  • Time-varying mass
  • Altitude-varying engine performance (LOX/ethanol at 350 psi and r = 1.1 from free version of RPA)
  • Altitude-varying atmosphere (from 1976 atmo model)
  • Drag coefficient (V2 copied out of Sutton) function of local Mach number
The 1DOF program needs to integrate these two differential equations:
  1. mdot = Fthrust/Isp(x)/g;
  2. xdotdot = 1/m(t) *(Fthrust – 0.5*rho(x)*Cd(M)*A*xdot^2 – m(t)*g);
For zeta = 0.45, TW= 1.1, and max thrust = 3.6 kN the max altitude is 16785 m (55069 ft). Definitely not the von Karman line, but probably enough of a challenge. A couple of the FAR university rocket challenges are to a similar altitude. I don’t know if a business case for a reusable sounding rocket closes – John Quinn said the sounding rocket stuff is a practice for their orbital program. And Blue Origin flies New Shepard only 3 times year, so probably can’t parlay a suborbital sounding rocket hobby into a business. Zeta = 0.45 is a lousy propellant mass fraction, but I’m pleasantly surprised it makes it past 50,000 feet. 
AltitudeVelocity

Altitude and velocity vs. time

I didn’t find a lot of drag coefficient data – I emailed this guy several times because his CFD software is cheap and looks easy to use, but he never replied. So I took the plot of V2 Cd vs. M and wrote a script that lets me click on the picture to capture a lot of points. The CdFxn() script does a crude nearest neighbor interpolation which is why you see the same drag coefficient for multiple Mach numbers in the plot below. 
CdCapture

Program for getting a lot of Cd vs. M points out of this plot. Click on the curve and the data appears in the table to the left. 

CdOutput

Cd “data” in blue and Cd values used in simulation in black.

Posted in Uncategorized | Leave a comment

DIY Prox Probes

I wanted to see if cheap inductive proximity switches could be reworked to output a voltage proportional to displacement. This is what it looks like on the inside after I ham-handedly snapped off the fragile copper coil (inductor). Some strands of the coil are visible on the right trapped in potting epoxy.

IMG_1231

On the inside they have this PCB connected to the coil and three pigtails that are Vs, GND, and a high/low signal indicating the probe is some distance from a conducting target. The LED lights up when you’re in range of the target.

circuitpics

I tried to reverse engineer it and came up with this circuit (possibly wrong, and I’m not sure where the coil attaches – it’s made of very delicate wire and tore off when I was trying to remove the potting epoxy):circuit

Resistors values are all visible, don’t know what the caps are, all transistors are NPN type. I think it’s probably an oscillator that excites an LC or RLC circuit, but my circuit analysis skills are insufficient to make heads or tails of it now. Eddy-current or inductive proximity probes are a very common vibration sensor in industrial turbomachinery, but are way outside the hobbyist budget. The premise is very simple so I’m curious why they get so expensive.

Posted in Uncategorized | Leave a comment

Reviving a bricked Arduino ProMini

Something anomalous happened to the ProMini on a flight about a month ago, and the ProMini would not run the sketch that was uploaded to it. I tried to reupload the sketch and got the following errors:

avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x40

Thinking somehow the bootloader got corrupted, I tried to reupload the bootloader, but received these errors:

avrdude: Device signature = 0x000000
avrdude: Yikes! Invalid device signature.
Double check connections and try again, or use -F to override
this check.

Now I think some of the fuse bits on the Atmega328 may have been corrupted or changed, so I’m trying to read them using my Uno running the ArduinoISP sketch. I removed the Atmega328 from the ProMini and soldered it to a breakout board (after failing to make my own). I had to translate some of the ArduinoToBreadboard pins from 28-pin DIP to the 32-pin TQFP that the ProMini uses. Here’s what I came up with:

UNO---->328 Breakout 
5V----->Pin 4,6,18 (Power)
GND---->Pin 3,5,21 (Ground)
11 ---->Pin 15 (MOSI)
12 ---->Pin 16 (MISO)
13 ---->Pin 17 (SCK)
10 ---->Pin 29 (Reset)

But when I run the following avrdude command

avrdude -P com3 -b 19200 -c avrisp -p m328p -v

I get what I think is a failure to communicate with the chip. I don’t know enough about avrdude to interpret or troubleshoot this.

avrdude: Device signature = 0x000000
avrdude: Yikes! Invalid device signature. 
         Double check connections and try again, or use -F to override 
         this check.

This is a stream-of-consciousness post. I’ll add and modify as I keep working it.

 

Posted in Uncategorized | Leave a comment

Helicopter upgrades and stupid I2C problem

I replaced the stock 11T pinion with a 12T pinion, and replaced the stock E-Flite 800 mAh LiPos (68 g) with Turnigy Nano-Tech 370 mAh (38 g) batteries. The Turnigy batteries are 30 g lighter, and deliver 7.5 to 8 minutes of (mostly hover) flight. These modifications, in addition to the throttle gain increase described here, make the helicopter very zippy – it lifts off at ~50%. I’m replacing my Sparkfun RedBoard and SD card shield (35 g combined) with an Arduino Pro Mini and MicroSD breakout board (6 g combined). The combined changes should give me sufficient T/W for experiment with sensors on board.

I have several FreeIMUs that I built myself a while ago, but never got farther than running Fabio’s yaw/pitch/roll demonstration. The FreeIMU library is very large, and takes up almost all of the ATmega328 memory, so I’ve been experimenting with communicating with the sensors directly via I2C so I can have a lightweight program to log raw data to an SD card. I’ve discovered that the MPU-6050 is a very complicated little device – its user manual and register map total 98 pages. The HMC5883L compass is much simpler, so I decided I’d start with that sensor. However, I encountered weird behavior where sometimes I could access the compass via I2C, but sometimes I couldn’t. The screenshot below shows the ouput of I2c.scan() – it only identifies the MPU-6050 accelerometer/gyro at 0x68 and the MS5611 barometer at 0x77.

2devices

Fabio has the HMC5883L compass tied to the MPU-6050’s auxiliary SDA/SCL – not the main SDA/SCL – and the MPU-6050 blocks I2C access to devices on its auxiliary bus unless certain bits are set. Fabio’s FreeIMU library sets these so I2C can access the HMC5883L, but they reset when the power cycles. So before running I2c.scan() I set the following registers on the MPU-6050:

I2c.write(ACCGYR_ADDRESS,0x6B,0x00); //Take device out of sleep mode I2c.write(ACCGYR_ADDRESS,0x6A,0x00); //Disable master mode, precondition to enabling I2C bypass                                                                                   I2c.write(ACCGYR_ADDRESS,0x37,0x02); //Enable I2C bypass

And after all that head scratching, I can see all three devices on the I2C bus.

3devices

Lots of reinventing the wheel. Blerg.

 

Posted in Uncategorized | Leave a comment