Jack Crossfire's blog View Details
Posted by Jack Crossfire | Oct 22, 2016 @ 03:23 AM | 1,467 Views
It's more than coincidence that the denial of service attack which shut down the internet today happened 1 day after Tesla released the video of a model X driving itself to Goog headquarters. The model X is becoming aware.

Tesla Self-Driving Car Level 5 Autonomy (3 min 47 sec)

Finally got around to uploading this nugget of video. There's not much novelty, since the exterior is just the original NUMMI factory. The interior was off limits to cameras.

Tesla factory 5k (3 min 36 sec)
...Continue Reading
Posted by Jack Crossfire | Oct 19, 2016 @ 01:00 AM | 1,516 Views
Debutted the 100m with the lunchbox going 10.9mph with the human at 195 steps/minute. It was incredibly loud. The human could probably do 200m at that speed, with minor injuries. Took a turn & crashed into a curb, breaking the 3rd servo. Decided to put the servo saver back on, but use a screw intended for mounting the servo to mount the servo saver. It was too narrow, but anything is better than breaking the shaft.

Apple's announcement of abandoning its electric car project & canning everyone working on it brought up the subject of autonomous cars again. They're continuing a scaled back effort just in the software side. All searches for progress in Goog's autonomous car project cut off at 2013 when Sebastian Thrun left. Now the project is all but abandoned, but generation millenial remanes ever optimistic a self driving car is just around the corner, 11 years after the hype started.

Saw 1 autonomous car in real life. Uber had 1 going up & down SOMA during the Oracle & Salesforce trade shows. It had a $75,000 Velodyne HDL-64E spinning wildly. The internet doesn't do justice to how chaotic that thing looks when spinning. A stray soccer ball would destroy it. The remaneing sensors were the same as 11 years ago.
Posted by Jack Crossfire | Oct 18, 2016 @ 02:03 AM | 1,367 Views
The trick is representing the camera with 3 points defining a plane. The plane has to be multiplied by a rotation matrix defining the pitch motor. Then the rotated plane is multiplied by a rotation matrix defining the roll motor. 6 matrix multiplications in total, since the motors only rotate 1 axis at a time. The final plane defines the handle. The angle between the 2 planes would define the motor mixing.

It's computationally intensive enough to require a coarse lookup table. Plug in the roll/pitch angles & get the handle angle. 1kb would give 16 possible handle angles or 5 deg precision. There are 20kb of flash left. It would be faster than spinning a new board with IMU.

The theme of multiplying planes by rotation matrixes could be used to simulate other robots.
Posted by Jack Crossfire | Oct 15, 2016 @ 11:28 PM | 1,364 Views
Found minimizing D & maximizing I/P gave better results for the Feiyu. P is the feedback which stabilizes the video. D fights the feedback. It oscillates more when it gets knocked off target, but it still recovers on its own. Pending another test timelapse, that leaves the motor mixing. There is no motor mixing, for all intents & purposes.

It works perfectly vertical or horizontal, but the ages old mixing algorithm always oscillates in between. Made a test program to manually control roll/yaw by mixing the motors. This revealed for changing heading when the handle was 45', the yaw/roll motors had to move equal & opposite distances. To change roll when the handle was 45', the yaw/roll motors had to move equal & equal distances. There were slight errors, but the feedback should eventually settle them.

It was exactly the mixing algorithm it did before, but it also revealed the pitch sensor wasn't enough to determine the handle angle. Both pitch & roll sensors need to be applied to get the handle position. The yaw sensor isn't needed.

It would definitely be best done with a matrix. It's also a recursive problem. In order to move the servos, you need the handle angle, but knowing the handle angle requires knowing how much the servos are going to move. It might work in small steps. Since the stock firmware didn't do a good job either, a 2nd IMU in the handle might be the best solution.

Motor mixing must be solved for hard coded handle angles, first.
Posted by Jack Crossfire | Oct 15, 2016 @ 12:37 AM | 1,703 Views
Much was made of the candidates positions on space exploration, which were comprised of canned speeches. For the last 8 years, the shuttle program ended, there was 1 Mars rover, & a few interplanetary probes.

