Saturday, August 23, 2014

Water Rockets Summer II --- MATTEO V.I --- (part ii)

(If you have not seen yet the previous chapter ...)


Wondering about Matteo V.I?

I will show you ...


And this is its flight ...


It is a pretty nice flight but ... it ends in the sea ... not too good for Arduino ...

Light tech specs:

  • 2.250L coca-cola bottle filled with about 1/3 flat water.
  • About 4 psi @ the moment of launching
  • 3 secs time out for parachute deployment

And now the crash story:

Well, if you have seen the video you will have noticed that Matteo V lands in the sea ...


Lets say that electronics and salt may not be as friends as they would like to,




Post-mortem

I need to analyse the video to really see what happened. When I went to rescue the rocket into the see the parachute was deployed. My guess is that it opened just in the sea but I'm not sure, I've to video edit and video analyse. This will require a whole new blog entry.

It took me about 1 full day of work to assemble everything (sparsed in 1week of holidays). The first thing is that is nice to prototype in paperboard but set the whole structure there and manipulate it once and again is is not a good idea, re-use policarbonate.





  • Bad idea to put the servo in one corner (I expected to let more space to the parachute)
  • Bad idea the duct-tape re-enforcements
  • Bad idea the paper board
  • Bad idea to expect and ideal world of circles and triangles, real world is more complicated, specially if you have an arduino with a lcd keypad which makes kind of thick




  • Bad idea to just hold the battery with duct-tape, the sun can make struggles in duc-tape
  • It was a good idea to use a bridle to hold all the cables.




  • I think a need to set more ballast an obviously put that helpful plastic bag inside the nose in case the parachute does not open!
  • Once again, bad idea the duct tape of the battery.




  • Great idea that kind of switch that I set outside the rocket




  • You can see how thick is the electronics. That's why the world is not perfect and it does not perfectly fit in a perfect round bottle inside a perfect circle witin a perfect triangle. The world is not perfect, thanks God!





  • The servo really does not need to be in the corners.

Friday, August 22, 2014

Water Rockets Summer II --- MATTEO V.I --- (part i)

Intro

What have I been doing this summer?
My favorite hobby, arduino and water rockets. Here it is a taste of what I'm going to tell you:


That's a lot! Many things, many, many.
Last summer (2013) me and my assistant, did a first version of the Matteo Water Rocket, the Matteo 4.0. It was really cool but we're missing a parachute. So we let the parachute for this year project.

By the way, let me introduce you my assistant



We thought that setting up a parachute was an easy task (Wrong!!!) We discovered we it is called rocket science. As long as you enter in this passionate world you will be introducing more a more tech. Digging into the internet I did not see a real mechanical mechanism for the parachute deployment. I was really dissapointed! Really? Should it be that difficult? Well, the only appeling thing that I saw was an electrical programmable lock.

I will be honest, if you want to build the deployment mechanism just follow this web, or do a little web digging.

Let's begin by the electronics. It is really easy, nothing fancy, it is just a timer and when it is done just opens the door holding the parachute.





The hardware side:

Electronics mechanisms for parachute deployment of water rocket using:

  • Arduino 
  • lcd shield (http://www.dx.com/p/2-6-lcd-keypad-shield-for-arduino-green-black-161359)  
  • microservo (http://www.dx.com/p/mg90s-metal-geared-micro-servo-for-plane-helicopter-car-boat-red-orange-black-274655#.U_dqgMWSw4E)
The software side:
  Really easy but if you like, you can find my code here


How it works


At the moment of this video the parachute was not already done but the mechanism. I realized a couple of things, first, 

  • it is no 100% relaible, 
  • the material of the door has to be the same as the bottle itself so when building this kind or rocket you need at least 3 bottles.
  • The ejection plate has to be as close as the opening door but not as to get blocked. 

Once the parachute was done, the load got like this:



Public presentation before launch off


Presentation done by my assistant:


Locked door


Main CPU and flight control


Parachute and nose see atached parachute to the main throttle


The flight (23 Augost 2014 @ 15:00 CET, 38°50′25″N0°06′3)




You can hear someone laughing in the background ... :-)





Thursday, May 22, 2014

Lab 15. Space Invaders. (ii) A finer ADC

I've had to come back to lab 14 (measure of distance) and make sure everything was working correctly.
In fact my ADC was connected wrong (thx lab 14 for your great help!). So once I got the correct ADC I had to update a little bit of code in the game. Now I really have a smooth battleship movement, I'm happy with it.

I've also checked moving the refresh of the LCD in the main loop. Good news, it works. Bad news, it looks flickering, it looks better inside the systick, lets see as long as I keep developing.

As a side effect I implemented a first collision algorithm which needs further development.
As a side effect as well I've seen that the LEDs are not as flashy as they use to be.

Next step. Collisions upgrade.

And now ... the video :-)


