Active cooled 3 axis gimbal timelapse (1 min 51 sec)

Slightly better, but probably not worth supporting yaw or pitch if software stabilization is required. A simple roll stabilizer is what you want. That does it for the 3 axis gimbal.

Time to document it before it's smashed into a million little bits.






...Continue Reading

Got the tiny motors up to .9A with active cooling. The pitch still has .3A without active cooling, to minimize vibration. The tiny motors have the least cogging artifacts, so active cooling might get them all the way.

Active cooled gimbal (2 min 6 sec)

...Continue Reading

Brushless gimbal + defished gopro (14 min 58 sec)

It was pretty bad at normal speed.

Jerky motion (5 min 3 sec)

...Continue Reading

Google AirShow streams I/O live from several RC blimps | Engadget at Google I/O 2013 (3 min 12 sec)

The indoor blimp has been seen as the most practical indoor UAV platform. It takes very little power, is stable enough to navigate tight spaces with little infrastructure, has low enough energy to coexist with someone not paying attention to it. The mane problem is it needs a lot of space & the helium can't be recompressed when it's not flying.

The Google video highlighted how a big company solves problems. The guys they hire have an MS or PhD in a very specific part of engineering from a very prestigious school, high grades, lots of formal training in data structures, complexity analysis, memorizing interview questions, no experience designing UAV's.

So you're looking at a Google guy put a 7.4V, 2Ah battery, Raspberry pi, & webcam on a blimp, but in a stroke of genious, he took the case off the wifi dongle to make it lighter. The guy is being interviewed by another guy with a camera that can't focus, but it's the latest camera & he has to use the latest camera.

Maybe if you don't have a lot of time to learn about all the different embedded computers, it's a way of doing it, but it shows how the hiring process has gotten really narrowly focused on people who just do 1 thing that they're formally trained for, but get really helpless outside that narrow focus.

Google I/O AirShow (6 hr 16 min 43 sec)

...Continue Reading

3 axis gimbal timelapse (2 min 16 sec)

Much better than 2 axes, but not perfect. It needs a more rigid structure, more powerful motors, softer wires. The PID gains are about as good as they can get.

There is a routine for equalizing the power as battery voltage drops, but it's not a simple linear relationship between PWM & voltage. If you double the PWM when voltage drops by half, it blows up the motors. The easiest solution was to fudge a linear PWM gradient from 9 - 12V that kept the motor current in a useful range, for the useful battery voltages.

Building a more useful gimbal with bigger motors is a matter of money.

3 axis gimbal solution (2 min 37 sec)

The algorithm from yesterday worked as described. The yaw motor could move anywhere without a loss of control. It was the 1st time the yaw coupling problem was solved outside China. At least for a short time, no-one else in America could do it. The mane problems are now a very wobbly frame, lots of cables getting tangled, too much cogging in the DT700.

Both IMU's required heavy, shielded cable. There was once a page which said to only solder 1 end of a cable shield, to avoid ground loops. http://en.wikipedia.org/wiki/Shielded_cable

After fighting I2C glitches forever, remembering a Logitec webcam was connected to both ends of the shield, decided to solder both ends of the shield. That ended all the interference. So for an I2C device where the only return path is the signal cable, you need to ground both ends of the shield.

Basically, you need a table of some kind for each camera axis

imu2 roll
imu2 pitch

|
|
V

table

|
|
V

motor 1 PID gains
motor 2 PID gains
motor 3 PID gains


The outputs of the 3 sets of PID equations for each motor are summed to get the motor steps. The hard part is computing the table. All 3 motors have a unique set of gains in the upright position. They have completely different gains in the 2 sideways positions.

There are 2 mane gradients for the PID gains: The roll & yaw motors trade places as imu2 pitch goes from 0 to 90. The yaw motor is replaced by the pitch motor as imu2 roll goes from 0 to 90.

The 2 mane gradients aren't linear. They're a sine wave. When IMU2 is pitched 20 deg over, it adds just 12% of the roll. When it's at 45 deg pitch, it adds 50% of the roll. When it's at 70 deg pitch, it adds 88% of the pitch.

If each motor has 3 sets of gains: the upright yaw, 90 pitched yaw, & 90 rolled yaw, each set of gains has 3 parameters: P1, P2, D2, a total of 27 values need to be manually tuned. The best way to tune it is to tune the fully deflected states.

Only 1 guy outside a corporation ever got the yaw coupling to work:

3-axis Brushless Gimbal 0411 tuning PID (0 min 46 sec)