All the achievements of SpaceX were funded by the commercial cargo program started many years ealier. Even then, the commercial cargo program has spent most of its life grounded due to failures. There was a test flight of a mockup of the Orion crew capsule. There were parachute tests of all the capsules, 1 abort test of Dragon 2. There were engine tests & structural test articles for the SLS.

NASA budgets have shrunk enough that any program won't materialize until many administrations later. The commercial crew program has inspired the most promising powerpoint slides of them all, but has so far fizzled from lack of funding. NASA stopped buying Soyuz flights after 2018. The way things are going with the rocket failures & lack of funding, there isn't going to be a commercial crew capability before 2020, so the space station is going to be purely run by Russia.

H-Rod is going to be looking for money to fund the free education program & the expanded medicare program. Part of it will come from NASA.
Posted by Jack Crossfire | Oct 11, 2016 @ 06:57 PM | 1,263 Views
Posted by Jack Crossfire | Oct 11, 2016 @ 03:30 AM | 1,488 Views
The answer is yes. Computers can probably now govern us better than ourselves. All the information ever recorded in human history is online. A computer could assimilate it all to create the perfect government, decide all our votes, create all our laws. A lot of people would hate the result, but it would achieve the optimum potential, least pain, & most fairness of every alternative.

If there was any more land to colonize, the new colonies would probably base their government on a computed result. They would admit it's beyond our mortal constraints to govern ourselves, but luckily we have tools that the founding fathers never dreamed of, to do what mortals can't do.

In a way, we're already moving towards a computational government. The
stock market is entirely automated. We all rely on Goog searches to
decide how to vote.

It's surprising no-one has already tried to create a computational government. The Goog could do it right now, but the result would probably put them out of business.
Posted by Jack Crossfire | Oct 10, 2016 @ 01:36 PM | 1,224 Views
Feiyu run timelapse 2 (2 min 55 sec)

1st timelapse run with the Feiyu running custom firmware. It's pretty bad, but comparable to Ginger Guy's raw Feiyu footage. The heading drifts a bit more when running. Roll drifts ever so slightly. The drift is nowhere near as bad as stock firmware. The motor mixing issue is pretty bad. It's rough to have to keep it always vertical.

F-22 stabilized (11 min 36 sec)
...Continue Reading
Posted by Jack Crossfire | Oct 09, 2016 @ 01:20 AM | 1,514 Views
Feiyu Mini 3D alternative firmware (2 min 4 sec)

Still managed to not burn out the motors or break the flex wires. These are considered the mane risks for any development on it.

Stepped the IMU & feedback up to 2khz, but the mane limitation is nothing else can happen while I2C is being accessed. The IMU board has to send the readout & wait for a data packet to make a full round trip to all 3 microcontrollers & back before taking the next reading. Function indirections contributed quite a delay to the I2C driver so inlined a lot of it.

Much PID tweeking got useful pointing accuracy but not as good as stock, despite much higher current. The reluctance cogging ended up not a factor. In certain parts of the rotation, it slightly vibrates when fighting reluctance cogging, but it doesn't ruin the video. The feedback allows it to do smooth panning with no evidence of the cogging troubles.

Decided to implement the full auto centering using the hall effect sensors. So if it's within 10 deg of the target position, it uses the IMU. If it's outside 10 deg, it uses the hall effect sensors. There's a small jump when transitioning because the hall effect sensors aren't as accurate as the IMU, but it's better than a complete loss of control when it bumps into something.

