Tag Archives: rockets

HackSpace magazine 12: build your first rocket!

Post Syndicated from Andrew Gregory original https://www.raspberrypi.org/blog/hackspace-magazine-12-build-your-first-rocket/

Move over, Elon Musk — there’s a new rocket maverick in town: YOU!


Step inside the UK rocketry scene, build and launch a rocket, design your own one, and discover the open-source rocket programmes around the world! In issue 12, we go behind the scenes at a top-secret launch site in the English Midlands to have a go at our own rocket launch, find the most welcoming bunch of people we’ve ever met, and learn about centre of gravity, centre of pressure, acceleration, thrust, and a load of other terms that make us feel like NASA scientists.

Meet the Maker: Josef Prusa

In makerception news, we meet the maker who makes makers, Josef Prusa, aka Mr 3D Printing, and we find out what’s next for his open-source hardware empire.

Open Science Hardware

There are more than seven billion people on the planet, and 90-odd percent of them are locked out of the pursuit of science. Fishing, climate change, agriculture: it all needs data, and we’re just not collecting as much as we should. Global Open Science Hardware is working to change that by using open, shared tech — read all about it in issue 12!

And there’s more…

As always, the new issue is packed with projects: make a way-home machine to let your family know exactly when you’ll walk through the front door; build an Alexa-powered wheel of fortune to remove the burden of making your own decisions; and pay homage to Indiana Jones and the chilled monkey brains in Temple of Doom with a capacitive touch haunted monkey skull (no monkeys were harmed in the making of this issue). All that, plus steampunk lighting, LEDs, drills, the world’s biggest selfie machine, and more, just for you. So go forth and make something!

Get your copy of HackSpace magazine

If you like the sound of this month’s content, you can find HackSpace magazine in WHSmith, Tesco, Sainsbury’s, and independent newsagents in the UK from tomorrow. If you live in the US, check out your local Barnes & Noble, Fry’s, or Micro Center next week. We’re also shipping to stores in Australia, Hong Kong, Canada, Singapore, Belgium, and Brazil, so be sure to ask your local newsagent whether they’ll be getting HackSpace magazine. And if you’d rather try before you buy, you can always download the free PDF now.

Subscribe now

Subscribe now” may not be subtle as a marketing message, but we really think you should. You’ll get the magazine early, plus a lovely physical paper copy, which has a really good battery life.

Oh, and twelve-month print subscribers get an Adafruit Circuit Playground Express loaded with inputs and sensors and ready for your next project. Tempted?

The post HackSpace magazine 12: build your first rocket! appeared first on Raspberry Pi.

New – Amazon EC2 Elastic GPUs for Windows

Post Syndicated from Randall Hunt original https://aws.amazon.com/blogs/aws/new-ec2-elastic-gpus-for-windows/

Today we’re excited to announce the general availability of Amazon EC2 Elastic GPUs for Windows. An Elastic GPU is a GPU resource that you can attach to your Amazon Elastic Compute Cloud (EC2) instance to accelerate the graphics performance of your applications. Elastic GPUs come in medium (1GB), large (2GB), xlarge (4GB), and 2xlarge (8GB) sizes and are lower cost alternatives to using GPU instance types like G3 or G2 (for OpenGL 3.3 applications). You can use Elastic GPUs with many instance types allowing you the flexibility to choose the right compute, memory, and storage balance for your application. Today you can provision elastic GPUs in us-east-1 and us-east-2.

Elastic GPUs start at just $0.05 per hour for an eg1.medium. A nickel an hour. If we attach that Elastic GPU to a t2.medium ($0.065/hour) we pay a total of less than 12 cents per hour for an instance with a GPU. Previously, the cheapest graphical workstation (G2/3 class) cost 76 cents per hour. That’s over an 80% reduction in the price for running certain graphical workloads.

When should I use Elastic GPUs?

Elastic GPUs are best suited for applications that require a small or intermittent amount of additional GPU power for graphics acceleration and support OpenGL. Elastic GPUs support up to and including the OpenGL 3.3 API standards with expanded API support coming soon.

Elastic GPUs are not part of the hardware of your instance. Instead they’re attached through an elastic GPU network interface in your subnet which is created when you launch an instance with an Elastic GPU. The image below shows how Elastic GPUs are attached.

Since Elastic GPUs are network attached it’s important to provision an instance with adequate network bandwidth to support your application. It’s also important to make sure your instance security group allows traffic on port 2007.

Any application that can use the OpenGL APIs can take advantage of Elastic GPUs so Blender, Google Earth, SIEMENS SolidEdge, and more could all run with Elastic GPUs. Even Kerbal Space Program!

Ok, now that we know when to use Elastic GPUs and how they work, let’s launch an instance and use one.

Using Elastic GPUs

First, we’ll navigate to the EC2 console and click Launch Instance. Next we’ll select a Windows AMI like: “Microsoft Windows Server 2016 Base”. Then we’ll select an instance type. Then we’ll make sure we select the “Elastic GPU” section and allocate an eg1.medium (1GB) Elastic GPU.

We’ll also include some userdata in the advanced details section. We’ll write a quick PowerShell script to download and install our Elastic GPU software.