But it was still unstable when the pitch & yaw motors were parallel. Having 2 motors share the same axis is a buster. You want yaw to be stabilized as much as possible, until the yaw motor is sideways. It requires gradually taking away more & more latitude from 1 of the motors until it's rigid. The easiest solution is to always have the pitch motor control 100% of pitch, with the yaw motor tapering its gains in the yaw direction as it goes horizontal. This doesn't maximize all the available degrees of freedom of the motors.

Without the brute force kinematic search, the table has the motors fighting each other. Doing the brute force search fast enough would be real hard. No-one has tested a Zenmuse to these extremes, but it probably does it right.

...Continue Reading

Brushless gimbal timelapses (4 min 18 sec)

The 2 axis gimbal is better than handheld, but it's not a miracle, especially when running. The most useful stabilization is roll. The software is most effective stabilizing pitch & yaw, leaving roll as the only direction which requires mechanics. It still glitches from lens glare, but there's no way it's going to handle running motion without software stabilization.

Freefly MōVI - NAB 2013 | videograndpa.com (0 min 41 sec)

...Continue Reading

In a world where the data rate on any phone is virtually infinite, the most bandwidth which can practically be made available to a cellphone user in a month is 3GB. That's 10 minutes of HD video/month. It's been that way forever & it's physically limited by the technology.

The "unlimited" data on T-mobile is actually throttled to 128kilobit, after the 1st 500MB.

With a phone transmitting omnidirectionally & a tower transmitting omnidirectionally, only 1 user can transfer data at a time. If there weren't bandwidth caps, all the users in a cell would use all the bandwidth, all the time, probably limiting the data rate to 128kilobit, which was the last rate at which unlimited data was sustainable.

The limit can technically be overcome, in the downstream direction. A phased array can direct all the energy to a very narrow angle. Hundreds of transmitters can be put on a single chip, to handle many narrow angle transmisions. It might be a large assembly. In the upstream direction, the phone would still be omnidirectional.

It seems inevitable to have highly directional, phased arrays in all towers & phones, in the future. Getting there requires many small steps, first analog, then digital, then software defined radio, than downstream phased array, then bidirectional phased array, all introduced in the capitalist Asia, slowly introduced in the socialist west, as money becomes available.

After 7 years, it finally puffed & died.





Unfortunately, the days of free phones with a 50 year contract are over. There are just $600 smartphones or $200 feature phones with 24 months of payments. You know you're old if you remember the 1st iPhone being an astounding $300.


...Continue Reading

http://en.wikipedia.org/wiki/Program...pular_websites

They all have a browser segment that uses Javascript & HTML5 with a server segment based on various languages of the day. The server segment is what makes money, since it can't be copied.

The current, most desired languages all became popular because of a dot com. If they win big, everyone else wants to use the programming language they used at the time & you track the demand in skills for a given time, based on the big dot com. When ebay won big, everyone started looking for Java developers. When Facebook won big, everyone started looking for Python developers.


Kiwipedia shows all the languages they currently use, but not what they were using when they became a hit. The Goog uses Go, but Go wasn't invented until 7 years after they started. Facebook was famously written in Python, but now uses C++.


ebay: java
google: C++
okcupid: C++
tumblr: ruby on rails
instagram: python
facebook: Python
twitter: ruby on rails
linkedin: java
amazon.com: java



Generally, dot coms winning big before 2000 used C++ & Java. Dot coms from 2000 - 2009 used Python & PHP. Today, it's Ruby on Rails.


Finding the best way to write web applications is still a work in progress. That's why it's a golden age in languages. No-one knows what the best language is. Clearly, interpreted languages are better for it than compiled languages.

Syntax composed of regular expressions is better than...Continue Reading

3 axis gimbal problems (2 min 20 sec)

Yaw is coupled to roll/pitch when tilted outside a very narrow angle. It used magnetic heading, which seemed to be distorted by the motors. Yaw is a lot of weight & power consumption for something that's always going to need software stabilization. The DT700 rewound with 130 turns of 0.2mm was never perfectly smooth, even at 0.6A.

Eventually, an open source solution to the yaw direction will appear. In the mean time, it's going back to 2 axes.

2 axis brushless gimbal & its limitations (2 min 49 sec)

...Continue Reading

A rare photo of how someone attached a gimbal to a motor. It was indeed drilling & tapping aluminum.





Shot some video with the 3 axis gimbal. The turnigy 2205 1350k had enough torque to do roll, if it got hot enough & the derivative was longer. Taking enough care to keep the yaw motor vertical made the yaw coupling bearable.

