Write in front:
I am a member of the electronic control group of the Robot Association of a non-African university. I am a sophomore in computer science. When competing, I mainly do electronic control and occasionally do some visual work. It seems that I am the only one in the electronic control group of the association who majors in computer science, and most of the other students are in automation and electrical fields.
Our electronic control association mainly does two jobs, one is to draw PCBs, and the other is to write control codes. I know nothing about the former. I gave up after learning PCB wiring (it was too difficult to draw). My main job is to write code. For non-computer major association colleagues, some people have a strong foundation in hardware but only code. . Well, that is to say, if your program is written healthily, it will save a lot of debugging time .
Electronic control is written in C language. Many engineering majors in our school take it in their freshman year. They feel that it is very simple to learn in class. Then they start to get confused when they learn the 32 standard library, and they get even more confused when they adjust the car by themselves. Some seniors in our association think that C language training is not very important and that we should focus on the learning of microcontrollers. But I think C language is also very important. As I said just now: If your program is written in a healthy way, it will save a lot of debugging time .
Therefore, in this article, I will use my professional knowledge from the perspective of a computer major student to give some suggestions and experiences to students in the electronic control group who are not majoring in CS and have relatively weak programming foundation. This is completely based on the opinions of one family, with average ability and limited level. I hope the bosses will criticize and correct me.
1 Low program coupling
When there is a problem with your code, the solution process is divided into two steps: 1. Discover the problem; 2. Solve the problem;
From my personal experience, the first step is crucial . If you don't have a good positioning of the problem, then how can you talk about solving the problem? When you solve the so-called problem, you may treat the symptoms but not the root cause, and create more problems at the same time. In the end, like the joke goes, you write a bunch of bugs and it just works.
However, how to locate problems efficiently requires that your code be written in a way that is easy to debug . How to make debugging easy requires that your code has low coupling (the sophomore water course UML finally came into play)
For example, this is a real example: A buddy couldn't adjust the wheel PID well. After adjusting it for a few days, he found that the encoder line had poor contact.
You might as well imagine how you would analyze it if you encountered this problem. There is a problem with pid, it is nothing more than three situations
First, there is a problem with the pid program and the formula is written incorrectly;
Second, there is a problem with the encoder and the output value is incorrect;
Third, there is something wrong with the motor PWM, the waveform is wrong or reversed;
That buddy couldn't find the problem, because his pid program was encapsulated with a function, and all the underlying libraries were adjusted, and the writing was very confusing.
If he encapsulates the pwm program and the encoder program, and then calls these two functions in the pid program, after a problem occurs, debug the pwm and encoder programs separately. If there is no problem, it is a pid problem. If it occurs If the problem is identified, then it is their own problem. In this way, the problem can be well positioned and solved.
This way of writing function distribution is called low coupling . Your program is composed of modules, piece by piece, and can be replaced and debugged in time. (Of course, high coupling is not a bad thing. Highly coupled programs are more efficient and save the time of calling, but I still don’t recommend it. I think as far as college competitions are concerned, ease of debugging > efficiency)
And my own example. I am driving a smart car, and the motor driver of our group was changed midway (it was originally a single-channel pwm+flag, but changed to a dual-channel pwm). I only changed the pwm encapsulation function. All the above programs have not been changed, and my code still runs. It's fine, there is no need to change the pid parameter.
-------------------------------------------------- Dividing line------------------------------------------------ ----------
Go to bed and write again when you have time. .
2023/3/25