Mixing of the roll/heading motors is definitely horrid. It didn't work in the stock firmware, but it was better. There's never going to be variable pitch or ability to initialize upside down. These problems are solved with matrixes & needing a matrix to solve kinematic problems has always been a career ending event.
Posted by Jack Crossfire | Oct 06, 2016 @ 04:00 PM | 1,199 Views
It was somewhat of a surprise that 3D Robotics dissolved. Fully expected it to get bought by someone, but they held out for too high of an asking price. They followed the open source philosophy like VA Linux, with the same results. We all lived through the failures after the open source boom of 1999. Now, if you opened up the DJI source code, you would find the 3DR source code. It promotes adoption through charity, but after fueling the kickstarter boom, even millenials have discovered charity doesn't buy as much as making money. Now, like their predicessors, they're hoping for a buyout at a much lower price.

Given enough money, would have gone with 3DR copters because they had replaceable parts & were hackable. All copters have since moved to proprietary all in 1 systems because they're the only way to solve the vibration, balance, & calibration issues. Maybe they're a lot less crashable & the cameras are good enough to not upgrade.

Anyways, consider in 2007 an autonomous quad copter with shaky cam was $18,000 with a lot of fussing. People used to hack them in their spare time. Today, the Mavic Pro is $1000 with a rock solid cam & no fuss. No-one hacks quad copters anymore. You just put them in the air & they're as good as tripods.

It was 1 of those niches which suddenly went from not existing to having unlimited possibilities with only the need for someone to figure out what the right quad copter was. The brushless gimbals have also followed the downward trend towards phone size. It's not long before the original Gopro box with 3 big motors is gone & the complete gimbal + camera fits in a what was once the Gopro box.
Posted by Jack Crossfire | Oct 03, 2016 @ 12:03 PM | 1,191 Views
Decided to just put in a standard brushless gimbal program & see if it worked without trying to fix the reluctance cogging. The immediate problem was latency when propagating data from the IMU to the 3 microcontrollers. This was why the stock Feiyu used 1Mhz I2C & 2Mhz UART, but I2C was crashing any higher than 100khz. Tried shorting the series 100R's & replacing the 2k pullups with 1k pullups on their I2C bus. That didn't work. It turned out I2C on the STM32 needs to be polled as fast as possible. Once done, it went all the way to 1Mhz using 2:1 duty cycle.

Captured a waveform to show 1Mhz I2C was really a thing. Helas, 16:9 duty cycle doesn't allow it to do the stock 1Mhz, only 720khz or 1.4Mhz. The 16:9 would be more reliable, but to get 1Mhz would require a clock speed multiple of 10. If the gimbal is fully deflected, it'll break I2C. 2Mhz for the UART wasn't a problem.

It would have been quite valuable to know the frequency of the stock IMU readouts. Set it to 1khz. Used source code from an ancient BruGi project. They ran the gyros at 8khz, but 1khz was the fastest the Feiyu could get the data down all 3 microcontrollers. It started glitching above 1khz, so left it. Better scheduling of I2C & UART is required to max out the rate.

At 1khz, the minimal feedback worked quite well. It seemed to compensate for reluctance cogging on its own. It's a bit more solid to run the motors at higher current than stock, but it overheats after a short time. Considered mounting a fan on the handle to blow air at the entire gimbal.
Posted by Jack Crossfire | Oct 01, 2016 @ 12:02 AM | 2,094 Views
Making Humans a Multiplanetary Species (best audience questions) (2 min 11 sec)

Part of the problem was the show happening in Mexico. The other part was even though a lot of the world took it very seriously, there was another part which doesn't take him seriously at all. At least he didn't moderate the questions with some bureaucrat.

Good grief, the government should fund more Musk, just like governments funded Columbus, Luis & Clark. Governments just don't do that anymore.
Posted by Jack Crossfire | Sep 27, 2016 @ 10:29 PM | 8,860 Views
Must concede, the 1st time the BFR appeared on the monitor was a bit of a letdown. It seemed too unreal to ever achieve. It went against everything in the Andy Weir book. The size was completely nonsensical. Just when the ship was supposed to stop at an orbiting outpost, the ship kept going, all the way from the launch pad to Mars. Was this nonsense what Musk worked on for the last 2 years?

The internet expected something more realistic, a 3 cored rocket of incrementally more power than the Saturn V, but not 4x more powerful. Things went downhill when the 42 engines all randomly stuffed under the booster appeared. It looked more like throwing the kitchen sink at a problem than rational calculations.

