Introduction
Having a background as a single programmer in the FTC (First Tech Challenge) competition, our team's lead programmer quickly became interested in the motion planning problem (for wheeled robots). There is a very popular open-source library used by 80% of the teams to write autonomous routines because it incorporates a complicated infrastructure, lots of functionalities through high level math and a user-friendly interface.
This package (roadrunner) installs locally on the Control Hub (main board) besides the robot code, enabling trajectory generation. They also have two separate tools: a simulator and a dashboard (connecting to the CH's network on the browser). The code is mostly written in Kotlin but has Java parts too.
Entering the FLL (First Lego League) competition, we saw that 90% of teams use block coding, which limits the potential complexity of the code written. This is an issue, especially because consistency and precision are very hard to achieve. Autonomous programming being the only allowed way to move the robot, those are key aspects for robots in this competition. We noticed those inconsistencies at all the teams at the Romanian Nationals, as most of the teams had drastically different scores from one match to another, running the same code (including our team).
Syntax programming is so rare in this competition that you can't even find examples online, so most of the teams don't even try using Python as their programming language. Keep in mind that **this competition is intended for children between the ages of 9 and 16 **. For them, it's impossible to learn advanced coding with no intuitive resources online.
Lots of motion profiling libraries exist online on GitHub, but there isn't one specifically designed for FLL.
We want to revolutionize coding for this competition, so we developed a plan.
This is where we came in with PythFinder!
- it's the first ever FLL motion profiling library out there \o/ ;
- unlike roadrunner, this library doesn't install directly on the robot, resulting in faster calculations ;
- the simulator, trajectory builder, and generator are all packaged in one single library while maintaining a friendly look similar to roadrunner's ;
- the core logic behind the implementation is completely different (which will be covered in the following sections) ;
- allows the user to manually drive the robot on the simulator with a controller ;
- generates all necessary trajectory values into a '.txt' file to be uploaded to the robot (an innovative solution that wasn't used until our library, from what we've seen) ;
- allows the user to change the interface without changing the code, just from the interface menu ;
- allows graph visualization of the velocity and acceleration for better understanding of the robot's behavior ;
This is just the beginning of our library. We did 'a bit of everything' to show a proof of concept. Our future plans resume to gradual improvements in each area of the simulator (interface, menu, syntax, trajectory generation etc.), by us and others wanting to help. Abstraction and letting room for improvements are essential practices for achieving a continuous progress. Expect us to release little improved-versions once in a while. A feedback section is also open to signal any issues or wanted implementations so we know how to address them.
We settled on Python for this project, as it's the main language LEGO® bricks supports. For easier display of the robot, we used the most popular Python game-maker, pygame. It already had the core functionalities we needed (photo imports/exports, keyboard + controller support, and, of course, the actual display window itself). The initial thoughts were to upload all this code onto the brick, but because of its old processor and compatibility with python, it was a better idea to separate this tool from the actual robot.
Matplotlib was an addition to help the user visualize numerical values in a more intuitive way.
We don't expect our library to be perfect; that's why we took into account possible errors and tried to address them before they appeared. With all those in mind, we still could've missed some edge cases, knowing it's a user-input based library.
For known incorrect inputs, we alert the user through custom exceptions.
We also implemented feedback on each part of the code compilation through 'print' messages. Some of them are easter eggs, but most of them inform the user about some action being taken. On occasions we can verify if an output isn't correct, we'll announce to the user that a bug has been found and thus report it to us.
As we expect some to appear, unknown or unidentified errors should be given as feedback to us. We'll adress the issue in the least time possible! ;)
Memory leaks, battery power, or any other resource shouldn't be abused by the library, thanks to its simplicity and minimal resource requirements. Limitations to the user were also made in this scope to further lower the chance of something really bad happening. This script can easily run in the background of any other program your CPU supports.
The only legal owner of the PyPi project is the lead programmer of Omega Core; no security issues will arise unexpectedly. The project has gone through PyPi's antivirus protocol when first uploaded to the platform, so it's safe for everyone to use.
We covered the basic functionalities provided by PythFinder in our 'README.md' file, but we still have some tricks up our sleeves.
The scope of this documentation is to explain in detail each part of our code, discussing both the actual implementation and the logic behind it, because, while building these roadrunner-inspired features, we couldn't find any research online explaining the process necessary to accomplish such a complex trajectory generator.
In the next few pages, we'll take each component piece by piece.
