SETTINGS PANEL!

When using this project there can be a lot of issues such as bad lighting, no accessible black on white resources, etc. And I was actually inspired to add this when I was walking around school and I saw that most of the numbers in places were white numbers on a dark background. So I thought why not make this program be able to read those?

This took me surprising not as long as I thought it would take. I spend a quick 20-30 minutes making a rough draft, then I did the typescript, and in the end I styled it and tested it out and 3 hours is great honestly by my standards.

Signing off,
Ash-ioL

Switched to a better deployment

My ship had changes requested to it to not deploy the project on services like render that go to sleep and take a minute to wake up.

I switched to vercel’s serverless function which doesn’t have that issue. I had to swap out my requirements for packages to more lightweight versions of them in order to make it compatible for this deployment. It took a couple of tinkering.

Signing off,
Ashwath Arasuraj Sankar

lots of tuning & mobile support

I spend the majority of my time in the preprocessing code trying to get it to work. I tried things like finding contours, adaptive threshold, and other things but I ended up just using thresh otsu and multiplying that threshold value by something near 2 and it ended up working out.

After that I was setting up cors allowed origins with the production domain, and I went through all my css and made sure its responsive and supports mobile devices.

My biggest challenge was honestly finding time to do this. I’m taking a heavy classload this year and with other commitments I could only squeeze out like an hour of my afternoon on this every day and I worked on it mostly in class and during lunch. But however it bugged me so much (and still does) of how fragile this model is to shadows and such, although I made it less impactful.

Signing off,
Ash-ioL

Loading Screen Complete and Results Screen Layout Complete

I created a simple loading screen to transition into the final result after the image is uploaded. For the loading screen I just put the image they uploaded and underneath it the name of the image they uploaded. For the animated ray, I used a parent container to remove overflow and a pseudo-element to have the moving ray. The biggest challenge was messing around with the perfect amounts of blur, opacity, ray width, and direction to make it look put together.

I also started working on the results UI. It displays the preprocessed image, prediction, confidence score, and some information about the pipeline behind this project. Since I am done with the UI, now I just need to use the fetch api in Javascript to get the response and feed it into the results. And some other polishing.

In the backend, I still need to fix the preprocessing bug but I figured it would be easier to debug if I finish the frontend first since I can use it as a tool to take a picture and see what it gives.

Added a Footer and Some Logos

So I added a footer in the bottom with social links and in the top I added a logo, along with a big transparent one in the background. I also made the file input button a html file input tag so it utilizes the file inputting and camera use. I’ve really just been adding stuff and not worrying too much about organization. I’m hoping I’ll be done with the project before that impacts me.

Signing off,
Ash-ioL

Webpage diagrams and icons added

I generated the svgs for the icons and the diagrams with AI. I manually did the colors and layout. Next I am going to make it responsive and compatible with phones. After that, I need to fix an issue with the preprocessing of the image in the backend.

Testing it out was kind of a hassle with taking a picture, uploading it to drive, using my laptop to send it to the model. But since I tested it out, I was able to know that something was wrong.

Backend Complete

I completed the API part of the project. It allows users send a post request with the image and gives the prediction as the response.

I also have it deployed publicly.

I spent a huge amount of time in the preprocessing step for the image since there were a lot of steps involved and lots of places for things to go wrong.

Started testing with a frontend to make sure it works but I haven’t added any elements to it yet.

Signing off,
Ash-ioL

Organization and change of plans

Completed:

• I learned ES Modules a little bit and I organized my 600 line javascript file into 4 different files, increasing the scalability and just making it easier to work with.
• I also scrapped the section on the page that was reserved for settings, and I decided to add a separate panel that pops in and out to save space and put more focus on the central grid.

Challenges:

• I spent like an hour or 2 finding small things that were out of scope or dealing with named and default exports.
• Some css shenanigans figuring out why this does that or if I need this etc.

Context:

So I’ve been busy for a while and I’m just getting back to working on this project after like 4 months or maybe more. I’ve probably spend like 30 unlogged hours on this project before stardance which mostly involved designing assets, working with grid scaling, learning canvas, and fixing the robot logic and input, that kind of base stuff. After that I need to like make it user interactive with styled buttons and layout and stuff so people can build their own obstacles, resize the grid, and maybe even use some pathfinding algorithms.

So yea, that’s why instead of doing something that involves actually using my previously coded code, I decided to do organization today to ease in to it.

Signing off,
Ash-ioL

Ready for ACTION!

The robot is now at a functional state with lots of new automation and is ready to compete in an offseason competition.

It certainly took a lot of time, especially with the abundant testing, and fixing some confusing bugs.

Completed:

• Added manual aim adjustment
• Created and saved elastic dashboard

Challenges:

• There was a bug caused by autonomous path filtering that I helped my team fix. It was hard to find what was causing it and even now I still don’t know why that line was causing a problem.
• Fixed a bug where the automatic shooting was actually not shooting when everything is ready, but was shooting instantly.

