Redwood timelapse (4 min 0 sec)

Stepping down the accelerometer weighting did indeed reduce the shaking. The battery is losing 800mAh per hour of stabilizing, giving it 2 hours before puff.

The key features are RCA connectors because the TRS connectors delaminated & melted. It has an enclosure to shade it from the sun. Hot glue won't work because it would melt. They don't make mp3 players anymore. After 9 years of baking, it's time for a replacement.

The leading candidate is a raspberry pi. It needs to boot as fast as possible when the power comes on & resume playback. It needs to save the playback position when the power goes off. It needs an interface to select songs, control volume, control EQ. A bluetooth phone interface is the leading candidate, but the pi must run without the phone. To survive the heat, it needs to be underclocked probably down to 200Mhz.

Some screws were omitted to make it lighter. The board got a conformal coating. A firmware update reduced the accelerometer weighting while adding a higher weighting for 5 seconds after a gyro saturates. This lets it initialize quickly while suffering less from acceleration. The chance of pitch control or upside down control fades as it gets older. There's a desire for an absolute mode which gives rapid movement without stabilization & a way to control it from a computer.

Still amazing it works as well as it does. There were times after it arrived in March, when it felt like it would never work. It was just a matter of over stressing the reluctance cogging, the fact that the stock firmware didn't work, & doubting anyone could outdo Chinese engineering.


https://www.rcgroups.com/forums/show....php?t=2640862

The original firmware left quite a feeling of despair.

Dougherty Rd run timelapse (3 min 57 sec)

Shaking is from the IMU getting thrown off by acceleration, but this firmware does perfect motor mixing.

The answer is yes. Multivariable calculus works & the handle angle can be derived from the motor positions. The lookup table for the angle ended up precise to 5 deg while only taking 170 bytes. It's vastly simpler than a 2nd IMU, but requires volume manufacturing to be cost effective. It's a very sloppy result, because the mechanics in the motors are sloppy & the hall effect sensors are sloppy.


This led to a nasty gain schedule of PID constants to handle the motor mixing. It barely worked. The decision was made to make assumptions about the motor mixing instead of relying on the PID controllers to hunt for a result, as had been done for 4 years. The ratio of roll & pitch motor steps would be hard coded for every handle angle. A small math test program showed this would follow a simple sine wave pattern.


The hard coded motor mixing worked quite well. It didn't need a gain schedule. It was rock solid & better than the factory settings. It was surprising how simple controlling the gimbal was, but also what a high level of multivariable calculus the Chinese were applying to forgettable consumer products.


Adding variable pitch would be a matter of multiplying the IMU result by a similar motor mixing formula. The gyro rates would also have to be mixed. It's such a pain to avoid bumping the pitch on the joystick, it would require replacing the joystick with tact buttons or providing another switch to lock the pitch. Joysticks are bulky, but...Continue Reading

...

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

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.

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.

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.

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.

...

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.

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

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.

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.

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.

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.