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

I am sleepy so short devlog

Quick summary:

• Added AdvantageKit
• Made sure the swerve 2d simulation works
• Changed default settings in custom joystick
• Measured some things in the robot and filled in configs
• Added current and speed limit
• Fixed the deadband
• Fixed som broken config values
• (not sure if this counts) but I also spent some time figuring out whats wrong with the can loop in the hardware (not counted in the 2h)

Plans:

• Test everything on the real robot
• Maybe add a fancy auto
• Maybe add a normal controller for people to try out, and an override controller
• Idk more ideas forming

Signing off,
Ash-ioL

Progress on the time… but no progress on the code

First of all I want to be clear I spent every minute of these 4 hours working on this. I was learning in depth how commands work, and shortcuts to use them, etc. as I was coding this on the side.

Anyways now that we have that clear, back to the progress report.

So this entire time I was working on making a teleop auto generation functionality to go from bump to bump with the click of a button.

Phase 0: Programmers start at 0

This only took like 5 minutes. So I copied over a utility I made in another robot that remaps the Xbox controller readings from windows axis/buttons to macos axis/buttons. So yay! I can use my controller now.

Phase 1: Brute Force

I wrote a like a 120-200 line code (forgot), and it involved copy pasting and changing stuff each time, resulting in a unique seperate command for each zone the robot can be in.

Why this was changed: It hurt my eyes.

Phase 2: Compactifying:

So I managed to simplify those into one command that modifies the pose x y and rotation values directly and uses mirroring and stuff to really keep it as low lines and simple as possible. I was proud of this, took a lot of thinking and fixing minor tiny errors here and there.

Phase 3: Kicking out the teammate with 4000 ping

By teammate, I mean advantagescope. It turns out when I was a youngling learning to do frc code (still am ig), i accidentally installed the x64 version into my macbook instead of the arm64, so after installing the advantagescope that my cpu works better with, it fixed the 4000ping and 10fps and I got a beautiful thing actually moves more than 4 steps when I push the joystick.

Before this it took me a lot of time ot figure out that i needed to reinstall advantage scope. I tried to mess aorund with the command scheduler, have a debate with stubborn AI about how to fix this, and lets just say it took a lot of time.

Phase 4 - What… the… hail who sped up time while i was coding

So now as I am writing this I am looking at the clock expecting it to be 10am, and its currently 11:30am which is normal for some people but I do practice at 6:30am so I’m probably not gonna feel the best tomorrow but whatever. Oh and how did my code work?

THE COMMAND JUST MAKES THE ROBOT JUST STUPIDLY DRIVE STRAIGHT TO THE MIDDLE OF FUDGING NOWHERE

but yea thats a problem for tomorrow.

And sorry the repository is private for now. I’ll try to get it public when my team meeting happens.

Signing off,
Ash-ioL