I’m a big fan of Django and Go as well but the only thing in the Go ecosystem that I’ve found that comes close is beego: https://github.com/beego/beego
But it still needs to mature quite a bit before I’d be comfortable saying it’s anywhere near Django or Rails
I found Pagoda required me to juggle too many things that were only loosely coupled together.
GoBuffalo was great but as soon as I started using, it got archived :’)
Now I default to beego. It isn’t as batteries included as a rails or django app, but there’s enough there that I don’t have to write as much boilerplate as with only the stdlib.
ScratchPixel's articles are some of the best mathmatical breakdowns of rendering I've seen all these years, along with perfect diagrams, charts, and formula noations. Defiitely worth its weight in gold if you approach topics from a logics/proof standpoint.
But man, I feel I was waiting for that path tracing article for 8 years now? It's not even on their recent roadmap. Treat the unreleased sections as wishlists instead of a "upcoming" section.
>Though admittedly it is a bit chaotically organized.
looks like they completely revamped the website (and their roadmap seemed focused on revamping existing articles over making new ones). The beginners section now seems to make enough sense if you were following a college raytracing course. The other sporadic articles are pushed farther down to prevent confusion.
agreed. It's interesting that Go has a lot of the ground work set up (built-in prod server, etc.) but no framework has really taken off. And the dev productivity when compared to something like Django is painfully slow...
Just watched, and yes this is a very good explanation. My intro to PID controllers was when writing AI vehicle steering for video games. I wasn’t taught about PID controllers in my CS degrees, so I started naively with what I would later learn is a P controller, and then got really surprised when lowering the gain turned into larger error. Like trying to smooth out the steering makes the problem worse, it was surprising to me. I told a very smart guy near me what I’d learned and he was like, “Oh yeah, you just need a PID controller”.
I used to design PID process controllers in industry. In watching this vid I realized one reason that designing a self-driving car is so difficult. Toward the end, in the process control diagram, he has [Vehicle] as the controlled process. This reminds me of the old math joke about "assume a spherical cow". The difficulty with a self-driving car is that it isn't just the vehicle that has to be controlled but [Vehicle + Current Road] so the controlled process is not just difficult to model but that it is changing all the time and sometimes rapidly.
I am surprised to hear about a PD controller though. In my testing, a PI controller seemed to behave much better than a PD controller. In my research, it seemed a common strategy to drop the D-component completely but I did not see the suggestion to drop the I-component.
In terms of the theoretical guarantees, a PD controller is (nearly) always stable and pretty easy to critically damp. However, if the set point is moving with a nonzero velocity or there is some load, then the PD controller will not converge. A PI and a PID controller can converge even if the target is moving.
Practically speaking, I would recommend encoding as much model information as possible before pulling out the I term: for instance, if you know the velocity of your tracked object and assume an intertidal model, you can just include some of that data in your feed forward rather than the controller, which simplifies things greatly.
You can use your intuition in the sense that if what you measure just has a constant error without an integrator in the loop that error will never be closed. Think about a motion control system with a proportional gain where you are pushing the actuator with your hand away from the current position. The proportional gain will apply a force against your push but generally that will leave some residual error in steady state. This is where the integrator comes in. And I agree with the parent that I've mostly seen the D term dropped from controllers, definitely with motion control, though sometimes there are other weird components or multiple loops which may end up having a similar effect.
One thing that I think is often confused the matter is that P, I, and D all relate to what you measure and what you're controlling. E.g. you might measure velocity or position in a motion control system, and generally your output is going to be current. In a temperature control system your measurement would be temperature and your output is likely going to be current (which influences acceleration, not position or velocity). Ofcourse velocity being the derivative of position means that the meaning of "P" is different. I haven't done PID in a long while but I've always used to ground myself in motion control systems to get a sense what I want to put the loop over.
EDIT: E.g. IIRC it's common in motion control to have a PI loop over the position error and an additional proportional controller over the velocity (and then filters, feed-forward and a bunch of other components ;) ).
> Practically speaking, I would recommend encoding as much model information as possible before pulling out the I term
I was referring to that part. Ie: if I know more abouty system, how do I include that in my control loop.
E.g. if I want to control the temperature of a room, I might have an idea how much energy is lost due to the gradient between inside and outside temperatures.
I would assume that a PID controller is still suitable for that, but I have never seen novice level resources on that.
I think the parent is saying something along the lines of "if you can look at your problem and determine there's no need for an integrator, or you can take the need out using feed forward, then you can remove the integrator" (or set your integral gain to zero). Keep in mind though the integral gain isn't simply acting to take out constant error, it changes the transfer function of the loop.
If you have a mathematical model for the thing you're controlling you can derive the PID parameters using that model. That's very rarely the case though and even with a model reality almost always differs.
The PID controller doesn't "care" about your knowledge. What it does "care" about is how the system responds to the control signal, specifically with linear systems the gain and phase for the different frequencies. If you're tuning a PID using some heuristics then the process of tuning includes the response of the system you're controlling. So at least intuitively I don't see an easy way to take some partial knowledge of the system and incorporate it into the tuning process. Maybe someone with experience can say something like "using less proportional gain and more integral gain results in better <something> for temperature control systems where there's a lot of energy loss due to gradient" but otherwise there's no easy way to tell IMO. If the integrator doesn't help you're probably going to discover that in the process of tuning anyways.
I think this knowledge is more useful in the context of a feed forward, i.e. if you have a good model of how your system behaves and you incorporate it into the feed forward part of your control loop then the residual error is going to be much smaller and you'll get better performance.
I used a PD controller for a specific application where we were trying to maintain a specific temperature in the future, and cared more about the trajectory of the temperature over time to reach the goal. We didn’t much care for the integration of that temperature since that wasn’t important in this particular case. An integration factor would actually wind up the rate of temperature change too much!
Integral windup is the term for this issue, there's a few ways to deal with the windup if you need to keep the integral component (e.g. for tracking a moving set point, or to overcome a stable error).
https://en.wikipedia.org/wiki/Integral_windup
How do you decide whether a side project/idea is worth pursuing? You mentioned in another comment that you don’t “do the MVP stuff” and go full blown from the beginning. That seems like a big time sink without a rigorous way of validating whether users want what you’re building.
Yes it is a time sink and I can't claim having a specific methodology but if you look at all the conflicting theories, literature and endless blog posts that have been written about validation, you might as well just trust your gut.
My amateurish approach is to jot down every idea in a single line of a text file, then walk away. If the same idea or topic strikes me again, I give it a separate text file and write some copy that might go on the product page, together with links to related stuff, screenshots, etc. Then, after another few weeks and only if I still believe in the idea I come up with more details, perhaps do some light coding, brand ideas, register domains, etc. Then (You guessed it), I wait another few weeks or even months and if it passes my still-relevant check I start working on it on the side of my existing, well, side project. The challenge these days is when to pull the plug or go all-in since the market, interests and attention shifts so quickly that it's tough to adapt without losing temper. Doesn't get easier as you get I older.
14.9% a year and a half ago and now 72.5%
reply