#关于2018年东南大学Robomaster算法组工作的总结

At the time of writing, I was one of the heads of the Super Nova Team algorithm group under the Robomaster competition at the Southeast University Robotics Club (this word is long written). The Super Nova team officially ended the Central Division on May 19, 2018 and was eligible for the second prize and the pre-finals resurrection, which will be in Shenzhen after two months. In this competition, our work has all sorts of inferior meanings, is worth the record and the reflection. This paper summarizes the various achievements and problems encountered in the development process of the algorithm group in the present position.

Project History

I joined the algorithm group a year ago, the beginning of the last semester. As a result of various personnel changes, the current leader Hby classmate is six months ago, the project actually just started at that time. The case of our algorithm group was that the entire team had a short history of the game, and that it was the beginning of last year's match, when the old people didn't leave any experience before exiting, and some code was hard to reuse. The work of the algorithm group is mainly focused on the visual aspects of the competition organizer's emphasis on DJI. For example, a very powerful deity will take a short period of time in accordance with the instructions of the digital tube to hit a nine lattice of handwritten numbers, time is very limited, only by the machine to complete, or this year's game to join the Automatic Sentinel robot, only through the built-in program control operation.

At that time, we were not clear about the project, but proposed to develop the local robot automatic identification algorithm and defense strategy for the Sentinel, for the infantry loading deck identification and tracking, small character hit and so on. At that time, there was me and Hby and one of the three junior students who later withdrew, as well as the three Hby. Feeling in this year near from the beginning of the scene, Hby proposed to two points, one is to put the work into the hands of the practiced hand, to ensure the inheritance of the algorithm group work, one is to write a highly modular, reusable library, the latter is he asked me to come in the reason.

And the difficulty of the algorithm is not considered, yes, these visual algorithms are not difficult, at least in the scientific research community is not enough entry-level things.

To later happened personnel changes, funding shortages and so on, but our algorithm development is very smooth, because the algorithm is very simple, to a few days before the game, the algorithm is basically to the point of availability, can be loaded. Just then, the problems in our project were exposed. In the last days before the provincial race, we stayed up all night, I and Hby overnight four days, and finally did not let it play a role in the car, until today, that is, the last day of the game, the self-aiming function is just on the line, has no help.

What happened?

There are too many things going on in this project, lookers, I need 1.1 points to clarify the factors that cause the progress to be abnormal.

The first is what happens in the last few days, which is what happens when the test is done after the algorithm is developed.

1. Upper and lower machine interaction is not guaranteed
2. Problems with code porting
3. Problems on the new system

The first thing that took away my day's time, we communicate between the upper and lower machine through serial port, send the information according to the agreed protocol. I have listed the causes of these things below.

Hardware not clear

Since the use of serial communication, it is natural to connect the serial line, unfortunately, I do not know the hardware connection, debugging hardware on the code before you need to ensure that the hardware connection is correct, even if it takes more time is also worthwhile . In fact, I just because the line in a number of debugging sometimes plug in reverse, manifold the current noise as the next machine sent information, nature is scratching the head to find out the problem.

Problems with the underlying protocol authoring

The underlying protocol is actually problematic. Due to the existence of align, the bottom layer in the calculation of a frame length less than a few lengths, when I was disturbed by the noise, I first realized the problem and with the electronic control confirmed that the problem was modified. Why is the agreement not tested beforehand? Because the previous version of the test has been updated, the writer felt that he did not change how much is not measured. Why hasn't this problem been seen before? The previous protocol was written by the algorithm group last year, and they know the problem. This is actually a matter of joint control.

There is no unified development environment

The problem with code porting is caused by the non-uniformity of the development environment. In fact, Hby is a strong vs supporter because there are many handy plugins for debugging vision algorithms in VS, and I am the only one in the group who is familiar with the Linux environment. Our code finally runs on the manifold of the Linux arm environment, and we can develop it trophyless-platform, library version, language standard, compiler are different.