Moving forward:

I’m gonna keep working on this and improving it for our next offseason competition instead of shipping it already. So the plans are:

• Automatically detect when we’re intaking, shooting, or a certain spot is facing resistance with stator current thresholds.
• Improve moving while shooting accuracy.
• Try some object detection, 3d simulation, and vision sim.

Signing off,
Ash-ioL

Shipping!

With this robot’s demo purpose out of the way and a bunch of working features developed in it, I think it’s a good closing point for this project, for now.

Changes / features added:

• Collision disabling
• Robot voltage and other useful loggin
• Added a boundaries system to kepe the robot in a rectangle boundary
• Added a precise 2 point angle command to make the robot alignment easy to reset the boundary
• Boundary override
• Kid mode to disable admin buttons

Challenges:

• Pigeon problems with the real robot. I checked everything on my side with yagsl and stuff, and I cna read values from the imu. Its just that yagsl isnt able to get it somehow so ive created like some tests to see if i can manually put in the value. But it would’ve been nice if it worked in a straightforward way.
• Honestly to be super real, shipping this is gonna be a bit hard. since this isnt like a simple project you can try in your browser, and this isnt entirely my creation, I’m gonna try my best to only share what ive implemented. I’ll try to make a good demo video without boring yall out or confusing yall.

Signing off,
Ash-ioL

Completed!

Wow… I got carried away. I know in my previous devlog I said I would finish this project the day after it, but as you can see its been like over a month now. But I guess things just got in the way like robotics, summer classes, and can’t forget about watching tv. Anyways… lets start the devlog.

Features added:

• Time Selection Option: So now instead of just picking the date which you want the time from, you can be extra precise and pick to the last minute.
• Pause Button: If you want to see the time in a specific metric, you no longer have ot wait for the animation to cycle back. You can just hit the pause button to freeze what metric it shows (like seconds, minutes, years, etc).

And considering my 1 month gap in web dev, I’m incredibly surprised that I managed to get this done in under 2 hours. I guess it was mainly the simplicity of the pause button. And the whole thing went pretty smoothly but I guess that’s just luck.

Message

The whole point of this update, is to prove that I value your reviews. I thank you Stardance shipwrights for the nice detailed reviews which helped elevate my project to whole ’nother level.

Signing off,
Ash-ioL

Entering the last week before offseason comp

Trying to make the robot as sophisticated and automated as possible on the controls side here before the offseason event. I’ve haven’t really been working on any other coding project other than this.

Changes/Improvements:

• Replaced the robot’s default position to x-lock instead of idle. X-lock is a wheel position for swerves that makes the robot hard to move.
• Changed the polar magnitude limiter to a acceleration limiter which lets us tune things more directly and easily.
• Developed a list of things the robot should do (like actions to bind to the controller) and implemented them in the code. Many are automated and simple to use, reducing operator error.
• Fixed some improper commands that were causing issues by not being interrupted properly.
• Predictive targetting: picks target based on where teh robot WILL be rather than where it is.
• Experimented with a jerk limit, hoping it’ll cause an s curve but it ended up causing some weird oscillations since it was reactive and not predictive.
• Logged the state for each subsystem.

To do:

• Improving our autonomous routines.
• Add a manual adjustment for targets.

Signing off,
Ash-ioL

Smoother Tracking, Quicker Maneuvers, Automated Sequences

It’s been a week or two since my last devlog. I’ve been working on this and helping getting it ready with my team for our next offseason competition, which is probably when I’ll do my first ship for my contributions to this project.

Features:

• Improved aiming while shooting by using the interpolated mean to average the robot’s velocity to make it less impacted by randomness.
• Smart controller detectoin to see how many controllers your using and binds the functions appropriately.
• More efficient bump crossing with the robot now snapping to the nearest 45 degrees rather than just a fixed one.
• Improved compatibility in my customjoystick for simulation.
• Reduced the logging overhead by removing unecessary stuff that’s only needed in simulation.
• Made it classify aiming as not idle so that it aims when standing still.

I also spent time adding logging for these features and making sure the code is neat and readable as possible, while double checking and testing in simulation a lot. I also fixed a couple small bugs here and there.

Tha challenges were mainly not that like confusing as it is sometimes. The big thing was like testing and navigating the code which took up the most time. But really this is all worth it because its so nice to see your code just come to life on a real robot.

Signing off,
Ash-ioL

Started, Scrambled Something Up, Completed

I initially thought of making this for my friend’s birthday. But I realized that it would be risky since it could easily break when put in a bag if dropped or swung around, and it would be hard to carry around for him. It would also need specific directions to use it the way I built it. So to save him the hassle, I decided to keep it and just give him a gift card.

Features:

