5776E
Inferno Intelligence
Projection Spline
This is a project has been developed entirely from the ground up and introduces a novel approach to generating autonomous routes, exclusive to 5776E.
The projection spline technique is used to generate intricate pathways. The projection spline enables motion with curves while preserving top speed. It continually produces and adheres to a calculable and observable path. What sets projection spline apart is its adherence to a predetermined path.
No other teams, to our knowledge, have developed this technology. Projection spline was created from the ground up, and is designed to work with any vehicle capable of moving in at least two dimensions. Projection spline has undergone 6 iterations, although only the 5th and 6th have passed the desmos proof of concept check. Only the 6th iteration is working. The following are the three types of instances that projection spline must address in order to create any path.
Projection Spline Attempt 1 & 2
The first iteration of projection spline
attempted to create an exponential function, and use translations in order to morph it into a spline. This did not work because it was too chaotic of a system, and hard to control the behaviour we wanted. The slope would also change exponentially, making it extremely difficult to program paths with, It failed the desmos proof of concept because of this and was scrapped after failure to pass the proof of concept for around 2 weeks
Desmos link : https://www.desmos.com/calculator/fqzi8h0u8oDesmos explanation: The red dots were simply just there to help the regression, this desmos is fairly empty since it failed extremely quickly.
​
​
Iteration two:
The second iteration’s main idea was to create a series or circles to create a path. This was the iteration that introduced the idea of splining, which will be mentioned later on. This iteration failed similarly to the first iteration, it was too complicated to figure out when and where to create circles, and was scrapped after being unable to make progress on it for around 3​ weeks.
Desmos link: https://www.desmos.com/calculator/wci0uzm2rdFor this iteration, there are two circles, they each represented possible ranges for the circle to be in, you may have noticed the dotted line exists in this demos too and that is because I wanted to try doing something similar to help the regression.
The fourth iteration was a blend of iterations 3 and two, it attempted to gradually transition from the tangents of eliptices generated to create a path, however after some researching, I discovered that this is how pure pursuit works,
and that was something
different to what I was
attempting to achieve. I
never made a desmos for it
since it failed the research
and design phase. It
however did show the
promise behind gradually
changing slopes for
generation
Projection Spline Attempt 3 & 4
The third iteration of projection spline was completely different from the other two, other than the fact that it relied on regression like the other two, since that was the aspect that got the farthest. This iteration attempted to create a gradient of slopes from one line to another. This passed the first proof of concept, but failed the other two. In some cases, it does actually generate the curve, but in majority of them, it scrambles out and makes a chaotic series of points. I really like the idea of gradually changing slopes, but I strongly feel like this isn't the best way to do it. With some reworking it holds great potential.
Desmos link: https://www.desmos.com/calculator/nqb2wx434v
​
​
​
​
​
​
Projection Spline Attempt 5
​
This is the fifth iteration of projection spline, all previous iterations failed the desmos proof of concept checks, or were too complicated to continue. Some features from nearly all versions of projection spline still exist. This version uses a modified version of dijkstra's algorithm which is used to solve the traveling salesman problem*. The model of generating points utilises this in order to create a path. How it uses this will be expanded on in the following pages, but a vague overview for the process the generation follows. The generation will create a grid of points, and connect dots to form a vague path, then go back and refine the paths until it makes a smooth connection.
How It Works:
1) Generate a grid of spaced dots
-
Variable distance between each dotSpace between dot calculated dynamically
2) Starting from opposite
ends connect the dots
based on best fit,
create other options with
a weightage if there is
more than one option
​​
​​​​​​​​​​
3) Once the first iteration has been complete, delete all excess dots
-
Dynamically calculate excess dots based on the weightage
4) Create tighter dots
-
Spacing between dots calculated dynamically
5) repeat and tune final spacing
*Traveling to each point with the best path
Signature: Preetam Sai Muppidi| Witness signature: Bhavana MaramDate: 7/28/25${pageNumberOnly}
Projection Spline Diagram
​
Step 1: The program created the dots dynamically, by created rectangles at step value of 0.28. I manually created the black line, to demonstrate how the curve
should look. In the following
pages, the program will create
its own curve.
​
​
​
Step 2: After some careful debugging, and optimisation, the curve generated this. The patches are generated properly in this case, however there a few more issue created now.
​
​
The program begins by connecting
dots, alternating each end, and
meeting the path at the middle.
The program in this case only
generated one green connection
per end initially, working from
the ends to the middle ensures the
curve is properly generated, and
helps avoid the use of calculus
Projection Spline Diagram
Step 2 (Cont):
In this image, the program
has completed the curve,
the green indicated a great
option, while the yellow
indicated a okay option.
It is important to store both
of these for later steps. The
curve as quite close to the
desired generation, however
took a long time to generate
on a personal computer
making it worth questioning
if this can run on a vex vrc brain.
​
Stage 3:
At this stage, the program attempts to remove all unnecessary dots, for further refining, the code is not quite perfect yet, hence the patch in the top right, and over deletion in the middle of the path
Projection Spline Attempt 5
After just one iteration, the algorithm was able to produce a curve that closely approximated the desired curve. It also correctly generated suggestions that were properly weighted. This means after the first pass through the algorithm, it was already performing quite well. After just two more iterations, the algorithm achieved the target curve almost perfectly, with a theoretical error of only 0.02 feet or 0.25 inches between its curve and the ideal one.
However, there are some significant downsides with this algorithm's performance. Firstly, generating each curve requires intensive computation that takes around 2 seconds. That is quite slow. In addition, every curve generation uses up 500 GB of RAM, which is an enormous amount of memory. Even if optimizations were made, these resource demands pose a major flaw. The human brain does not have nearly enough processing power or memory to handle running this algorithm in real time. The time and RAM needed are just too high.
In summary, while the algorithm converges quickly and accurately to the right curve, its computational and memory requirements are impractical. It takes too much time and memory per curve for it to be easily usable for real-time applications or implementation in actual brains/neurons. The resource usage issues are likely unable to be reduced enough through standard optimizations to make this algorithm viable. New techniques would probably be needed to create a similar curve generation approach that is fast and memory-efficient enough.
Projection Spline Memory Issues & Solution
Issues:
This algorithm currently isnt optimised enough to run on a VEX brain, each “dot” takes up 4 bytes, and since the algorithm doesnt currently remove many dots, with the amount of dots being represented by the equation
Where D is the distance between the points and S is Scale, at the Scale of 10 (level of precision we need) and a distance of 10 there will be 338,350,000 total points created
Solution: The solution is fairly straightforward, by changing the type of data used to store the dots, we can reduce the memory for each dot from 4 bytes to 8 bits or, 1 byte; secondly starting with a lower S value will lead to less dots being created in total, this will make it more computationally intense at the end; however the trade off is worth the amount of computations can be optimised and spread over time.
Projection Spline Optimisation
One major way we could take advantage
of the freed up memory is to store all of the alternative branches the algorithm evaluates (shown as yellow lines in the diagram). Along with those branch options, we would store their calculated weightings.
By saving those branches and weights in memory, we can avoid re-calculating around half of the potential options every single iteration. Instead, we can look up previous work the algorithm has already done. This should drastically cut down on the computations required each time we want to generate or refine a curve.
In addition, having those branches stored will allow us to more accurately identify and remove extraneous/unneeded dots from the curve. We'll have more information to determine which dots can be deleted without negatively impacting the overall shape. Removing unnecessary dots will further reduce both the memory usage and number of calculations per iteration.
By incorporating this optimization of caching alternative branches and their weights, we can predict the algorithm will reach even better precision. Theoretically, we can expect a final error rate of around ±0.058 feet between the generated curve and desired curve after this improvement is added.
So in summary, storing the alternative branches explored by the algorithm allows us to skip redundant computations and simplify the curves more efficiently. This should both speed up and lower memory demands of the overall process, while still retaining an impressively high level of accuracy on the final iterative curve. We anticipate being able to reach precision in a few inch range.Signature: Preetam Sai Muppidi| Witness signature: Bhavana MaramDate: 8/12/25$
Projection Spline Attempt 5
The code currently uses dijkstra's algorithm which has a efficiency of O(elog(n)) which is very fast.
​
​
The algorithm is often used for problems such as, “the traveling salesman “ and is extremely similar to what we need, in its essence it finds the fastest path by finding the paths with the lowest total weightage(the numbers on the lines)
​
​
This is the heart of the code
and runs the actual algorithm,
this is only the generation and
not the weightage creation,
that algorithm is currently not
working
Projection Spline -- Final
This iteration of projection spline is the first iteration that works, this iteration is both fast, and consistent. This iteration is split into to main parts, firstly the generation, and secondly the controller. The generation is responsible for forming the path. The controller has the more difficult and complex task of ensuring the bot follows the path. The controller can be split further into the following steps, which will be explained in more detail in the following pages.
1. Create bounding lanes
2. Keep track of where the bot is
3. Find where the bot is versus where it should be
4. Update error values
5. Create a map (a map is a series of values that correspond to a different item)
6. Update the map.
7. Change the spline if needed
8. Respond to last spline conditions
Both the generator and controller utilise splines, as mentioned in the list above, and makes the algorithm extremely more powerful. Splines allow several paths to be joined together and allow the programmer to create complex paths easily. Essentially, Projection spline allows the program any path that can be drawn, the generation has to be able to handle this too, and the algorithm must be extremely optimised in order to run several splines together. To put it simply the algorithm must
​
1. Create a path
2. Group paths together
3. Handle splines
4. Follow the path
Path Generation
The algorithm generate points by slowly moving up a point between two lines. This is called Linear interpolation
​
By connecting the points created by 2 linear interpolations, the line created moves in a curved fashion. This animation I coded using Manim should help demonstrate the construction of the curve. The t value represent the percent of the line the point is at, so t=0.5 would be halfway through the line(if the video isn't working, go into present mode or press the pop out icon)
​
Linearly interpolating three lines, a curve is formed as demonstrated below. This is essentially gradually changing the slope, as mentioned from the iterations previously .
This generation is a staple for how the algorithm’s generation works, connecting several of these allows for extremely complex movement.
Path Generation cont.
​
By making a line formed between points P0 and P1 have the same angle as the initial angle of the bot( the angle of the bot when the function is called) and making the line formed between P2 and P3 the same angle as the terminal angle, and at the terminal point, we can generate a curve with the desired conditions. Then, we can calculate where to keep points P1 and P2 in order to form the curve.
To ensure that the math worked and to test it further, I had created a desmos which visually verifies and allows testing of this generationThe desmos is going to be on the next page, along with controls on how to use it for a better understanding of how the curve. I highly recommend exploring it and messing with it as it will provide a better understanding of its full potential.
​
The merging of two splines, is simple, and allows quick, easy, and fast. This allows for creation of complex paths. We are currently working on a controller algorithm that will allow for the bot to follow the paths created with
extreme accuracy, additionally,
we are also working on an
EfficientPathCreator object
which will automatically
generate the most efficient path,
the path with the highest
average speed, with the least
amount of distance.
Signature: Preetam Sai Muppidi| Witness signature: Bhavana MaramDate: 8/25/25${pageNumberOnly}
Projection Spline Desmos
I used desmos to check the math , since it makes it easier to check if it’s working, by programming it into a desmos first, it provides a visual proof of concept, and allows the debugging of the math, making it quicker and easier to develop. This also helps save time during meetings, since I can test most concepts on a desmos at home, instead of on physical bot, giving more time for build team to perfect the bot.
Under the Initial angle folder,
there is a slider named DI which will control the initial angle in degrees. (DI stands for degrees initial). Similarly under the target angle folder, there is a slader named DT which will control the terminal/target/final angle of the bot in degrees. The points labeled P0 and P3 are draggable and can be placed anywhere; other folders are pure math and do not take inputs. The dotted red line shows the initial angle of the bot, and the dotted black line shows the target final angle of the bot:
Demonstration
To avoid creating large chunks
of code, and creating messy unreadable, I created the code using OOP ( object oriented programing), allowing the path to be created and used simply.
The first three lines of the code
generates the code, and the
fourth line prints it for
debugging purposes. The curve
generated is shown on the right:
Effects
Why is this important?:This will allow the autonomous movement to be continuous, the entirety of autonomous could be run without ever stopping, while additionally making the movement extremely optimal allowing us to cram much more movement into the restricted 15 seconds autonomous and one minute for skills.Here is the code, transferred to an online source, if you want to mess around with it you can fork the repl
https://replit.com/@ArjunBedi/NoodleCurve
After the fetch-error function testing proof of concept worked, I have moved towards making a controller. Essentially a controller ensures that the bot goes to where its supposed to, a common example is PID. Since however this has linear and rotational movement, a standard PID will not work, and therefore a custom controller has to be made. There are two possible approaches to take for the controller. A lane based controller, which is significantly simpler, however more computationally intensive. The lane based controller works similar to how humans drive cars, if the object approaches too close to the edges of the lane, it will attempt to recenter. In this case the bot will always attempt to recenter, however its sensitivity is controlled by how far it is from the lane bounds. This should prevent the bot from overreacting and spamming turns and following a periodic function of over/under shooting towards the middle of the functionSignature: Preetam Sai Muppidi| Witness signature: Bhavana MaramDate: 10/3/25${pageNumberOnly}
Math For Generation
The main pro for the lane
approach is the simplicity. The math, while there is more math for the computer to do, it is a significantly more simple for a human to code and design. It should in theory be as effective as any other approach. We take the create path and add (sin(Ia), cos(Ia) ) to create an upper bound. In the code we then take the distance from the bot to the upper bound and lower bound, as the distance approaches 0, we increase the amount it turns, this accounts for distance error, and slope error, in non technical terms, if the bot isnt in the right place it will move towards the middle ( distance error) and if the bot isnt facing the right angle it will turn towards the correct angle (slope error). The errors are inversely proportional to the rate of turning.
The other possible approach is to make a predictive controller, without using lanes, this algorithm will fetch current distance and slope errors, as well as predicted distance and slope errors, this would then be processed in a mapping function, which maps the 4 errors provided from the fetch error function. The main problem with this, is that the math is significantly more complicated, however there's less overall math, however the mapping of the errors is a problem currently. The fetching of errors for this currently works as well, however decoding those errors is difficult as messing with position messes with the angle, and vise versa.
Splining
To allow for more complicated movement,
I have implemented motion chaining(paired with splining). Motion Chaining is essentially the combination of several paths to create one complicate path, the endpoint of one path becomes the starting point for another point, this is what makes projection spline so powerful and revolutionary, with motion chaining, the entire autonomous period for skills and matches alike can be one continuous path. The bot could complete its entire route without needing to stop. A path has a t value from 0-1 corresponding to the percentage of its point, as explained in the animation tab here. Each individual curve is called a spline, in an overall path
In the image below, the red curve is a spline, and the green is also a spline, both splines form an overall path, if there is only one curve, the curve is both the spline and the path.
We can differentiate splines by using the t value. If the t value is within [0,1] it must be from the red spline, but if its from [1,2] it must be from the green spline ( t=1 will be both, but this isnt an issue since the point is shared.)${pageNumberOnly}
Projection Spline Controller
Moving onto the controller, the part of the code that controls how the bot moves. To put it as simply as possible, the controller has two main jobs
1. Fetch where the bot should be
2. Tell the bot to move to where it should be
​
There is a lot of intricate math and logic behind how the controller works which will be explained shortly, to summarise, the controller is responsible for ensuring the bot follows the path.
Projection Spline Controller
How it Works:
The controller works by generating
bounding “lanes”, similar to driving
a car, the controller creates a left
bounding lane, and a right bounding
lane, it can tell its off center by
comparing the distance from the bot
to the left lane, and the distance from
the bot and the right lane. This is
extremely similar to how people
drive cars, ride bikes, and walk.
This approach solves a lot of issues,
but adds more computations for the
brain.
Controller Cont
The code is structured using Object Oriented Programming, and this allows the paths to be defined quickly and efficiently. There are classes for the following , Point, Path, PathGroup, PathController. The reason for them being split like this, is because it makes it easier for the programmer to code their route, but it also controls how the path works, making it less likely to break , The Point class is simply to define movement more easily by using a coordinate system. This is already common in a lot of other team’s code, and will help transition other teams into Noodle cuve. The Path class allows for programmers to define an individual spline, for several splines, the PathGroup class is used, which holds a series of Paths, defined by the programmer, Lastly the PathController class allows for the running of the pathgroup, simply typing “Path.runPath();”. This allows for the programmer to code cleanly and simply,without having to learn the how’s and why’s of projection spline, it greatly lowers the complexity of the coding, making it easier and more accessible to more teams. This architecture also allows projection spline to run on any device which can move in at least 2 dimensions. The controller keeps track of the current spline, and enters a PID on the last spline, to ensure the bot stops at the right point.