Hacker News Reader

Comment by monk_e_boy | Hacker News Reader

That was really amazing. I've been following it closely on YouTube but to see it actually fly - mind boggling! Not quite clean room facilities. The nose blew over in a storm. Locals streaming video from cameras mounted on telegraph poles. When it landed various parts came shooting off spraying gas as they tumbled away.

Full-flow engine - first to ever fly. And boy did it fly!

I love it. Back yard hacking hardware.

Summary - SpaceX are the first people to land rockets for reuse. Then they go and do the same thing with a different engine design, different fuel, in a water tower controlled with Falcon 9 reaction control system.

Quick question for the experts:

1 - how do they measure altitude? GPS is notoriously poor at this.

2 - any idea of how the control software was written for a flying water tower? Could they use the Falcon 9 software?

View on HN

In similar systems, the position is generally tracked with the combination of interial sensors (accelerometer / gyro / angular rate sensors) and external references like GPS and star trackers.

Inertial sensors are able to provide high frequency data on change in position and orientation. Higher frequency means the software can make much more rapid decisions to steer the rocket, on the order of 1000 a second or so, much more often than can be achieved with GPS.

The fact that inertial sensors don't rely on external signals (like GPS does) means that there is some degree of robustness- for instance, if there is a temporary disruption in GPS signal reception, the rocket will still have some idea of its position.

Over time, integration and measurement error accumulate from the inertial sensors. (Remember that they generally measure changes in position / orientation, not absolute position or orientation). For this reason, it is usually necessary to use external position and orientation references to correct the error that accumulates over time. GPS is used for this, and in some applications, star trackers can be used as an absolute orientation reference.

On the algorithm side, a Kalman filter combines measurements from all of the position and orientation sensors to generate a prediction of the current position / orientation / velocity / acceleration etc.

A minor addendum, you should feed your Kalman filter the gimbal and thrust of the rocket too, it'll happily chow down and combine that with everything else to further improve its estimate.

It's dangerous to throw extra sensors into a Kalman filter, because if the sensor goes bad it'll corrupt the output.

Angular rate sensors are extremely accurate, far more accurate than a thrust sensor could be, so it probably wouldn't improve the overall accuracy anyway.

>> It's dangerous to throw extra sensors into a Kalman filter, because if the sensor goes bad it'll corrupt the output.

Not necessarily. A Kalman filter uses a covariance matrix to account for noise in the input signals. Another technique can be used to dynamically adjust that matrix while it's running. If a signal doesn't agree with everything else going on, it's noise level is effectively increased to the point that it doesn't contribute any more.

I know someone who implemented a system like that and it could drop sensor inputs and bring them back in real-time. I realized that all the traditional sensor diagnostics others had used in similar systems might be obsolete with something like that. It was a pure math-based system, no logic or thresholds for sensor diagnostics and it just worked (TM).

I've tried to make adaptive Kalman filters work, and it's not easy. For something like a rocket, the covariance of all the sensors is very low while it's sitting on the launch pad. As soon as you light the engines, the covariances jump up. So an adaptive filter will try to adjust its weights during the first few seconds of flight, which is a terrible time to change everything.

Usually it's better to lock down all the filter coefficients.

Also, an adaptive Kalman filter measures noise on each input to estimate error, usually by looking at the autocovariance. This turns out to be maximally bad when a sensor fails and emits a constant value, because the autocovariance becomes zero and the adaptive filter will decide it's the most accurate of all the inputs and weight it heavily.

Before a Kalman filter, you need redundant sensors and logic to discard ones that disagree with the majority.

Angular rate sensors and accelerometers are cheap and light, so I'm sure they have at least 3 sets. Maybe 5.

A friend of mine used an adaptive Kalman filter to estimate vehicle speed in a car using the 4 wheel speed signals, and steering angle IIRC. They tested on special surfaces (alternating ice patches or something) that caused wheels to lock or slip. He said it was able to track actual vehicle speeds very well down to a single valid wheel speed. I think the key is not to just measure the noise of the signal itself, but its deviation from "everything else". Probably simpler in a car than on a rocket?

Anyway, these things are possible to varying degrees. Nor did I say it was easy - I've only implemented one, never designed one ;-)

Ah, I guess I'm used to wheeled robots where odometers are often your most accurate gauges of position.

Modern GNSS can reliably measure altitude at <50cm 2-sigma accuracy using techniques such as RTK and PPP-AR. Modern GNSS is a better source of altitude data than barometers.

Likely SpaceX is using a combination of radar altimeters and GNSS.

Source: I do engineering on modern GNSS

Super interesting info. Sorry for my annoying questions. Does modern GNSS receive that level of accuracy in cities among buildings, or is that an ideal case like what SpaceX has, being outside?