Then Iron Man showed up with a moustache resembling Howard Hughes. He assuaged some fears by stating the video was based on CAD models & there was enough room for BFR facilities to coexist with the current Falcon 9 facilities on LC-39. He already built a full size oxygen tank for the 2nd stage, in addition to firing an engine which seemed to be the full size engine. We all hope today's speech goes down as a Kennedy moment, where we all remember where we were when it happened & quote the lines for all eternity.

The spartan black & white graphics brought back memories of the Saturn V diagrams from the good old days. That made it look a little more legit. Nothing that detailed was released for the Falcon 9. Delta IV & Atlas V diagrams were always...Continue Reading
Posted by Jack Crossfire | Sep 26, 2016 @ 11:38 PM | 7,544 Views
Predictions for Musk night 2016: The BFR will be a single core equivalent of the Falcon heavy, with 9 Raptors. It'll be the same size as New Bezos, but have a reusable 2nd stage. It'll have a 3 core version outputting 15 million lbs of thrust. The raptor engine will produce 600,000lbs of thrust in the same size as the Merlin & a fraction of the size of the RS-25 which made 400,000lbs of thrust.

It'll put an object 75% as large as the shuttle in LEO. It'll use multiple launches for the MCT, fuel, & the permanently space based component.

The rest of the architecture will be equivalent to Andy Weir's vision. The mane focus will be the unveiling of the big rocket, since Andy Weir's vision is familiar to everyone.

It's the largest methane engine ever tested. That alone should have made more headlines than year 50 of race riots. As usual, the engine was heavily obscured in the test photos. It looked much smaller than past 600,000lb thrust engines, but Musk has a history of getting more thrust from the least weight than anyone else.

There's no obvious gas generator exhaust like there was on the Merlin, confirming it's the staged combustion cycle promised earlier.

Musk said it's the same size as the Merlin, but making 3x more thrust from a tripled chamber pressure. Based on photos of the Merlin next to construction workers, the engine under test is indeed the full size version. They're both slightly smaller in diameter than a handrail. The nozzle diameter...Continue Reading
Posted by Jack Crossfire | Sep 25, 2016 @ 12:47 AM | 5,459 Views
The guy who made a timelapse movie of traffic by writing a javascript program to load the data from the Goog developer API makes you wonder why he didn't just screen capture a browser window all day.

It brought to mind the 1+1 problem. The way modern developers add 1+1 is by creating several objects. There's a starting event broadcasted by the user. It causes a 1 object to broadcast an event. A + object waits for the 1 event. Then another 1 object broadcasts an event. The + object waits for that event. When the + object gets 2 1 events, it adds them & broadcasts an = event. There's an = object which waits for = events before broadcasting a display answer event. All the objects reside in their own threads.

Adding 1 + 1 can be done in a single line of code, but it's 1 of many more realistic examples in the mobile app boom where what could be done in a few lines of C code is done using thousands of objects & horrendously complex event passing sequences. Deciphering the simplest workflow requires much worshiping of the IDE's search tools & swapping between many files.

But a single line adding 1+1 is not a dogmatic solution & won't get you a job. The availability of plenty of money to enforce any software architecture dogma, no matter how inefficient, is a key facet of the mobile app boom. Many an interview has been failed by giving direct answers instead of dogmatic answers or worse, looking up the answer like you would do in the actual job instead of trying to recite it from memory like you're supposed to do in an interview.

It seemed to start in the 1990's with the idea of plugins & interprocess communication. The modules became smaller & more fundamental until every single thing is now done by a new object. Many a developer is shocked by the idea that a program can actually be written from left to right, top to bottom, stepped through like a book. The current generation never saw anything like that.
Posted by Jack Crossfire | Sep 24, 2016 @ 12:47 AM | 4,182 Views
For the impatient: “a breach in the helium system”

