Complicated Medium

So that solar physical simulator I mentioned? It’s happening. I’m now referring to it as the PhotoVoltaic Emulation System, or PVES.

Here’s a high-level black diagram of the whole thing. You probably can’t read it. It contains: Two processors, an AC-DC converter, a DC-DC bi-directional buck converter, an isolated DC-DC buck/boost converter, and a high-speed voltage-controlled current regulator. Not to mention the PWM generation, logic supplies, current/voltage measurement, and communications required for all that.

Needless to say, this is an ambitious project. Shall we get started?

I’m way ambitious about this. I intend to make the world’s best solar car power trackers. I heard the old ones are getting an upgrade, so the bar is set high.

Anyway, on to the emulator. It contains “way too many” power electronics: A buck-boost regulator to create a “raw” PV voltage, followed by a tricky linear regulator to limit the current of the output based on the voltage of the output. Then a bucking converter feeds a battery that sourced the original buck-boost. Lastly, an AC charger keeps the battery voltage constant. The completed system will likely have 5 microcontrollers.

So, I’ve taken the IVT contour from the last plot and tried to simulate some trackers. The typical tracker uses the Perturb-and-Observe (PO) algorithm. I’ve found that, given sufficiently fast response, a PO tracker will either track quite nicely, or just completely drift off.

I’m working on a modification to PO call Rapid Shadow Response (RSR). My initial version of RSR prevents the tracker from drifting off and improves the efficiency in this scenario by 1% over a good-tracking PO.

Got some initial plots for my shadow tracking simulation. 

There are some interesting results from this, but the plot is hard to understand and harder for me to explain. The overall result is that the maximum power point can move rapidly, oscillating between two points as a shadow passes over the car. 

I kinda took a break from, well, thinking.

But I’m back. At least a little.

I’m working on a pool table simulator. It’s kinda silly, but it’s something to keep me occupied.

An event-based timing system means that calculations are only needed when collisions occur, and only on the balls affected by the collision, so the simulation should be super fast.

After some research, I remembered that one of my biggest issues is the non-linearity of the rocket system. Thrust magnitude and thrust vectoring are multiplied in determining rocket rotation rate, and this makes everything very non-linear.

So! The standard way to deal with non-linear operation is to linearize the system; however, the rocket has many different regions of operation, so it’s impossible to linearize around just one and have good performance everywhere. So instead, I’ll implement something called Gain Scheduling, where I have several different controllers for different regions of operation.

https://youtu.be/QSN5TPKMJ24

I’m continuing iterations on the rocket controller, and it’s working pretty well now, but still not perfect. I think I remember some LQR methods from one of my classes, so I’ll try that next. For now, watch the rockets dance!

I’m investigating the effects of moving the rocket’s aerodynamic center. In the animation below, the black rocket has the aero center near the center of mass, while the red rocket has it much higher. Both have the same controller, which in this case is trying to make the rocket land at 0. (The controller isn’t perfectly tuned yet.)

(If you didn’t understand that, just say the black rocket has fins.)

I’m working on the controller for the 3-dof water rocket. It’s improving: I can now control the tilt of the rocket. Notice in the animation below how, despite the wind pushing the rocket over, it stays pointed upright. The black rocket has this control system, while the yellow rocket shows what happens without thrust vectoring.

Work continues on the inverter model, but my simulation seems to be messed up, and I can’t figure out how to make it work right. But with more work, I seems to be figuring this out slowly.

Did a bit of work with the Simulink Coder right now. It turns out the libraries supplied in the standard support package can’t take advantage of the STM32′s peripherals, but Waijung has some tools that let you do that.

I managed to connected the Discovery board’s accelerometer to make a sort of tilt sensor using the LEDs as feedback.

I’m taking a brief break from the water rocket to go back to my solar synchronous inverter design. Today I’m going to look in to component selection based on my design criteria for a 200 W inverter. I had some basic designs, but I can’t seem to find them... Looks like I’m starting over. Let’s dive in.

Here’s the rocket with a simple proportional rotation controller. From this, I’m observing what I was expected to be an issue the whole time: Lack of rotation control when there’s no thrust.

This won’t be that exciting.

Putting more thought into the water rocket. My entire control scheme relies on being able to control the thrust coming out of the rocket through 4 control axis: throttle, pitch, yaw, and roll. I want to avoid using fins for any of this.

What this means is I need a vectoring mechanism and a control scheme to go with it. I started with this source (http://digitalcommons.usu.edu/cgi/viewcontent.cgi?article=2221&context=etd) and used my imagination from there.