Peter's Engineering Reports. Processes, learning, and in general, making the world work better. Some call me an engineer, but really I'm just an artist with a 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’ve been a bit busy lately; somebody’s actually paying me to do engineering, so that’s taken priority. However, I have an ambitious plan to -take-over-the-world- I mean make a super advanced PV emulator that will physically simulate the currents and voltages from my simulation.
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.
I need a name for this... Solar Optimizer Test System SOTS. hm. Good enough. (I played a game called Sword of the Stars. I knew that acronym seemed familiar)
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.
There’s another 1% to be gained, however, so I’m going to keep working at it.
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.
Perfect tracking may be more difficult than I anticipated.
I have not been typing much lately. I've been moving, getting employed, and overall not very inspired. But, all that is out of the way and I have a new project. My idea is to build a new maximum power point tracker for the solar car. The objective of this device is to harness as much power from the car's solar panel as possible. The challenge here is that the solar panels electrical characteristics are continuously changing and must be tracked quickly to get as much power as possible. My device will improve on the tracking speed of our current trackers. I have a bunch of ideas, too many to list here, but I have an interest in starting place. I'm going to use my solar array simulator to replicate a time profile of a shadow moving over a solar array at 60 mph. Updates and hopefully cool animations to come. when I'm less busy.
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.
It’s crazy the geometry and algebra problems that are thrown at me when I do this sort of thing. I had just suddenly found myself needing to solve a fourth degree polynomial to find out when two moving balls collide with each other. Suddenly all the obscure math I learned seems worthwhile.
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.
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.
Now the goal is for the rocket to land where it started with zero lateral velocity.
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.
It may be that my system is too “stiff”, which I’m currently looking up the meaning of. It seems to have something to do with rapid changes in circuit parameters, which I solved by putting 50 nF Caps across the load resistors in my test circuit.
Still, it seems like every thing I do causes the output to be bonkers, and it really makes no sense. I’m starting to question the value of this tool.
I found that the FET models that I was using were causing issues, possibly because of the fast turn-on times. MOSFET gates have dynamics with time constants in the nanoseconds, so any meaningful simulation has to be extremely fast.
For my purposes, I can simulate much faster by replacing them with switches.
Here’s a shot of my simulation. It’s nearly lossless, but the output voltage isn’t quite reaching the levels I’m expecting. As always, the investigation will continue.
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.
Still not sure how I’m going to do complex programming with this tool, but considering what I can do with a couple blocks, I’m hoping that I’ll be able to do a lot with this.
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.
A solar inverter requires three main functions:
1. A DC-DC boost converter to increase the solar array voltage to the grid peak-to-peak voltage (168 V, minimum)
2. An isolation transformer to electrically isolate the solar array from the grid (so you don’t get electrocuted by touching the solar array)
3. The inverter itself to convert DC to AC.
The first two functions can be combined into a single stage, so we’re dealing with a minimum two-stage device, although three-stage devices are common.
Here’s the design I want to use:
Of course this won’t make much sense to a non-EE, so I won’t bother with a detailed explanation. Even for me, it’s been a while since I took power electronics, so I need to think this through.
The first stage is an isolated boost converter. Combined with a high transformer ratio, I can easily get from a 12 V array to 168 V. The two switches charge the transformer/inductor, alternating to keep the core from being saturated, and when both are off, a current is forced into the DC link.
(on a side note, I’ve had to add a lot of this terminology to chrome’s dictionary.)
The transformer is going to be the trickiest part to get right, and I might have to wind it manually to get the parameters I want.
Next post will look into the specific parts I want.
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.
To counter this, I have to add a term to increase thrust based on the rotation error term.
First off, I’m reconsidering my sensor choice. There are 6-axis accelerometers that use gyroscopes to measure rotational velocity. (could I use a gyroscope to stabilize my craft? nvm) For now I’ll stick with the 3 axis accelerometer+digital compass combo, but I’ll need to research to see which is better.
First off, I have to estimate my velocity, position, etc. from the 3-axis accelerometer and tilt sensor. This is easily done with integrator/differentiators. Sorta. Except the accelerometer has to be adjusted for its tilt, so I toss a rotation matrix in there. (seriously, this is like cooking. Missing a taste? Add x ingredient!)
I’m going to try controlling x position with the same sort of control strategy that I used to control height. This one will have a few more parameters, and will be compounded by varying thrust, so I’m not sure how well it will work out. I’ll neglect drag in my control scheme for now, on the thought that if the rocket is going sideways fast enough for drag to be a significant factor, I’ve probably completely lost control of the rocket. I’m also going to ignore direct lateral translation from thrust vectoring, for now. That may change later.
My calculations show that the x position is roughly proportional to the fourth integral of nozzle angle, assuming constant thrust and mass. That seems like a lot to me. So four PID controllers? Sure, why not. Life is PID.
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.
Basically, there are 3 things I can do to vector the thrust:
A: control the direction that the nozzle points (mechanically pointing the nozzle in a certain direction)
B: control the direction that the water flowing out goes (have fins or guides redirecting water flow)
C: have multiple nozzles pointing in different directions with individually controlled throttles.
No matter what scheme I do, I will need 4 servos so that all 4 controls are performed.
The paper I mentioned earliers uses B to control a rocket engine (or a jet? I didn’t really read it). B has the advantage of having the simplest control scheme. However, given the tiny size of my nozzles, I don’t think it’s feasible to stick fins in them.
A can’t be done by itself unless I find a way to “twist” the nozzle. Also, no matter the control scheme, I have to be able to control at least one throttle.
Given the small scale and desired simplicity of the mechanical design, I have two preferred options:
1. Have four nozzles, each with its own throttle control. Each nozzle would be angled slightly, all 90 degrees off from each other. By throttling the nozzles correctly, each control axis can be attained. Since there’s only one type of mechanism (i.e. a throttle), this is the simplest solution, but constantly-angled nozzles reduces efficiency.
2. Have two nozzles, each with throttle control and one axis of direction control. The axis for each nozzle is offset 90 degrees. Angling both nozzles leads to translational thrust, while angling just one gives spin. The control scheme might be a bit trickier on this one, but I think it would be doable.
I’ll do more research and see if there’s a better option that I’m not thinking of.