There's a lot of wobble from all 3 motor shafts, aluminum flexing, high impact. It needs a lot of cushioning to eliminate the jarring motion, but it can't be eliminated from running. The yaw motor has to be less effective, to keep from shaking all the stuff hanging off it.

After thinking about the problem, the way to decouple yaw from roll/pitch is to have a 2nd IMU on the yaw beam. The yaw beam is always perpendicular to roll. It doesn't need a compass. The relative roll/pitch of the 2 IMU's determines how much yaw is contributing to roll/pitch. It would take fusing the 2 IMU's to determine just the derivatives & rate feedback of the motors.

There's little point in having a 3 axis gimbal without going all the way, but there's little point in having a 3rd axis, either. It's too heavy to actually run with. Video is always going to need software stabilization because of the play in the structure. It's never going to be stable enough for long exposures.

Airborne video seems good enough with only 2 axes. It's probably better to wait for the 3 axis solution to make it to the open source version.

As soon as all 3 motors were fired up, it immediately became clear that the roll motor needed to be a lot more powerful or the roll assembly needed to be a lot more compact. There's too much inertia in that direction.

It also became clear why a 3 axis gimbal hasn't appeared from Alexmos or open source. The yaw motor fights the roll & pitch motors if it isn't level. The pitch motor handles crosstalk better, since it has less inertia. The roll motor can't handle any crosstalk before it oscillates.

In very little tilting, the yaw motor becomes a roll or pitch motor. The roll motor also becomes a yaw motor when tilted. It could probably be bearable if the motors were powerful enough, but never perfect.

A more complex feedback model is required, which predicts the effect of each motor on the IMU, after translation through the downstream motors. That would require knowing the orientation of each motor.

The DJI Zenmuse does it perfectly. It seems to have potentiometers on all the motors. No-one has ever torn down a DJI. It's only a matter of time before the extra math makes its way into open source. It'll probably use an IMU for each motor, so people can still make their own frames.

...Continue Reading

Went ahead with fabricating all 3 motors. The thing is, the 2 axis brushless gimbal footage is so stable in roll & pitch, shaky panning starts becoming noticeable.



This DT700 with famously broken wires last flew on a very windy day in 2010 & crashed. Sadly, the bearing fell out & was absorbed into the apartment, never to be seen again.



...Continue Reading

Found a rubber pipe was good enough for attaching the motor, for now.

Brushless gimbal motor test (1 min 40 sec)

That led to the 1st reasonably successful test of 1 axis.


The gimbal controller is not intuitive, since a single PID loop is not enough to track a solid camera angle. Reading through the forums & the open source controller, it requires an outer loop to determine a turn rate goal from the angle error. The turn rate goal is very low. Then, there's an inner loop tracking the turn rate goal by commanding very fast motor phase changes.


The turn rate from the gyro is not enough. The inner loop also needs the derivative of the gyro reading to dampen the turn rate. Version 048 of the open source gimbal didn't do this right, but still managed to work.


Most of the stabilization is done by the inner loop counteracting the relative gyro movements, with only very slight angle errors accumulating for the outer loop to correct.

The trick with calibration is to start with all the gains at 0. Calibration must be done with the camera attached, since it adds a lot of inertia. This causes the calibration without the camera to be completely unstable.


Start by increasing inner loop P until it oscillates, then increase inner loop D. It should lock on for very long periods with only the inner loop.


The optimum values had P & D equal & fairly high, with a derivative length of 3.4ms. If the...Continue Reading

Avoided looking at the bank statement because getting paid to work on robots was too good to be true & I suspected I wasn't really getting paid the full amount. When it became time for the 1st major $1000 car maintenance, it was time for the bad news.


Sure enough, I was only being paid about 1/2 of the amount stated. Basically got 1/3 in Nov & Feb & only 1/2 after Feb. The money was less than break even for the last year & now there was $1000 in car maintenance. Time to start thinking more about web applications than robots.


In the new economy, something is better than nothing. If the guy doesn't have the money, he doesn't have the money. You don't complain about only getting 1/2, not knowing what you're really going to get, or reality not agreeing with word documents. But you do have to budget your time based on the need to pay rent.


13 years after the 1st dot com crash, it's all social network web application jobs out there. My generation avoided all that SOAP, Ruby, JSON, Python stuff, because those jobs completely vanished in 2001. They still make us queezy.


If you create a website to learn the latest buzzwords, who's ever going to use it? How would you ever gain experience with large numbers of actual user accounts on a large data center? It's not like writing a desktop program, where your own needs are enough to fully exercise the platform.


2nd on the popular skill requirements is iOS & MacOS development. This...Continue Reading