It is my responsibility, as the only person familiar with Linux programming, to be reminded of the difficulty of porting the code at the very beginning. Otherwise, I should make sure that these things are consistent, give players the necessary training, deploy simple software for them, or simply use a simulator or cross-compiling technology to solve it. Can only say that I have no experience, this matter is a lesson, a wake-up call. The code must be guaranteed to run, and it's hard to guarantee before testing, so it's important to test in real-world situations.

Problem with code synchronization

This needs to be seen in conjunction with the previous point. We used git to manage the code and work together, and hosted a remote repository on the code cloud. This is a good thing, however, because all personnel can not guarantee the familiarity of git, so after leaving the graphical interface after the operation becomes very difficult, so that there is git but also to manually synchronize, or the entire team stopped working, only to wait for a person code to complete the synchronization success, and because of the lack of awareness, People often forget that syncing happens every time it's a disaster . These things slowed the progress of the project greatly, but in any case, nothing was done in one night. It was a ugly.

Project centrality is too strong

"I am the only person who has a thorough understanding of this project,"----Hby

Yes, also in the growth of the learning brother need to Hby, know that the project has been written about the situation of the people only Hby, know what to do next is only him alone. In this case, he actually became this should be parallel project in the mutex lock, so in the early days, in the late everyone together in the run-in time, so it will actually wasting the entire team of manpower, commonly known as the whole group to see the programmer doing nothing.

Problems on the new system

This problem is not the problem of code, but the problem of the system itself. On manifold Embedded Linux systems, there are a lot of problems that will not appear on Windows. For example, its above OPENCV must use the V4L Library first processing to open the camera, directly call Videocapture class will be unable to open the problem, and, call V4L OPENCV program must exit normally, and can not use crtl-c signal exit, Because the system does not automatically recycle the camera resources, multiple crtl-c can cause the camera to not turn on again. In addition, C + + does not guarantee that operations that exit the main function except normal return call destructors.

My current solution is to capture the SIGINT signal, let it change a global variable, and the main function polls the variable and exits.

In addition, similar to the need to solve the dynamic library links and other system-related issues, developers lack the ability to solve problems independently, may be found Baidu can not be resolved.

It's going to be a technology drain.

By the end of the last few days after the first version of the deck tracking, we found that the control performance is very poor: The wind is very bad.

A lot of debugging, only to find that this is a long time ago has been resolved a problem, but with the update of the Protocol, the electronic control over there has been a technology drain, the problem has come back-unfortunately, and wasted a lot of time.

The more fundamental reason?

What caused these trivial problems to occur? There are certainly reasons why developers and managers have no experience, and there are other reasons.

The first is that the whole team is progressing too slowly. Yes, until the last few days the car was barely moving, and it was far from done. So until the end we really had a chance to debug, so the problem was too late to be exposed.

The second is the shortage of funds. Hby, who spent an afternoon one months ago transplanting his own program to TX2, and made an already-used armor plate tracker, he thought a lot of things were simple. However, because of the problem of money, we can only use the manifold of the second gear. We have overlooked this point.

This is ultimately a matter of project planning. Although know what to do, but the whole project planning is problematic, this is actually the management staff have no experience, time planning is very important .

So what is the lesson learned?

As far as I am concerned, the lesson is that in doing projects, you need to have a clear understanding of the target platform, a detailed survey of the technologies used, and the ability to use them skillfully, before the target platform for development needs to be determined.

If I were to redo the project, I would have to confirm the team's funding, identify the end-use platform, and then confirm the library version and standards used to ensure that these things are compatible with the target platform. Run all the programs go out on the manifold, and it's best to ask everyone to run their own code on Linux. Before that, I needed to give the players Linux training to teach them the knowledge of make cmake shell script compiler link Dynamic library static library and so on. If time is not enough for me to teach, then I will provide them with the environment as convenient as possible.

Then tell Hby that the project's progress needs to be carefully designed.

Then ensure the stability of the underlying interface, the more the lower the more the need for high-quality early completion, rather than the opposite.

#关于2018年东南大学Robomaster算法组工作的总结