The helium spheres plagued them for a long time, starting with a “bad trends” tweet in 2015. Surprised the failure caused that much fire instead of just spraying liquid oxygen all over the place like the 2015 explosion. Carbon tanks never did the job on the x-33 & ended up killing the program. If carbon fiber can’t do the job again & they switch to solid metal tanks, it would be another blow to reusability.

As usual, millenials will be satisfied just knowing it was ruptured tank & it was fixed by whacking on a little more fabric & she'll be right. Generation X will never be satisfied & assume the tank was ruptured by an external force not to be disclosed until Nov 9.

The internet converged on spontaneous combustion of carbon fiber as it rapidly unraveled in a liquid oxygen environment. It would be a nifty experiment to deliberately rupture a COPV in a tank of liquid oxygen to see if it explodes, but it would be real expensive so it won't be done.

NASA tested COPVs to 7500psi, back when it made spaceships. The SpaceX ones were 5500psi.

Based on the graph, all tanks fail after a certain amount of time under pressure. Decrease the pressure or the time & the failure rate becomes a function of the number of tanks. In 100 launches, there would always be a failure.

When the tanks burst, it looks like a lion mane got abused.
Posted by Jack Crossfire | Sep 18, 2016 @ 05:32 PM | 1,977 Views
The ganged batteries made their debut 18.6 mile drive. Speed was reduced to 9:30 on account of the heat, which translated to 10:00 after PWM errors. The fuse didn't heat up. After the drive, both batteries were cold.

It was quite luxurious to not have to stop the run, squat, & change batteries. You have no idea what a pain that was for 1st 3 years of robotic exercise coaching.

Battery #2 in the low tray took 4545mAh. Battery #1 in the payload bay took 3294mAh. So they discharged as expected, but it was a quite high current draw. They carried water for 7.5 miles with 5 miles uphill. Need to swap battery trays to see if it was cable loss or internal resistance.

The wiring was redone to handle more current & gain a fuse. The fuse in the apartment was a polyfuse which started blowing at 3A. It was delayed proportional to the current. 3A took a long time. 8A blew it almost instantly. It got hot, never cut off, but allowed a current below 1A after blowing & continued heating. It would probably explode if the batteries shorted, but it's better than the wire bursting into flames. An HRC fuse would be nice. The normal cruising current with 2 batteries is 1.2A - 1.7A if they're balanced. It might blow on a hill or if the human goes real fast.

The once dubious LED arrangement turned out pretty respectable in its ability to light a large area.

The attempt to glue the wheels failed. The rubber flexed. They instantly popped out of the glue & spun the same as before.
Posted by Jack Crossfire | Sep 16, 2016 @ 11:11 PM | 1,916 Views
Suspect because it was a terrorist attack, the cause of the last Falcon 9 explosion won't be disclosed until after the election & H-Rod already had the talk with Musk Rod, for his sake. It'll be quite the stir when he finally reveals it right after H-Rod's election, but maybe Americans will just think it was politically correct for ISIS to blow it up. More of a stir would be if Emirates, Quatar, & Etihad airlines immediately got into the space tourism business, just like how the Islamic airlines took over the industry after 9/11.

In other news, I was intrigued by the fact that the fictional New Bezos would be larger than the fictional Musk Heavy, yet would make 1.5 million lbs less thrust. Musk's strategy was always to clear the tower as fast as possible. Every second of the liftoff burns enough fuel for 9 seconds of the landing. So he puts out 2 million more lbs of thrust than the weight of the rocket.

The liftoff mass of New Bezos was never given, but it would be comparable to Musk Heavy. A lot more propellant would be burned to clear the tower, so all that size would probably end up giving the same payload capacity as Musk Heavy.

7 Bezos-4 engines would make 3,850,000 lbs of thrust. The Musk Heavy would make 5,200,000 lbs of thrust to hurl 3,200,000 lbs.

New Bezos would offer a much bigger payload fairing. The payload volume on a 3 cored rocket is the same as 1 core, limiting the benefit to manely higher orbits of the same payloads or...Continue Reading