The smaller remote control was finished, after a last minute decision to upgrade the radio. It was easy to make the antenna always perpendicular to the vehicle. This should greatly increase range. The battery was shrunk with an LP2989 voltage regulator. Unfortunately, the output voltage fluctuated from 3.3 to 2.8 with changes in input voltage. Putting in the bypass capacitor lowered the voltage to 2.2, so that was a cactus voltage regulator. Current is always 60-100mA.

The new driving computer was finished, with a last minute decision to omit GPS. It would be a lot of work to program a map. It would start with drawing a route in Goog earth, still the only program which allows drawing a route. The turns would still require a lot of manual override, with the GPS errors. Quite a few steps remane, to make the computer use the MPU6000 with optional AK8975, install it in the truck, make it use the serial port instead of SPI, send realtime video through the serial port instead of wifi.

Everything needs to be conformal coated.

The Bezos mobile was a long time coming. Behind the hype over amazon.com's neverending losses was an obscurity called Amazon Web Services. Unlike the headline store, AWS was churning out billions in passive income from nearly the beginning. Almost the entire internet has been hosted on AWS servers. Today, AWS contains most of the computing power in the world, an obscene amount of clockcycles which can't possibly all be dedicated to web pages.

While never announced, AWS probably makes a lot of money from government code breaking entities. It allowed Bezos to fund his own space program in complete secrecy, with no official government aid.

Going vertically to 62 miles & recovering all the components was quite a stunt, but without much point. It's been done horizontally, forever. Spaceship 1 went 7 miles higher. A fully recoverable system using today's technology can't be scaled to orbital flights, whether vertical or horizontal. Some expensive parts must be discarded.


No details of the Bezos mobile have ever been released, but it's probably similar in efficiency to the Delta IV. All Kiwipedia could gleam is the Bezos-3 engine uses the mane combustion chamber to feed the turbopumps instead of using a separate gas generator. It's the 1st time a cryogenic engine has emerged from purely private funds. With the debut of government money, he plans on developing another cryogenic engine using liquid methane.

Reading up on the Bezos mobile revealed a nugget about...Continue Reading

It was the 1st new board in 11 months. The 1st truck board arrived on Dev 7, 2014. It had a lot of rework & a MOSFET for controlling the headlights. Hard to believe that old age has degraded memory so much, but I had no memory of the 1st board or even reworking it. The 2nd board arrived on Jan 18, 2015. It had no headlight control.

Memory of board etching times faded. The ideal times are exposure: 25 min, etching: 40 min. Left it etching for too long, which didn't kill anything, but it had a toner bubble which broke a trace. There's very little memory of working on boards in the last 15 years, despite all the time it took.

The 3rd board has a UART for the Odroid instead of SPI, I2C for a full IMU, a UART for GPS, but probably not enough power for GPS above 1Hz. A board for a 2nd vehicle's hand controller also emerged. Knowing whether that 2nd vehicle will ever be affordable requires checking the current rent.

Whether an IMU heading is accurate enough to keep it on a path is the 1st task. It will have some knowledge of the path heading from manual input & a rough heading from the IMU. Later on, the path heading could come from GPS. The heading from the IMU can help find the path on the camera & provide a boundary for feedback headings. Knowledge of the path edges from the camera can offset errors in the IMU heading. The camera would have a very diminished role, compared to the IMU heading.

Does anything still show under all your advertisements?

Funny watching 1 generation of Linux distributors get rid of core files years ago only to have the next generation replace them years later with the .xsession-errors file & encounter the same old problem of crash logs filling the entire drive.

Now within a matter of days of a video player spitting out h264 debug statements, the .xsession-errors file grew to all 750gigs of the SSD it was stored on before firefox started crashing more than usual. After the usual 50 comments on the multibillion dollar stack sites going absolutely nowhere, the solution at least on Ubunt 14.04.2 was to change the name .xsession-errors in /etc/X11/Xsession to /dev/null

Log files have always been a tradition in UNIX. There are dozens more in /var/log. Every night, the latest ones are compressed & stored in a rotating history of log files. It wasn't a problem when hard drives could be rewritten forever & were slow, but modern SSDs can be filled up in a couple seconds & only take 1000 write cycles before they have to be thrown away. A particular debug statement which prints something for every pixel of an image could fry an SSD instantly.

Just by selecting the right luminance, shadows can be detected. It might even work in variable lighting. It wouldn't be able to fill missing areas of the path, since the shadow borders can't be detected. Its mane use would be throwing out bad frames. The algorithm would be to detect when the edge of the path came within a certain distance of the shadow pixels. If enough shadow pixels were within range, the frame would be discarded. If a shadow crossed the edge, it would be discarded. If the color key was all shaded, it would be discarded.

The best shotgun chroma keying algorithm still had a hard time isolating the path in the right lighting, so wasn't convinced making a new board would work. The sun is so low in winter, it makes a lot more shadows, revealing more problems in machine vision. It was back to more notes on robot dogs.

In the old days, it was a tradition to stump Santa by wanting what wouldn't exist for another 30 years: LED TV screens, quad copters, watch TV's. Now the tradition continues. Despite Boston Dynamics introducing a robot that could run 3 years ago, no consumer version of one has appeared. 3 years is an eternity in modern terms.