Start-Transcript -Path "C:\egpu_install.log" -Append
(new-object net.webclient).DownloadFile('http://ec2-elasticgpus.s3-website-us-east-1.amazonaws.com/latest', 'C:\egpu.msi')
Start-Process "msiexec.exe" -Wait -ArgumentList "/i C:\egpu.msi /qn /L*v C:\egpu_msi_install.log"
[Environment]::SetEnvironmentVariable("Path", $env:Path + ";C:\Program Files\Amazon\EC2ElasticGPUs\manager\", [EnvironmentVariableTarget]::Machine)
Restart-Computer -Force

This software sends all OpenGL API calls to the attached Elastic GPU.

Next, we’ll double check to make sure my security group has TCP port 2007 exposed to my VPC so my Elastic GPU can connect to my instance. Finally, we’ll click launch and wait for my instance and Elastic GPU to provision. The best way to do this is to create a separate SG that you can attach to the instance.

You can see an animation of the launch procedure below.

Alternatively we could have launched on the AWS CLI with a quick call like this:

$aws ec2 run-instances --elastic-gpu-specification Type=eg1.2xlarge \
--image-id ami-1a2b3c4d \
--subnet subnet-11223344 \
--instance-type r4.large \
--security-groups "default" "elasticgpu-sg"

then we could have followed the Elastic GPU software installation instructions here.

We can now see our Elastic GPU is humming along and attached by checking out the Elastic GPU status in the taskbar.

We welcome any feedback on the service and you can click on the Feedback link in the bottom left corner of the GPU Status Box to let us know about your experience with Elastic GPUs.

Elastic GPU Demonstration

Ok, so we have our instance provisioned and our Elastic GPU attached. My teammates here at AWS wanted me to talk about the amazingly wonderful 3D applications you can run, but when I learned about Elastic GPUs the first thing that came to mind was Kerbal Space Program (KSP), so I’m going to run a quick test with that. After all, if you can’t launch Jebediah Kerman into space then what was the point of all of that software? I’ve downloaded KSP and added the launch parameter of -force-opengl to make sure we’re using OpenGL to do our rendering. Below you can see my poor attempt at building a spaceship – I used to build better ones. It looks pretty smooth considering we’re going over a network with a lossy remote desktop protocol.

I’d show a picture of the rocket launch but I didn’t even make it off the ground before I experienced a rapid unscheduled disassembly of the rocket. Back to the drawing board for me.

In the mean time I can check my Amazon CloudWatch metrics and see how much GPU memory I used during my brief game.

Partners, Pricing, and Documentation

To continue to build out great experiences for our customers, our 3D software partners like ANSYS and Siemens are looking to take advantage of the OpenGL APIs on Elastic GPUs, and are currently certifying Elastic GPUs for their software. You can learn more about our partnerships here.

You can find information on Elastic GPU pricing here. You can find additional documentation here.

Now, if you’ll excuse me I have some virtual rockets to build.


European Astro Pi Challenge winners

Post Syndicated from David Honess original https://www.raspberrypi.org/blog/european-astro-pi-winners/

In October last year, with the European Space Agency and CNES, we launched the first ever European Astro Pi challenge. We asked students from all across Europe to write code for the flight of French ESA astronaut Thomas Pesquet to the International Space Station (ISS) as part of the Proxima mission. Today, we are very excited to announce the winners! First of all, though, we have a very special message from Thomas Pesquet himself, which comes all the way from space…

Thomas Pesquet congratulates Astro Pi participants from space

French ESA astronaut Thomas Pesquet floats in to thank all participants in the European Astro Pi challenge. In October last year, together with the European Space Agency, we launched the first ever European Astro Pi challenge for the flight of French ESA astronaut Thomas Pesquet to the International Space Station (ISS) as part of mission Proxima.

Thomas also recorded a video in French: you can click here to see it and to enjoy some more of his excellent microgravity acrobatics.

A bit of background

This year’s competition expands on our previous work with British ESA astronaut Tim Peake, in which, together with the UK Space Agency and ESA, we invited UK students to design software experiments to run on board the ISS.

Astro Pi Vis (AKA Ed) on board the ISS. Image from ESA.

In 2015, we built two space-hardened Raspberry Pi units, or Astro Pis, to act as the platform on which to run the students’ code. Affectionately nicknamed Ed and Izzy, the units were launched into space on an Atlas V rocket, arriving at the ISS a few days before Tim Peake. He had a great time running all of the programs, and the data collected was transmitted back to Earth so that the winners could analyse their results and share them with the public.

The European challenge provides the opportunity to design code to be run in space to school students from every ESA member country. To support the participants, we worked with ESA and CPC to design, manufacture, and distribute several hundred free Astro Pi activity kits to the teams who registered. Further support for teachers was provided in the form of three live webinars, a demonstration video, and numerous free educational resources.

Image of Astro Pi kit box

The Astro Pi activity kit used by participants in the European challenge.

The challenge

Thomas Pesquet assigned two missions to the teams:

  • A primary mission, for which teams needed to write code to detect when the crew are working in the Columbus module near the Astro Pi units.
  • A secondary mission, for which teams needed to come up with their own scientific investigation and write the code to execute it.

The deadline for code submissions was 28 February 2017, with the judging taking place the following week. We can now reveal which schools will have the privilege of having their code uploaded to the ISS and run in space.

The proud winners!

Everyone produced great work and the judges found it really tough to narrow the entries down. In addition to the winning submissions, there were a number of teams who had put a great deal of work into their projects, and whose entries have been awarded ‘Highly Commended’ status. These teams will also have their code run on the ISS.

We would like to say a big thank you to everyone who participated. Massive congratulations are due to the winners! We will upload your code digitally using the space-to-ground link over the next few weeks. Your code will be executed, and any files created will be downloaded from space and returned to you via email for analysis.

In no particular order, the winners are:


  • Winners
    • @stroteam, Institut de Genech, Hauts-de-France
    • Wierzbinski, École à la maison, Occitanie
    • Les Marsilyens, École J. M. Marsily, PACA
    • MauriacSpaceCoders, Lycée François Mauriac, Nouvelle-Aquitaine
    • Ici-bas, École de Saint-André d’Embrun, PACA
    • Les Astrollinaires, Lycée général et technologique Guillaume Apollinaire, PACA
  • Highly Commended
    • ALTAÏR, Lycée Albert Claveille, Nouvelle Aquitaine
    • GalaXess Reloaded, Lycée Saint-Cricq, Nouvelle Aquitaine
    • Les CM de Neffiès, École Louis Authie, Occitanie
    • Équipe Sciences, Collège Léonce Bourliaguet, Nouvelle Aquitaine
    • Maurois ICN, Lycée André Maurois, Normandie
    • Space Project SP4, Lycée Saint-Paul IV, Île de la Réunion
    • 4eme2 Gymnase Jean Sturm, Gymnase Jean Sturm, Grand Est
    • Astro Pascal dans les étoiles, École Pascal, Île-de-France
    • les-4mis, EREA Alexandre Vialatte, Auvergne-Rhône-Alpes
    • Space Cavenne Oddity, École Cavenne, Auvergne-Rhône-Alpes
    • Luanda for Space, Lycée Français de Luanda, Angola
      (Note: this is a French international school and the team members have French nationality/citizenship)
    • François Detrille, Lycée Langevin-Wallon, Île-de-France


  • Winners
    • Delta, TALOS ed-UTH-robotix, Magnesia
    • Weightless Mass, Intercultural Junior High School of Evosmos, Macedonia
    • 49th Astro Pi Teamwork, 49th Elementary School of Patras, Achaia
    • Astro Travellers, 12th Primary School of Petroupolis, Attiki
    • GKGF-1, Gymnasium of Kanithos, Sterea Ellada
  • Highly Commended
    • AstroShot, Lixouri High School, Kefalonia
    • Salamina Rockets Pi, 1st Senior High School of Salamina, Attiki
    • The four Astro-fans, 6th Gymnasio of Veria, Macedonia
    • Samians, 2nd Gymnasio Samou, North Eastern Aegean

United Kingdom

  • Winners
    • Madeley Ad Astra, Madeley Academy, Shropshire
    • Team Dexterity, Dyffryn Taf School, Carmarthenshire
    • The Kepler Kids, St Nicolas C of E Junior School, Berkshire
    • Catterline Pi Bugs, Catterline Primary, Aberdeenshire
    • smileyPi, Westminster School, London
  • Highly Commended
    • South London Raspberry Jam, South London Raspberry Jam, London


  • Winners
    • Garibaldini, Istituto Comprensivo Rapisardi-Garibaldi, Sicilia
    • Buzz, IIS Verona-Trento, Sicilia
    • Water warmers, Liceo Scientifico Galileo Galilei, Abruzzo
    • Juvara/Einaudi Siracusa, IIS L. Einaudi, Sicilia
    • AstroTeam, IIS Arimondi-Eula, Piemonte


  • Winners
    • Birnam, Zespół Szkoły i Gimnazjum im. W. Orkana w Niedźwiedziu, Malopolska
    • TechnoZONE, Zespół Szkół nr 2 im. Eugeniusza Kwiatkowskiego, Podkarpacie
    • DeltaV, Gimnazjum nr 49, Województwo śląskie
    • The Safety Crew, MZS Gimnazjum nr 1, Województwo śląskie
    • Warriors, Zespół Szkół Miejskich nr 3 w Jaśle, Podkarpackie
  • Highly Commended
    • The Young Cuiavian Astronomers, Gimnazjum im. Stefana Kardynała Wyszyńskiego w Piotrkowie Kujawskim, Kujawsko-pomorskie
    • AstroLeszczynPi, I Liceum Ogolnokształcace w Jasle im. Krola Stanislawa Leszczynskiego, Podkarpackie


  • Winners
    • Sampaionautas, Escola Secundária de Sampaio, Setúbal
    • Labutes Pi, Escola Secundária D. João II, Setúbal
    • AgroSpace Makers, EB 2/3 D. Afonso Henriques, Cávado
    • Zero Gravity, EB 2/3 D. Afonso Henriques, Cávado
    • Lua, Agrupamento de Escolas José Belchior Viegas, Algarve


  • Winners
    • AstroVianu, Tudor Vianu National High School of Computer Science, Bucharest
    • MiBus Researchers, Mihai Busuioc High School, Iași
    • Cosmos Dreams, Nicolae Balcescu High School, Cluj
    • Carmen Sylva Astro Pi, Liceul Teoretic Carmen Sylva Eforie, Constanța
    • Stargazers, Tudor Vianu National High School of Computer Science, Bucharest


  • Winners
    • Papaya, IES Sopela, Vizcaya
    • Salesianos-Ubeda, Salesianos Santo Domingo Savio, Andalusia
    • Valdespartans, IES Valdespartera, Aragón
    • Ins Terrassa, Institut Terrassa, Cataluña


  • Winner
    • Moonty1, Mayfield Community School, Cork


  • Winner
    • BSC Behringersdorf Space Center, Labenwolf-Gymnasium, Bayern


  • Winner
    • Skedsmo Kodeklubb, Kjeller Skole, Akershus


  • Winner
    • UltimaSpace, Mihaly Tancsics Grammar School of Kaposvár, Somogy


  • Winner
    • Lambda Voyager, Stedelijke Humaniora Dilsen, Limburg


Why aren’t all 22 ESA member states listed?

  • Because some countries did not have teams participating in the challenge.

Why do some countries have fewer than five teams?

  • Either because those countries had fewer than five teams qualifying for space flight, or because they had fewer than five teams participating in the challenge.

How will I get my results back from space?

  • After your code has run on the ISS, we will download any files you created and they will be emailed to your teacher.

The post European Astro Pi Challenge winners appeared first on Raspberry Pi.

Some moon math

Post Syndicated from Robert Graham original http://blog.erratasec.com/2017/02/some-moon-math.html

So “Brianna Wu” (famous for gamergate) is trending, and because I love punishment, I clicked on it to see why. Apparently she tweeted that Elon Musk’s plan to go to the moon is bad, because once there he can drop rocks on the Earth with the power of 100s of nuclear bombs. People are mocking her for the stupidity of this.

But the math checks out.

First of all, she probably got the idea from Heinlein’s book The Moon is a Harsh Mistress where the rebel moon colonists do just that. I doubt she did her own math, and relied upon Heinlein to do it for her. But let’s do the math ourselves.

Let’s say that we want to stand at the height of the moon and drop a rock. How big a rock do we need to equal the energy of an atomic bomb? To make things simple, let’s assume the size of bombs we want is that of the one dropped on Hiroshima.

As we know from high school physics, the energy of a dropped object (ignoring air) is:

energy = 0.5 * mass * velocity * velocity

Solving for mass (the size of the rock), the equation is:

mass = 2 * energy/(velocity * velocity)

We choose “energy” as that of an atomic bomb, but what is “velocity” in this equation, the speed of something dropped from the height of the moon?

The answer is something close to the escape velocity, which is defined as the speed of something dropped infinitely far away from the Earth. The moon isn’t infinitely far away (only 250,000 miles away), but it’s close.

How close? Well, let’s use the formula for escape velocity from Wikipedia [*]:

where G is the “gravitational constant”, M is the “mass of Earth”, and r is the radius. Plugging in “radius of earth” and we get an escape velocity from the surface of the Earth of 11.18 km/s, which matches what Google tells us. Plugging in the radius of the moon’s orbit, we get 1.44 km/s [*]. Thus, we get the following as the speed of an object dropped from the height of the moon to the surface of the earth, barring air resistance [*]:

9.74 km/s

Plugging these numbers in gets the following result:

So the answer for the mass of the rock, dropped from the moon, to equal a Hiroshima blast, is 1.3 billion grams, or 1.3 million kilograms, or 1.3 thousand metric tons.

Well, that’s a fine number and all, but what does that equal? Is that the size of Rhode Island? or just a big truck?

The answer is: nearly the same mass as the Space Shuttle during launch (2.03 million kilograms [*]). Or, a rock about 24 feet on a side.

That’s big rock, but not so big that it’s impractical, especially since things weigh 1/6th as on Earth. In Heinlein’s books, instead of shooting rocks via rockets, it shot them into space using a railgun, magnetic rings. Since the moon doesn’t have an atmosphere, you don’t need to shoot things straight up. Instead, you can accelerate them horizontally across the moon’s surface, to an escape velocity of 5,000 mph (escape velocity from moon’s surface). As the moon’s surface curves away, they’ll head out into space (or toward Earth)

Thus, Elon Musk would need to:

  • go the moon
  • setup a colony, underground
  • mine iron ore
  • build a magnetic launch gun
  • build fields full of solar panels for energy
  • mine some rock
  • cover it in iron (for magnet gun to hold onto)
  • bomb earth

At that point, he could drop hundreds of “nukes” on top of us. I, for one, would welcome our Lunar overlords. Free Luna!

Update: I’ve made a number of short cuts, but I don’t think they’ll affect the math much.

We don’t need escape velocity for the moon as a whole, just enough to reach the point where Earth’s gravity takes over. On the other hand, we need to kill the speed of the Moons’s orbit (2,000 miles per hour) in order to get down to Earth, or we just end up orbiting the Earth. I just assume the two roughly cancel each other out and ignore it.

I also ignore the atmosphere. Meteors from outer space hitting the earth of this size tend to disintegrate or blow up before reaching the surface. The Chelyabinsk meteor, the one in all those dashcam videos from 2013, was roughly 5 times the size of our moon rocks, and blew up in the atmosphere, high above the surface, with about 5 times the energy of a Hiroshima bomb. Presumably, we want our moon rocks to reach the surface, so they’ll need some protection. Probably make them longer and thinner, and put an ablative heat shield up from, and wrap them in something strong like iron.

I don’t know how much this will slow down the rock. Presumably, if coming straight down, it won’t slow down by much, but if coming in at a steep angle (as meteors do), then it could slow down quite a lot.

Update: First version of this post used “height of moon”, which Wolfram Alfa interpreted as “diameter of moon”. This error was found by . The current version of this post changes this to the correct value “radius of moon’s orbit”.

Update: I made a stupid error about Earth’s gravitational strength at the height of the Moon’s orbit. I’ve changed the equations to fix this.

Maker Faire New York 2016

Post Syndicated from Lorna Lynch original https://www.raspberrypi.org/blog/maker-faire-new-york-2016/

It’s been five years since we made our first appearance at Maker Faire New York. Back in 2011, we were still showing demonstrations of the Raspberry Pi, prior to its release the following spring. This year, we had prominent billing alongside the robots and rockets!

Robots, rockets, and Raspberry Pi!

Robots, rockets, and Raspberry Pi!

Maker Faire New York ran from 1-2 October, and was as great an experience as ever. We brought a bunch of Raspberry Pis showcasing our brand-new Pixel desktop environment. Greg Annandale’s gorgeous photo of the Brooklyn Bridge was a stunning backdrop to the Sense HAT activities we had organised.

Lorna Lynch on Twitter

Doing some pixel art with @Raspberry_Pi at #MFNY16 #MakerFaire #MakerFaireNYC

Joining the stalwart US Pi team of Matt and Courtney were Carrie Anne, Sam, and Lorna, as well as Raspberry Pi Certified Educator Kerry Bruce, who came all the way from Albuquerque, New Mexico. A community college instructor with a passion for STEM education, Kerry was a real trouper and a valuable addition to the team.

When we arrived at Corona Park to get set up, we were concerned about the inclement weather. Given that the Faire is outside, the prospect of running our Pi activities in an open-sided marquee was somewhat daunting.

The team tried hard not to let the rain dampen their ardour for STEM...

The team tried hard not to let the rain dampen their ardour for science…

We braved the elements to take a photo in front of the famous Unisphere, to explore the park a bit, and to geek out over the history of the place. I can’t have been the only one who was excited to see the towers on the New York State Pavilion in real life, after multiple viewings of Men in Black.

Carrie Anne Philbin on Twitter

Team @Raspberry_Pi for #MakerFaire NY 2016! Come visit us and tell us about your makes!

Fortunately, the weather improved for the Faire; we didn’t have to remove electrical equipment from puddles! Resident design genius Sam decorated our tables with Pi-themed cartoons, including one answering this common question: how do you connect a Raspberry Pi to a computer?

Raspberry Pi on Twitter

Here’s what happens when @samalderhyde shows up at your event! #MakerFaire #wmfny16 @makerfaire

We loved pointing to Sam’s cheery Pi character when explaining that the tiny board was the computer. It was great to see people’s surprise at the Pi’s power.

Matt and Carrie Anne both gave speeches: Carrie Anne’s presentation, “Digital Making: Encouraging Creativity in the Classroom and Integrating STEAM Project-Based Learning”, was part of the Make: Education series, while Matt explained how to get started with the Raspberry Pi on the Show and Tell stage. 

Raspberry Pi on Twitter

Go see @MattRichardson at @makerfaire’s Show & Tell Stage at 11:30 (in 10 min). He’s giving a intro to Raspberry Pi.

We heard great reports from the attendees, and we saw a lot of visitors to the stand who had been enthused by what they heard. 

As in previous years, there were many excellent Raspberry Pi-based projects, as well as familiar faces from the Pi community. There was an excellent display of Pi-controlled Lego Mindstorms robots. We also met the guys from Pi Supply showcasing their new JustBoom equipment, bringing affordable high-quality audio to Raspberry Pi users. Eager experimenters of all ages came to try out our Sense HAT activities, and to tell us about the Pi projects they had made at home. One man was even wearing a Pi Zero as a necklace! Other visitors included Steven Welch, who updated us on the work his team are doing with Pis at CERN (we’ve blogged about this), and Henry Feldman of the Beth Israel Deaconess Medical Center, who is using the Raspberry Pi and Camera Module for edge detection in laparoscopic surgery.

We also found a number of excellent projects with more artistic applications. Joe Herman had uncovered a cache of old 8mm and 16mm family movies, and was digitising them and projecting them via a modified vintage movie projector equipped with a Raspberry Pi and Camera Module. You can find out more on Joe’s GitHub.

Joe Herman's Pi-powered projector. Image from Maker Faire.

Joe Herman’s Pi-powered projector. Image from Maker Faire.

Joe’s project wasn’t the only great Pi art project. Following on from Sam Blanchard’s amazing SeeMore, one of the main showpieces of last year’s Faire, we were incredibly excited to see another Pi-powered art piece in pride of place this year. The first thing to greet attendees visiting the Faire in the New York Hall of Science was the Pi-powered Sisyphus kinetic art table. We think it’s so amazing, we’ll be devoting a whole post to it, so keep an eye out!

For several of us, it was our first visit to the Faire and to New York, which really added to our excitement. One of the greatest things was meeting so many happy Pi fans, and introducing newcomers to the fun you can have with one. We lost count of the excellent animations we saw kids (and adults) create on the Sense HAT, and the joyful exclamations as another person got their first piece of Python code working; this is one of the most rewarding parts of our work. We can’t wait for the next Maker Faire! If you couldn’t attend, be sure to check out our tour video here:

Live from World Maker Faire New York 2016

Let Carrie Anne and Matt take you on a tour of World Maker Faire 2016. Join them as they explore the faire, introduce the Raspberry Pi stand, PIXEL and Sam’s artwork, and chat to the teams from Ready Set STEM and Pi Supply.


The post Maker Faire New York 2016 appeared first on Raspberry Pi.

Doom scale

Post Syndicated from Eevee original https://eev.ee/blog/2016/10/10/doom-scale/

I’ve been dipping my toes into Doom mapping again recently. Obviously I’ve done it successfully once before, but I’m having trouble doing it a second time.

I have three major problems: drawing everything too small, drawing everything too rectangular, and completely blanking on what to do next. Those last two are a bit tricky, but struggling with scale? That sounds like a problem I can easily solve with charts and diagrams and math.

Some fundamental metrics

Doom’s mapping rules and built-in textures offer a few fixed reference points.

The z planes — floor and ceiling — are a 64×64 grid anchored at the origin. All “flat” textures are aligned to this grid. (ZDoom lets you rotate, scale, and offset flats, but in vanilla Doom, you sometimes have to design architecture around texture alignment.)

All actors (objects) are square and axis-aligned. Doomguy is 32×56. However, it’s very difficult for an actor to move down a corridor of the same width, and the axis-alignment means a 32-unit square couldn’t fit down a 32-unit diagonal hallway. (It’s rare to see a hallway narrower than 64 or a room height shorter than 64.)

The viewport is 41 pixels above the ground. Doomguy’s maximum step height is 24, which is actually fairly large, almost half his height. Doomguy can balance on a ledge of any width.

The vast majority of Doom’s wall textures are 64×128. A few larger textures are 128×128, and a handful of very large outdoor textures are 256×128. A few “strut” textures and door borders are 8 or 16 wide. Some interesting exceptions:

  • DOOR3, the door you appear to have entered from in many Doom maps, is 64×72. So is DOOR1. EXITDOOR has some extra stuff on it, but the actual door part is also 64×72.
  • BIGDOOR1, the silver door with the UAC logo on it, is 128×96.
  • MIDBARS3 is a railing texture that’s 64×72.
  • The Icon of Sin is built out of a 3×3 grid of textures. The full image is 768×384.
  • EXITSIGN is 64×16, though only half of it is the actual part that says “EXIT”; the rest is the sides of the sign.
  • The STEP textures are all 16 high.

Since Doom’s textures tend to be 128 tall, we can conclude that a standard room tends to be no more than 128 tall. Any more and the texture would start to tile, which works poorly with a lot of textures.

The problem

Vertical distance is fine. Doom doesn’t have a lot of vertical movement, so vertical distances tend not to get too outlandish in the first place.

The trouble is that I don’t know how big spaces are. I draw rooms and they turn out, much later, to be far too cramped. I draw buildings and outdoor areas and they turn out to not really have enough space to fit everything I want.

An obvious approach is to find a conversion between Doom units and real-world units, then judge distances based on real-world units. That sounds great, but I don’t have a good sense of real-world units, either. How big is the room I’m in now? Somewhere between ten and a hundred feet, I guess? Thirty? How much is thirty feet, is that a lot?

How long is my car, say? I guess two of me could lie down end-to-end beside it, so that’s twelve feet? That sounds like I’m underestimating. Fifteen? Are these reasonable guesses? I don’t know.

Hm, well. The answer turns out to be exactly halfway between at thirteen and a half feet, so I don’t know what we’ve learned here exactly.

Okay, so let’s consider in terms of architecture. How long is the quiet residential street in front of my house? I have no idea. The next biggest thing is a house, and I don’t know how wide a house is, or how many houses there are on this street. I could estimate the street in terms of house lengths, and estimate a house in terms of car lengths, and estimate a car length in terms of my height, but that’s enough wild guesses that the final answer could be a whole order of magnitude off.

I never have any reason to appreciate or internalize length measurements, especially moderately large ones. I have no reference point.

Also, Doom’s grid and texture sizes mean that everything is done in multiples of powers of two. I know the powers of two, but I don’t actually know every single multiple of 64 up to 32768, so I occasionally run into the problem that the numbers lose all meaning. How many 64s are in 768, again…?

Also, Doom doesn’t make any sense

The other problem with relating to real-world sizes is that it assumes there’s a way to convert between Doom and the real world. Alas, the universe of Doom has much more in common with the exaggerated and cartoony scale of platformers than with the hyper-realism in modern shooters.

Consider Doomguy. Here’s his default forward-facing sprite, PLAYA1. The pink area is his 32×56 collision box, the red dot is where he fires from, and the yellow dot is the location of the viewport.

Doomguy and some of his measurements

The collision box is the same height as the sprite itself, but it gets shifted upwards slightly because of the sprite offsets. (Every sprite has an offset indicating where its bottom center is, since that’s where the game tracks an object’s position. If Doomguy’s sprite were just drawn from the bottom, he’d look like he were standing on his tiptoes.)

It is generally accepted — by which I mean “Doom Wiki says so” — that 32 units of height correspond to one meter (39”), which makes Doomguy about 5 feet 8 inches tall. It also makes him one meter wide, which seems rather extreme. The usual handwave is to say that vertical and horizontal scales are different (because pixels weren’t square in the original game), so 32 units of width correspond to ¾ of a meter (just shy of 30”).

That doesn’t really make sense to me. If the architecture were truly distorted to compensate for the pixel size, then surely wall textures would be, too. They aren’t. Switches are perfect 32×32 squares. Several floor textures also exist separately as wall textures, and they weren’t distorted in any way. This is a cute explanation that neatly ties together several bits of Doom trivia, but I don’t think it was a deliberate design decision.

Plus, according to this sprite, Doomguy’s collision box is significantly wider than his actual appearance. I don’t know why this is — perhaps the extra space is where he keeps his hundred rockets and half a dozen spare weapons. If we’re interested in aesthetics, surely we should be going by Doomguy’s sprite rather than his in-game dimensions.

More importantly… this weird ratio still doesn’t jive with most architecture. Consider the fast skinny doors introduced in Doom II, which are 64×128. At 32u = 1m, those are two meters wide and four meters tall, or 78” × 157”. The Internet tells me that an interior residential doorway is around 32” × 80” (2:5), and a human being is around 18” × 69” (~1:4).

Here are those measurements alongside the supposed sizes of Doomguy and a skinny door. Something seems slightly off.

An illustration of how even Doom's smaller doors are twice the size they should be

The light blue boxes are the collision boxes; the dark blue boxes are Doomguy’s apparent visible size. I’m using his waist rather than his shoulders, because most people’s (or at least, my) shoulders are not too much wider than their hips — however Doomguy is a beefcake carved out of pure muscle and doors would not be designed for him.

It seems as though all the architecture in Doom is about twice the size it should be, for whatever reason. Look what happens if I shrink the door, but not Doomguy:

The same illustration as above, but with the door scaled down by half

If I use some ZDoom shenanigans to shrink a door within the game, it looks rather more like a real door. (You’d have a hard time fitting through it without modifying the player’s radius, though.)

A 32×64 door in Doom

It’s not just architecture! Keycard sprites are 14×16, which would be about a foot and a half square. The shotgun is 63 pixels long, a whopping 77”. A shotgun shell is 7 pixels long, almost 9”. The candelabra is 61 pixels tall — taller than Doomguy! — which is just over six feet. This is ridiculous. Halving all of these lengths makes them closer to something reasonable.

It appears, for whatever reason, that the world of Doom is roughly twice the size of the world we’re used to. (Or perhaps Doomguy has been shrunk by half.) That matches my attempts at replicating real-world places to scale — they turned out unusually cramped.

64 units equal 1 meter, then. Problem solved.

Ah, well, about that. The 64×128 doors make sense, but… real doorways don’t span the full height of a room, yet many Doom rooms are 128 tall. Or less. The starting area in E1M1, the hallway in MAP01, and the DOOR1 entrance” door are all 72 units tall, which converts to less than four feet.

Let’s try something else. Tom Hall says in the Doom Bible that the 128-unit walls in Wolfenstein 3D were eight feet thick, i.e. 16 units equal 1 foot. The 64-unit grid is thus four feet, which seems reasonable. The maximum step height would be 18 inches, and shallow steps would be 6 inches, which also seem reasonable — the stairs in my house are 7” tall, and the most I can comfortably step up is 3 at a time.

But this still makes those 72-unit rooms be only four and a half feet tall.

This isn’t a problem that can be solved with different height and width scaling, because we’ve come down to a conflict between door/room height and step height. If those 72-unit rooms are a more reasonable eight feet tall (the standard) then 9 units are 1 foot, and Doomguy’s step height is over two and a half feet. Also, those 64×128 doors are over nine feet tall.

The fact is, Doomguy has goofy proportions, and the environment was designed around them. The textures have a gritty semi-realistic aesthetic, but comparing the levels to real-world architecture makes about as much sense as designing Mario levels around real places. Actual humans cannot jump several times their own height, so the design language doesn’t translate at all.

Better reference points

If I can’t use the real world to get a sense of scale, I might as well use Doom itself.

I’ve gone through some large areas that are particularly memorable to me, areas that I have a good sense of, and measured their dimensions.

However, I’ve tried using a new kind of unit: Doom grid cells. All of the numbers in parentheses are counts of 64-unit cells (for horizontal units only). It turns out to be much easier to grapple with 22 vs 24 than 1408 vs 1536.

  • E1M1: Hangar

    The iconic starting room is 640×768 (10×12) and 72 tall. The recessed area in the middle is 448×320 (7×5) and 216 tall.

  • E3M8: Dis

    The entire shuriken fits in a 3712×3584 (58×56) box. The sky is 256 units above the inner part of the ground.

  • MAP01: Entryway

    The opening room is 640×448 (10×7) and 256 tall. The subsequent hallway is 128 (2) wide and 72 tall.

    The large room before the exit is 960 (15) deep and 192 tall. Wow! I always think 1024 (16) sounds really huge, but this one humble room is almost that big.

  • MAP02: Underhalls

    The entire area with the little brick “house” is 576×896 (9×14), measured from the water. The surrounding walkway is 88 tall; the grass is 216 below the sky.

    The whole map fits in a 1920×1920 (30×30) box.

  • MAP03: The Gantlet

    The main large outdoor area is carved from a 1664×832 (26×13) rectangle. The water is 264 below the sky.

    The entire starting area just about fits in a 704×704 (11×11) box. The hallway is 128 tall; the center room is 160 tall.

  • MAP07: Dead Simple

    The inner part, including the walkway, is 1536×1472 (24×23). The outdoor parts are 120 tall; the roof is 80 above the walkway.

  • MAP08: Tricks and Traps

    The starting room is 448×448 (7×7) and 192 tall.

    The cacodemon room is 448 (7) wide, 1792 (28) from the door to the far wall, and 288 tall.

    The cyberdemon room is roughly 896×448 (14×7) and varies between 96 and 128 tall.

    The room you teleport to with the pain elementals is 704×704 (11×11) and 144 tall.

  • MAP12: The Factory

    The entire map is 3776×4288 (59×67). Outdoors is 208 tall. The outer wall is 96 tall, and the main raised outdoor part is 80 high, 128 below the sky.

    The main “factory” interior is 2560×1536 (40×24).

  • MAP14: The Inmost Dens, the most detailed map in Doom II

    Water to sky is 200, and the floor is 16 above the water. The brick wall surrounding everything is 32 high. The pillars between areas are 88 tall.

    The entire map fits in a 3520×3904 (55×61) box.

  • MAP15: Industrial Zone

    Ground to sky is 600.

    The central structure — the one you jump off to reach the other side of the map — is 1600×1600 (25×25).

    The entire map, excluding the purely aesthetic waterfront, fits in a particularly pleasing 4416×6144 (69×96) box.

  • MAP18: Courtyard

    The grassy courtyard itself is, very roughly, 2112×1920 (33×30). Grass to sky is 192.

    The surrounding area with the columns is 576 (9) at its deepest.

    The separate cacodemon area with the blue key is 768×1216 (12×19) and 272 tall.

  • MAP23: Barrels o’ Fun

    The starting hallway is 2240 (35) long, 384 (6) wide, and 256 tall.

    The blood pit is 960×1024 (15×16) and a whopping 384 tall. The hallways leading to it are 64×528 (1×8¼) and 80 tall.

  • MAP27: Monster Condo

    The starting area plus library form a rough 2624×1728 (41×27) rectangle. The other main area plus pain elemental room form a rough 2432×1600 (38×25) rectangle. Both are 128 tall.

    The twin marble rooms are about 576×1024 (9×16), not counting the 128 (2)-deep closets on the sides and backs. Total height is 256, and the walkway is 80 above the floor.

  • MAP29: The Living End

    The huge central blood pit is 3072×2816 (48×44) and a whopping 696 tall, which is almost five and a half 128s. The platform you first see it from is 200 above the floor.

    The central exit slab is 1216×1216 (19×19).

  • MAP30: Icon of Sin

    The main area is 2688×1728 (42×27) and 768 tall. Each platform is 128 above the next. Pressing the switch up top raises the lift by 512, or four 128s.

  • MAP32: Grosse

    The main room is a 2176×2944 (34×46) rectangle, plus a 1024 (16)-deep lead-in bit.

It might help to know that the player’s maximum run speed is about 583 units per second… or just over 9 grid cells per second. With straferunning, it’s about 11⅔ grid cells.

I also ran all of these maps through a slightly modified wad2svg and combined them into a single image, depicting all of them at the same scale. (If you like, I also have a large SVG version.)

Several maps all drawn to the same scale

One pixel is 16 Doom units; four pixels are 64 units or one grid cell; the grid lines mark 1024 units or 16 grid cells. The player can run across one grid cell in 1.8 seconds, or 1.4 seconds when straferunning.

I don’t know if I’ve absorbed anything intuitively from this yet, but it’ll give me something to refer back to the next time I try to map. Seeing that the entirety of Underhalls just about fits inside the Icon of Sin room, for example, is downright fascinating and says a lot about the importance of breaking space up.

Ah, you got me, this whole post was an excuse to list those dimensions and make a collage of Doom maps.


What if I fixed the player size?

Assuming Tom Hall is correct that 1 real-world foot is equal to 16 Doom units, a six-foot-tall Marine should be 96 units tall. With the magic of ZDoom, I can make that happen. I can also fix the heights of the humanoid enemies.

The opening scene of Doom II, but with the player and visible enemies much larger

The results are pretty hilarious. Highly recommend running around for a bit with one of these. Hint: you may want to bind a key to “crouch”.

Rocket Man

Post Syndicated from Alex Bate original https://www.raspberrypi.org/blog/rocket-man/

James Dougherty, co-founder and owner of Real Flight Systems, was looking at how to increase the performance of his high-altitude rockets…

Rocket Pi High Altitude Rocket

These types of rockets… yeah…

James’s goal was to build a ‘plug and run’ video system within a rocket, allowing high-definition video to be captured throughout the entirety of the flight. He also required a fully functioning Linux system that would allow for the recording of in-flight telemetry.

You can totally see the direction he’s headed in, right?

This requirement called for long battery life, high storage to accommodate up to 1080p video, and a lightweight processor, allowing the rocket to be robust and reliable while in flight.

Unsurprisingly, James decided to use the Raspberry Pi for his build, settling for the model B.

Before starting the build, James removed the HDMI port, composite video output, USB post, audio jack, and Microchip LAN9512. Not only did this lessen the weight of the Pi, but these modifications also lowered the power needed to run the setup, thus decreasing the size of battery needed. This shrunken unit, completed with the addition of a Pi camera, meant the Pi could run for 8-10 hours with the recording quality lowered to 720p60 and no audio captured.

Rocket PI High Altitude Rocket

Slimline Pi, now with 40% less Pi.

Sadly, the first launch had its issues: the rocket suffered a system failure that resulted in the destruction of the micro SD during the Pegasus flight at BALLS 23, an experimental rocket launch event in the Blackrock desert, USA.

Rocket Pi High Altitude Rocket

Ruh-roh, Raggy…

Rockets Magazine managed to record the launch which shows the highlights mid-flight.

ROCKETS Mag Balls 23 James Dougherty Pegasus

James Dougherty Pegasus flight at Balls 23

However, the next launch was far more successful, with close friend Jimmy Franco launching Rocket-Pi within a Dominator 4 to record the following footage.

(This clip comes with a motion sickness warning!)

Dominator 4 L1355 – TCC 02/21/15

Jimmy Franco flies Dominator-4 at TCC’s February Launch (02/21/15 on an L1355.

So what was next?

Aside from a few issues with Windows when trying to upload the footage post-flight, the main gripe was the lack of audio.

Investing in a new Raspberry Pi, making sure to keep more of the original components intact, James also updated the board with a USB microphone, added a USB flash drive to eliminate the Windows issues, and replaced the SD card with a lower storage option, as the footage was now stored in the flash drive.

1/3 Scale Nike L3150 – TCC Nike Smoke Drag Race 06/20/15

Launch and recovery of 1/3 Scale Nike Smoke at Tripoli Central Californias June 20th Launch. The vehicle flight-ready weighed 30 lbs, L3150 produces 800lbs initial thrust so we had about 26.6 G’s (burnt time 1.1440 seconds). Max speed: Mach 1.2; Max Altitude, 8,837′ AGL (GPS).

In the meantime, as James has continued to work on the Rocket-Pi, updating the hardware and code, he’s managed to put the Pi through some vigorous testing. During the most recent flight in Blackrock, the Pi reached 48K MSL (48000 feet above sea level… wow), at a speed of up to Mach 1.8 (1381 miles per hour… double wow).

Rocket Pi High Altitude Rocket

But I AM flying! And from way up here you all look like little ants.

Moving on from the build, James aims to upgrade various features. One of the most exciting upgrades looks to be the migration of Rocket-Pi to the Pi Zero, the smaller size allowing for multiple units in one rocket… creating 360-degree coverage of the flight (yes please!).

More of the build information, coding, and flight documentation can be found at the RFS website.

The post Rocket Man appeared first on Raspberry Pi.