In this way, when running fastercnn, we need to change the original model’s 21 categories to our own number of categories. After the first modification, no error will be reported in the run, and after the second modification, an error will be reported as follows:
1 block: [0,0,0], thread: [16,0,0] assertion T & gt= 0 && amp; t < n_ Classes failed.
2 runtime error: CUDA runtime error (59): device side assert triggered
the main solutions on the Internet are as follows:

The reason for this problem is that there are tags in the training data that exceed the number of categories. For example, I set up a total of 8 classes, but if 9 appears in the tag in the training data, this error will be reported. So here’s the problem. There’s a trap. If the tag in the training data contains 0, the above error will also be reported. This is very weird. Generally, we start counting from 0, but in Python, the category labels below 0 have to report an error. So if the category label starts from 0, add 1 to all category labels.

Solution:
The first time I ran the program, I found that there were 16 categories (I deleted 4 categories, but I didn’t find them). After running the program, I found that there were four more categories, so I deleted these four categories. However, when I ran the program again, I reported the above error. The reason is that every time we
run the program, we have to delete the cache generated by the last run, because I didn’t delete it, so the program thought it was 16 categories, But only 12 categories are provided. So if you report this error, you can delete the cache and run it again