I was doing some analysis of a solar-electric plane that can fly indefinitely: https://github.com/gusgordon/atmospheric_satellite
Seems feasible, never went past the analysis phase though :)
HN user
contact: gordgus@gmail.com
I was doing some analysis of a solar-electric plane that can fly indefinitely: https://github.com/gusgordon/atmospheric_satellite
Seems feasible, never went past the analysis phase though :)
This is awesome, nice work! In case it's useful, I made a Python package for calculating solar irradiance at altitude: https://github.com/gusgordon/airmass
Takes into account lots of stuff (e.g. attenuation from air, ozone, and water vapor) with the goal of estimating solar power at any altitude/latitude/day/time.
Totally - right now it's using the USDA food nutrient database [1] which has all nutrients, so all the nutrients on the back-end are there. Calories is the most important thing to the majority of people (in my experience), so there's a balance between showing too much information vs. keeping things simple. Probably should just add a setting to show everything, though.
Stopping by to say this is super cool! I've been pretty obsessed with this idea for a while — here's an analysis I did a few years back: https://github.com/gusgordon/atmospheric_satellite
I got a minimum wingspan of around 8m for self-sustaining flight on the winter solstice with a small payload — pretty close to what you all built.
The biggest problem I ran into when creating this analysis was accurately estimating solar irradiance at different altitudes. Here's the module I built for estimating that, in case you find it useful: https://github.com/gusgordon/airmass
Congrats and good luck!
Given that there have been multiple mass extinction events in Earth’s history, it seems reasonable to spend a small fraction of GDP on colonizing another planet. How about something roughly equivalent to the amount we spend on chapstick?
Yeah, that’s basically what I do, but I often find I need to play around with intermediary data within functions.
What’s your recommendation in terms of tooling for cases where it’s not just prototype -> production, but an iterative process? I love notebooks for prototyping, but I find it’s a lot of work to make sure notebook code and prod code are in sync. Maybe just debugging with IPython?
Good question. One requirement for the aircraft in this optimization is that they must have more energy in the battery than they did 24 hours prior. If the aircraft started at full energy, they wouldn't ever be able to satisfy this requirement, so that's why it's an independent variable.
For example, an aircraft could "start" at 50% battery state of charge, then charge to 95% over the course of the day, then come back 24 hours later at 51%, and that would be valid. There are other ways around this, but this is what I came up with at the time.
This is similar to why the starting altitude is allowed to float. The gravitational potential energy of the aircraft can be used as another "battery", but the aircraft is only a valid solution if it's not losing altitude over the course of 24 hours.
Yes it's a lot easier at lower altitudes since you can get more lift, but you might run into some extra regulatory issues with that :)
For those curious about the physics of these aircraft, here's an analysis I did of the same concept. The goal is to determine the smallest aircraft configuration that can indefinitely sustain flight: https://github.com/gusgordon/atmospheric_satellite#readme
Here's a fairly in-depth analysis of supersonic electric VTOL aircraft: https://github.com/gusgordon/electric_jet
tldr; they become "practical" with a battery specific energy of around 1500 Wh/kg. However, if you just want to do a demonstration, they are practical now (as this post suggests).
The primary goal of RCV in the US is to address the hostile partisan divide. Making more parties viable is secondary.
When you have a ranked choice system (even if it's only in a fraction of states), it incentivizes the candidates to not disparage each other. If candidate A attacks B, it means the B supporters will rank A lower. RCV draws candidates closer together.
It’s expensive to get access to a GDS API and, from what I’ve heard, the data they provide is quite difficult to work with. There’s a reason Google bought ITA for $700m, right? If this project ever grows, it could make sense to pull from a GDS.
Thanks - just using Amazon SES to send the emails.
Yeah, it uses all airports within 40 miles of your location (or your closest airport).
Thank you. The front end is hosted with Netlify and the back end uses Chalice: https://github.com/aws/chalice It also uses Chrome Puppeteer for scraping.
Chalice is super awesome. I'm planning to write a blog post on the tech.
Thank you! I’ll take a look at the scroll bar issue.
That’s right, it uses the 90-day average price of flight + hotel. I take the z-score relative to that and filter for trips with lower z-scores.
Not currently — this is just for flight and hotel combinations. Good idea though, I want to add that along with train and boat trips.
Flying at higher altitudes in lower density air also reduces lift, though [1]. A plane does get extra benefit from flying higher as drag on the fuselage is reduced, but there is a limit — the plane has to go faster to make up for the reduction in lift due to the reduction in air density. An electric plane ends up being able to fly a little higher, but not by much. See these notebooks for details:
https://github.com/gusgordon/atmosat/blob/master/atmosat.ipy...
https://github.com/gusgordon/electric_jet/blob/master/plane....
[1] https://en.wikipedia.org/wiki/Lift_(force)#Lift_coefficient
Larger planes aren't significantly more fuel efficient. Look at the A380 vs. the 787.
The reason airlines thought hub and spoke was more profitable was because they could basically guarantee that every flight would be full. If a flight is only half full, you're lugging an entire airplane around for no reason which is very costly.
Hub and spoke is worse than airlines thought, though — newer planes like the 787 are far more efficient, so that cost of lugging the airplane around is reduced.
You clearly don't have a basic understanding of the issues here. Cars that use gas incur the additional penalty of environmental damage that is unaccounted for in the value of those vehicles relative to their cost. For example, a gas car may cost $1000, and bring $1500 of value to the owner, but incur $200 of damage to the environment. This is not priced into the value of the car. If you want to learn more you can read the first few chapters of an introductory economics textbook where they cover market failure.
The government didn't say "give us the one we can make bombs with" or anything like that. In a review [1] they discuss groups working on thorium reactors who find that these reactors are potentially cheaper than water cooled reactors, but there are uncertainties and a demonstration plant is needed. They basically state that thorium reactors might work well, but their potential benefits don't outweigh the existing industrial commitments. Sure, the reason for the existing infrastructure was for the ability to more easily make bombs. But when this was reviewed, it was possible to make bombs with Thorium, too. [2]
There are advantages and disadvantages to thorium over common reactors, but it's definitely not a magic bullet.
[1]: WASH-1222 (p. 49) http://www.energyfromthorium.com/pdf/WASH-1222.pdf
Why are you so in favor of nuclear energy startups when solar+batteries seems to be the cheaper and more immediately implementable option?
You would need to have huge amounts of batteries on the satellite, like 15 tons of lithium ion batteries per kg you want to get to orbit, or a nuclear reactor. Then you have the fun problem where if you miss the heat exchanger you have a death ray.
Thank you! Websockets speed it up a little, about ~20-50 ms. I am a fan of open source, I would consider open sourcing part of the backend if I can turn it into a library that is useable.
Thank you! These are all great suggestions. I am probably just going to go down the line and add most of these. I want to stray away from user accounts because they take time and resources, but I'm not sure if that's the right call. I'm erring on the side of improving the core functionality before the user accounts. The list of lists is also a great idea, that should probably tie in with user accounts.
FYI you can enter custom foods (primitively) by typing e.g. 500, 20g, 30g, 37g. This definitely should be improved in the future though.
Pics, or some clip-art style stuff would be a good idea for giving more feedback on what is entered. The larger idea of pictures is good but I'm not going to pursue it right now.
Data source is USDA along with a bunch of other various sources that I scraped. I believe scraping is 100% legal here because nutrition labels are not proprietary.
I will add an about page, that is a good idea. Backend is Python/MySQL on DigitalOcean. DigitalOcean was a hassle (not DO itself, but just getting the server set up) but I have been learning a lot. It's fast because I spent a long time optimizing how queries were analyzed and the MySQL queries themselves.
Thanks! I am pondering how I want to take this, but I want it to stay pretty lean because I like it more and it's faster to develop. I'll consider a dev blog, probably just in the form of a more comprehensive about page.
The percentage bar is % energy content. Maybe there is a way to make that more clear. Displaying things in terms of weight percentages is misleading because the body burns a set amount of calories, not a set amount of food.
Thanks for the suggestion. I agree, I think I could improve how details are displayed more effectively anyways.