A running robot dog is still a very difficult problem that preoccupies grad students for years, with no-one having miniaturized one. The Boston Dynamics robots used rotational hydraulics so powerful, they could hop. Their 6 year old consumer sized robot was limited to very slow movement by the speed of the servos.

It became quite clear the spring aided Swiss robot can't turn or support the weight of a battery. If a legged running robot is required, the best alternative would use 2 fans blowing air to support most of the weight & stabilize it. The legs would just provide sideways balance & forward motion. It would have really short battery life. Running robot dogs are still firmly in the imagination.

The apartment had the required components to augment the car navigation: an MPU6050 & AK8975. Not sure what the best parts are nowadays, but a 6 DOF IMU instead of a 9 is now ideal, since it's now known the compass needs to be far from the power system.

The truck has done such a good job in its current form, as a training tool, the decision still hasn't been made to rebuild it to augment the navigation. There's still a desire to make a 2nd vehicle for the day job, since most of the time is now spent there. Another pair of radios & all the parts required to upgrade it are in the apartment.

A Losi Micro T would be easiest to fit in the office, but probably too small to negotiate the curbs. Prices are outrageous in 1/24 size. If only quad copters had enough range to do the job. They would need a tethered battery backpack.

Another idea was a robotic dog. Scale model RC cars aren't a big thing, if they exist at all. There's no scale model lunar rover. Scale model flying machines have long included ornithopters. If someone is fascinated enough with biological movement to pick an ornithopter over something more practical, surely a biological ground vehicle would be worthwhile.

There are no affordable robotic dogs which can go faster than 4mph. The last Boston Dynamics models before their buyout relied on electric hydraulic pumps to manetain a reservoir of static pressure fluid. The constantly pressurized reservoir could be called upon at any moment to provide instant, fast & powerful force. It was the only way enough force at enough speed could be produced to generate the required leg movement.

The small robotic dog relies on passive springs to augment servos. It uses 2 servos per leg, pulling cables which must be tightened. It's passively stable, driven by open loop servo commands, & goes 3mph. http://biorob.epfl.ch/cheetah

There's certainly potential for scaling it up. Replicating the mechanical parts & making them strong enough to go 10mph would be an ordeal.

There is an algorithm which generates a basket of possible paths, using a large subset of color keys. For any combination lighting & shadows, it's guaranteed to find at least 1 frame which has the closest approximation to the true path. This reduces the problem to just finding which approximation is the best. In this case, previous knowledge of the absolute heading of the true path & vehicle could be the only pieces required to close the loop. Once the ideal path from chroma keying is known, the edges can be found.

Getting a vehicle heading accurate enough to do the job is still tricky business, but if it worked, no further work would be required. It would start with a test program that superimposed heading on video. The compass would be attached to the Odroid.

A purely vision based filter is still ideal. An attempt to rank images based on edge detection failed. It calculated the best triangle in each frame, picking the frame with the highest number of masked pixels in the triangle. Another idea is to pick the frame where the masked pixels line up with the triangle with the least noise.

Started a new project to try to collect every video from the famous flight director until the Goog shuts down the party.

Wayne Hale Mars Society Speech (12 min 56 sec)

Wayne Hale Von Braun Symposium speech (23 min 56 sec)

...Continue Reading

The cheap fisheye lens has its widest view in the corners & narrowest view in the center. Given this limitation, you want the widest part of the path on an edge & the narrowest part of the path in the center. It should expand the narrowest part & shrink the widest part.

You can't point the camera diagonally to increase the field of view of the path. The narrowest part would have to be down the exact center to fit in a corner, which it never is.

Pointing the camera down to get more of the path in view for finding color keys doesn't work. This puts the narrowest part in the widest field of view near the top of the frame. It makes it harder to find where the vanishing point it. It puts the widest part in the narrowest field of view near the center of the frame, reducing the amount of path edges visible.

Nevertheless, curiosity about the effects of camera pointing prevailed. It was while driving 10 miles to gather footage that the intuitive effects of the fisheye lens became clear. Tried aiming the camera down, but the suspension still pitched up on its own. There's no way to precisely aim it.

It yielded the 1st footage in cloudy weather. Machine vision was pretty awful, due to the lack of contrast.

An unannounced Trident II missile test from a submarine no-one knew was there proved a bankrupt Navy can still shock & awe. Undoubtedly, it was meant to shock Putin as much as the book of face.

A short drive with the camera pointed at 2 oclock revealed the path would still occupy most of the frame with the most consistent color. There wouldn't be a reliable negative mask from looking at the sides. There was still an idea of throwing out colors which are outside hard coded boundaries & throwing out frames which don't have a good lock on the path.

It's a shame to lose $100 on a computer to run a machine vision algorithm that didn't work. Tried out a more complete implementation of the Goog algorithm. It took color keys from a rectangle spanning several frames in time for 48000 color keys. This was quite robust, but ground down to 1 frame every 4 seconds on the quad 3.8Ghz. If it ever got off the path, it was cactus for a while until the bad color fell off its history.

If the truck simply drove a short distance & stopped for several seconds to compute a new frame, it would be a victory. Another idea came to get a wider horizontal field of view, wide enough to make the path a small fraction of the view. It would take color keys from known areas not to be the path. Lacking any fisheye lens for a webcam, it would use 2 cams pointing at 10 & 2 oclock.