Wednesday, May 14, 2014

Lab 15. Space Invaders. (i)

Hi!

I've just done a first crappy version of the game. Just to get to the contest. It is not the final version, it is a "version" but there's still a lot of work dealing with the deployment of the code to get to the contest. I'm sure it will not be in the finals but it will be in the contest :-) (or at least I hope).
Deadline is tomorrow may 15th and I've yet to fix the ADC + the main loop doing the refresh + collisions + smoothing the joystick, vamos, ni de coña, I get to deliver a finer version.

So here it is the release version, in fact a youtube video is one of the requirements so here it is.

Enjoy it!!!


Thursday, May 8, 2014

Lab 15. Space Invaders. Testing module IV (Sounds)

Hi!

I'm just done with my sound test function and guess what ... It works. I'm so happy.



In fact the important thing finally, apart from the DAC, it was "the delay" between the chain of sounds.

My hypothesis: (I've got not taken an scope and maybe my guess is wrong but it makes sense to me) the clock time of the processor is 80Mhz which is way faster to run all my tests (at 11Khz with about 1sec in total of real sound). If you don't put a delay you won't be able to hear anything.

I was having as well a wrong interrupt, another part of my problem.

Finally my working sound_test function looks like this (all the rest equal):

// Testing Tools
void Sound_Test (void)
{
// Predefined sounds
Sound_Killed();
Delay100ms(20);
Sound_Shoot();
Delay100ms(20);
Sound_Explosion();
...

Here you can find the most significant files for the test:



During the Delay100ms I've the time to go through all the sampled sound with no other interruptions apart the one I'm interested.

And that's it, thx again to all of you

Lab 15. Space Invaders. Testing module III (Fire buttons & Joystick)

Hi everyone!
I think I've got already all the pieces to go through the game engine more confident in my hardware.
In fact my very hard problem is that I do not understand one of the pieces of my DAC testing. Going through all the sounds I've just got the very last one, it looks like if my test function is faster than my timer2 handler. No big deal for the game but frustrating as a test sound function.

Anyways, the fire button and leds had not really being a challenge, but integrating my joystick (the ADC) looks like it will be (is it not linear anymore??? weird?!)

By the way, I'm already @ 30K ! I've just got 2K left for the GameEngine (I guess and hope that I've enough ... )

As usual I let you with a proof of concept of this latest test module.

Have a nice day!




Wednesday, April 30, 2014

Lab 15. Space Invaders. Testing module II (DAC)

I'm testing the DAC. I was initially designed the DAC to be a 4bit DAC as it was in lab13 but going a little bit through the code I've seen that the sound resources I've got are 8 bit so I had either to upgrade the DAC from 4 bit to 8bit or downgrade the sound sources from 8bit to either 6 or 4 bits. I've read that 6bits DAC makes a pretty good sound (in the other hand it will take more memory! and I've only 32k!). So I've take the decission to upgrade my DAC to 6bits and downgrade the wave sources from 8bits to 6bits.

Here are my waves:

  • explosion.wav
  • fastinvader1.wav
  • fastinvader2.wav 
  • fastinvader3.wav
  • fastinvader4.wav
  • invaderkilled.wav
  • shoot.wav
  • ufo_highpitch.wav
  • ufo_lowpitch.wav
And here it is the Matlab script to download the wave and covert it, downsample it: (watch out! this converter is for 4bits)

Anyways, my first test of the DAC module is to test that the DAC is correctly implemented, so here I show you the ramp of a 6bit DAC and a closer look of the DAC hardware implementation, that' all for today folks!





Monday, April 28, 2014

Lab 15. Space Invaders. Testing module I (LCD)

Lab 15 is the final project of the edx.org "embedded system shape the world", the target is to build a video game in <= 32Kbytes (fun, isn't it? I've got less memory than my first ZX Spectrum 48K!) so, do not expect to see here the latest graphics, music and game experience.

Let's be honest, it will be far from being a PiPhone but I think that at least I will have the same fun as its creator.

I've got to break down the project in its main modules driving, the lcd, the DAC sounds, the LEDs, the "joystick" and finally the main engine controller.

So today is the first part, the LCD testing module :-) and here it is ...







Monday, April 21, 2014

Lab 14. Measure of distance

Here we go with Lab 14. What about lab 14? Well, the amazing thing of lab 14 is how we can sense the world. The lab was about making an "electronic ruler". Basically it was the symetry of lab 13 instead of generating signal here I was interpreting signals. 

Once the lab was done and graded I had a little problem with the screen!


It was full of noisy pixel everywhere. After checking once and again every single connection, the solution was, guess what ... turn off, turn on the device! And never had this problem again

Once I put the ruler on the variable resistor, once again, guess what!, I had to calibrate! and linear regrese the values to have a lineal ruler (using excel). Now I had the lcd, here it is the setup!


And finally the electronic ruler in action here!



If you're interested in the code, check it out here.




Tuesday, April 8, 2014

Lab 13. Embedded systems shape the world. DAC

Too late to comment more than just "It's done".

Once it was done I had to implement a little op-amp in inverse mode to just hear without the headphone the tones (and hence the "musik!") produced :-)

Nothing else, nothing more, here you have the next top 10 hit! "Mary had a little lamb"


Of course, I can not let you go without the debugging session photos!








The source code if you're interested in to know how all this works, and a last video showing the first working version just out of the owen, you will see that you can hardly hear the tones.












Tuesday, April 1, 2014

Lab 12. Embedded systems shape the world. Interrupts

Well, well, here I let you a little demo of how it looks like for me the implementation of the Lab 12, interrupts.
It is just a little program that uses Systick and in the interrupt service routine just implements a little FMS (it may even be a counter) to just change the status of the push button in relation with the output tone 440Hz (A for tunning). If you click once, the tone is hold, if you click again the tone is off and on and on.

No more texto and just see the pictures and the little video :-)




Tuesday, March 25, 2014

Testing the LCD Nokia 5110 display with the tiva Launchpad

Little video to just test that I've bought the correct hardware and that it is working




Monday, March 24, 2014

Edx Lab 10: Traffic Lights.



Well, well, well. I'm doing this course from Edx, "Embedded Systems Shape the World", which is seriously true. Just think in the traffic lighst of a city (if it was me doing the traffic lights I won't have money enough to pay the insurance companies!)

And that was the purpose of Lab10. You can find my "dishonrable" code in bitbucket: https://agudo@bitbucket.org/agudo/edx_labs.git

Here you can see some pictures and a video (at the end) of the WORKING! hardware (I would like as well to upload a Finite State Machine, or FSM,  diagram but right now the only one I've is in white paper and black pen).





I've not adjusted the timing. I think it would be a good lab to implement a real hardware circuit with KiCAD, just 6 Leds (3 in each plate) a few resistors and 3 push buttons. When I finish all these MOOC where I'm suscribed I will begin to make a first and simple circuit.

Let's the rock begin!



For me the real FSM has around 18 states but to pass the grading with no headache I implemented the 9 states noted in the description of the lab.