• Tall body - this wasn’t intended, I sort of just started building and it came out like this.
• A switch with a rubber band lock - this needed some really good adjustment so it isn’t too hard to activate and isn’t too easy to activate.
• A battery holder - it took me some time to brainstorm and come up with the idea to add a rubber band lock
• A door to access the battery with a rubber band lock
• A plastic propellor - I also considered cardboard and badminton feathers but I thought that plastic would meet in the middle and be simple but also lightweight.

Honestly, rubber bands and hot glue really carried this and help me so much.

Challenges

• Time constraint: since this originally intended for my friend’s birthday, it forced me to lock in and finish quick so this was nice.
• Switch headaches: a lot of the times when the fan wouldn’t spin, it had something to do with the switch not making contact when locked so I had to adjust that many times.
• Motor wire to foil detachment - the motor wire one time came out of the foil so I had to open up the thing and remove hot glue and stuff to fix that. I reinforced it with a ton of hot glue.

I think the fact that I was able to make something cool and work on it without giving up is something to be proud of. It’ll be nice to have this nice sitting on my shelf to remind me of the little things I can do that build up over time.

ALMOST READY FOR DEMO

First, I want to apoligize for how many hours I’m logging with this single devlog. I just wanted to get to a good stopping point so that I can share my full completed journey for each feature. (Unfortunately, this last problem took me nearly 4 hours to fix). I can hopefully make up for this by making this devlog long, detailed, and thorough.

Completed:

• Added a lot of configs such as robot mass, width, module locations, gear ratios, etc.
• I overrode the yagsl deadband and applied my own
• Adjusted and fiddled with tiny things here and there
• Added code that can switch your alliance during auto in code.
• Zeroed the encoders (took a while) and funny story, we tried putting in the value from phoenix tuner x thinking it was radians but it was degrees, so we used a radians to degrees conversion, but that just messed everythign up, when after like hours we found out that it was in rotations (0 to 1) and not radians.
• Fixed some controller axis inversion that happened in a specific alliance
• Tried to get the project to build by figuring out what the right dpendencies are
• Put in debugging code to try and fix the problem with reading pigeon values
• Followfunctioncommand and bounds system

I didn’t record time for this but I also helped prepare a backup roborio, did testing in sim and in the real robot, zeroed encoders, measured weight, and did other stuff with the real robot. I also made a controller guide which wasnt recorded.

FollowFunctionCommand (not tested yet however)

What this basically does is it takes a Function<double, double> and it converts the x value to time based on a ratio, and it take the output as the y value, and generates a custom autonomous trajectory that traces the function.

The reason I decided to do this is for a learning experience in autonomous paths, pathplanner, and the pipelien and all that.

Some struggles I had are that I started off with the completely wrong approach, treating it like a lazy command that goes to eahc spot as the time comes. But then I made it so that it instantly generates the path and it just runs the path, which is just a lot smoother and better.

Boundary System

Our demo space is a square area so I added a safety feature that keeps teh robot inside the space even if someone tries to drive it out. I also added overrides that someone on our demo team can use if it becomes finicky.

Since we added vision, I had to code a setup command (which was honestly the hardest part of doing this). I made it so that you pick two setpoints to make the robot face straight (which is more accurate than mannually aiming straight), then to go ot a spot on the boundary which the odometry resets to. I also added telemtry so the driver can see where the robot thinks its at and work with that.

The biggest issues I faced with this is because of some rules with how you use the SwerveInputStream type by yagsl. I removed the deadband thinking you didn’t need it since I had my own manual one, but it was required to make the robot face a certain heading. This problem took me a stupid amount of time to solve. I had to do human binary search through all my commits to see what couldve changed and what went wrong and allat.

TODO

• The highest priority is to get the real robot working and the pigeon values read. I won’t be recording hours for that though since its a hassle. Without the pigeon (imu), half my other features are useless.
• Set up the driverstation in our main laptop
• Finish and test the grapher
• finally remove the custom joystick overhead since well be using windows
• Add kid mode so peopel who want to try driving don’t accidentally mess with our setup buttons
• Maybe some other stuff I forgot to include.

Anyways thanks for reading my devlog, as long and boring as it is.

Signing off,
Ash-ioL

Made some progress!

Completed:

• Trajectory generation to bumps using compact code
• Removed trig from polar slew rate and replaced with vector math (so much cleaner)
• Fixed some axis inversion with the contorller input causing weird behavior.
• Broke bump paths unintentionally but fixed it again
• Fixed some landmark positions and zone coordinates that were incorrect
• Increased kp in heading requests to make it snappier

I am pretty surprised at the amount of things that I was about to work on and get done in this 5 hour period of time. I did a lot of testing, involving digging through past commits for direction issues and narrowing down issues with the bump stuff, and I also made sure not to ignore the small details like cleaning up old code and keeping things readable and compact.

Next:

Honestly I might take a small break from this robot. I did have a cool idea of generating PathPlanner trajectories with continuous math functions. But I might do that in another repository and move it over to this after.

Signing off,
Ash-ioL