Also, how expensive is a modern GNSS receiver that can get that level of altitude accuracy? Is this something that could make it into phones some day?

Not an annoying question whatsoever.

Dense urban environments are challenging. The error distribution is more complex there, its hard to definitively say. The numbers I'm quoting is for open sky environments where you have plenty of satellites and little multipath.

For the average end-user, these are $500 GPS units (this is the one I work on: https://www.swiftnav.com/piksi-multi). The technology is already moving down the supply chain to ~$10 GNSS units from Broadcom and ST (we're doing this: https://www.swiftnav.com/news/swift-%E2%80%8B%E2%80%8Bnaviga...)

The issue with phones is mainly an antenna issue. Your phone antenna is tiny and squeezed in alongside half a dozen other antennas and radios. This degrades the GNSS signal quality a lot. A stopgap here is external GNSS antennas for your phone: you might plug your phone into your car and get lane-accuracy turn-by-turn directions, but it's unclear when we'll have high accuracy GNSS inside phones, but most major phonemakers are indeed working on this.

... $10?! Really? Can we hook one up to a Raspberry Pi?

This would be a game changer for my sport (kitesurfing)

Depending on the update rates and accuracy you need, there are many commercially available GPS breakout boards and small cheap modules under about $20

I've used [1] which can be found for about $18 before on some toy projects.

[1] https://www.u-blox.com/en/product/neo-6-series

GPS doesn’t do height accurately :( 10m error

I can’t answer all the questions but I can talk about RTK techniques. I recently used two $75 GPS receivers and two raspberry pis to create an RTK GPS system (real time kinematics). With RTK you have one receiver that is fixed - it does not move. The other receiver is on the thing whose position you want to measure, and the two devices are connected through the network. Because the system knows the fixed station is not moving, any drift in measurement represents the real time error of the current satellite constellation. The moving unit subtracts that error from its own measurements to get very precise figures for its position. In the system I built, it seems to have centimeter level repeatability. That is, if I am looking at the read out in real time and I stop moving the receiver, the drift in the measurement is a couple of centimeters. If I move it 20 centimeters that is pretty closely reflected in the read outs. Currently I don’t know the absolute accuracy of my system but the relative accuracy is very high!

To add to the parent comment, super high precision gnss/rtk is often paired with multiple inertial measurement units, not very dissimilar from what you find in a smartphone. Also used in COTS drone flight controllers. Software can combine data from an imu that some vertical acceleration had taken place, with data from gnss sensors that altitude is now 2m higher, for additional level of confidence in what the gnss sensors are reporting.

I'm no rocket expert, but I have some ideas about altitude.

> 1 - how do they measure altitude? GPS is notoriously poor at this.

GPS is indeed notoriously terrible. They might have better luck with it though, given they can buy high-quality receivers and always have a good view of the sky.

However I think I read (or hope at least) that they use barometers. Even cheap smartphones have barometers for relative altitudes these days, and while the barometer data is influenced by the atmosphere and weather of the day (the focus of like all my startups [1]), the rocket could easily know about the differences in the weather and create MSLP (mean sea level pressure) numbers that would allow for excellent precision at landing.

Your phone barometer can tell the difference in altitude between your head and your feet.

[1] My latest go at this is https://www.allclearweather.com (US, Android) with a goal of eliminating the altitude part of barometer data so that the remaining data can be QC'd, summarized with statistics and eventually hopefully included in weather models for increased forecast accuracy

I think they do also have a radar for distance to pad information but I couldn't cite that. I believe they have a form of instrument landing system, similar to how it is done at major airports but oriented for the rocket of course, and the distance calculating "radar" could be part of that (using signal timing) but I am not sure exactly how they did it.

Falcon 9 is known to have a radar altimeter; it's quite likely the Starhopper does too.

Yes I think that radar idea is quite correct. I now recall Elon/SpaceX explaining that this rocket (BFR or whatever) should be able to land on any solid body in the solar system. This would eliminate barometers and GPS for long-term solutions, but keeping radar/lidar and other light-based imagery in the running.

>> any idea of how the control software was written for a flying water tower? Could they use the Falcon 9 software?

https://www.semanticscholar.org/paper/Lossless-Convexificati...

Reddit blurb about that paper: https://www.reddit.com/r/spacex/comments/7t2tb2/a_paper_by_l...

> 1 - how do they measure altitude? GPS is notoriously poor at this.

I would imagine they would use a number of different sensors, they probably have barometric altimeters, but probably rely on some kind of radar altimeter for low altitude maneuvers.

Oh yeah - radar! Duh, I was thinking lazers or something.

Reply on news.ycombinator.com