More advanced Software Ideas..

[joemost]

Hey Guys,
This thread is kinda a shot in a dark but here it goes! My friends and I are one year out from robotics, currently software students in college. Obviously we are far away from our home team/don't really have time to be helping a ton but we were hoping over the summer to build something software wise for them.

The only issue is we can't really think of anything to build, they have drive code down, and their vision code is decent.
I don't want to take away from the current students, our goal is to build something that just wouldn't be plausable in the short season by younger kids still trying to learn how to code.

Also, I think I heard that anything software wise that is not developed during the season has to be open source, which is fine by us.



Also to you seniors and juniors, cherish your time on the time. While I was kinda a mentor for my team over winter break, its not the same.. and it isn't as satisfying (still satisfying) seeing the team do well.. because you weren't apart of it


TLDR: What are some good high level implementations of software that your team or another uses?

[cjl2625]

How about a scouting system?
Over the summer, I developed a scouting system for my team from scratch, where scouts bubble in a sheet, which is fed through a scanner, and the data is uploaded to our scouting website. The scouting website has match predictions, team comparisons, charts and graphs for every team, etc.

[joemost]

Originally Posted by cjl2625

How about a scouting system?
Over the summer, I developed a scouting system for my team from scratch, where scouts bubble in a sheet, which is fed through a scanner, and the data is uploaded to our scouting website. The scouting website has match predictions, team comparisons, charts and graphs for every team, etc.

i Was thinking something a little more robot based to be honest..
I actually wrote them a scouting app which would collect the data and give them analytics already.. so year to year I can just tweak it a little in an hour or two

[AWoL]

Sounds like the next step for the team would be motion profiled movement. We were essentially in the same position last year, and a college mentor a year out from the team taught me how to do that in the off season.

[joemost]

Originally Posted by AWoL

Sounds like the next step for the team would be motion profiled movement. We were essentially in the same position last year, and a college mentor a year out from the team taught me how to do that in the off season.

Wanna give me a quick summary on what that is exactly?

[marshall]

Originally Posted by joemost

Wanna give me a quick summary on what that is exactly?

Watch this: https://www.youtube.com/watch?v=8319J1BEHwM

[joemost]

Originally Posted by marshall

Watch this: https://www.youtube.com/watch?v=8319J1BEHwM

So is motion planning really just vision based? I am still watching the video and trying to pick up on all of it

[Ether]

Originally Posted by joemost

So is motion planning really just vision based?

?? Not sure how you got that idea from watching the video. Try reading this thread.

[joemost]

Originally Posted by Ether

?? Not sure how you got that idea from watching the video. Try reading this thread.

Hmm from the 254 video it seemed like they were using a lot of different censor systems to accurately move to a point...

[rich2202]

Camera Control:

1) Expand Camera Class to more than one Camera
2) Select which camera is sent to the Driver Station, or multiple streams to the Driver Station
3) Class (driver) for each camera - Microsoft HD-3000 can't be easily configured.
4) Ways to easily send a camera stream to another device on the Robot (Raspberry Pi, Intel compute stick, etc.). An IP device (raspberry pi) can probably grab a camera image directly from an IP camera. A USB Compute Stick (or usb camera) may need the RoboRio to send the image.

[joemost]

Originally Posted by Ether

?? Not sure how you got that idea from watching the video. Try reading this thread.

Hmm Okay, i think I am getting a little better grasp on it..

What is the advantage? More precise movement?

Does 254 just run it in Auto..

Still trying to grasp it completely.

[Ether]

Originally Posted by joemost

Hmm Okay, i think I am getting a little better grasp on it..

What is the advantage?

Take 2 minutes and watch the video starting at 14:50

It answers your question.

[joemost]

Originally Posted by Ether

Take 2 minutes and watch the video starting at 14:50

It answers your question.

Ahh Okay, starting to grasp it a bit, basically for really accurate movement. It seems like you would only really use it in auto though, unless I am wrong.


My team this year struggled drive team wise, it was kinda unfortunate because we never got to see the robots ceiling competing wise...a lot of indecisive driving kinda held the team back. Sometimes I think about something to aid them with guiding the robot

[Cothron Theiss]

Originally Posted by joemost

TLDR: What are some good high level implementations of software that your team or another uses?

Have you tried using gyros to build a drive program that is relative to the field, and not to the robot? What I mean is, if the driver pushes the joystick forward, the robot doesn't just drive forward, the robot drives towards the opposite end of the field, or towards the goal, or whatever target you want it to be.
This would be a drive program for a Swerve drive, or maybe a Maccanum drive.
My team has never done this, but I would LOVE to see a good chassis that was driven relative to the field, not the robot. It would be very easy to drive, and could be a fast and reliable scorer, regardless of the game.

[asid61]

Originally Posted by Cothron Theiss

Have you tried using gyros to build a drive program that is relative to the field, and not to the robot? What I mean is, if the driver pushes the joystick forward, the robot doesn't just drive forward, the robot drives towards the opposite end of the field, or towards the goal, or whatever target you want it to be.
This would be a drive program for a Swerve drive, or maybe a Maccanum drive.
My team has never done this, but I would LOVE to see a good chassis that was driven relative to the field, not the robot. It would be very easy to drive, and could be a fast and reliable scorer, regardless of the game.

That's called "field-centric" control, and is pretty common with swerve drives. I know 1717 did this when they were around, 16 does both that and "robot-centric" by pressing a button to switch (or used to, anyway). It is a very useful feature, especially for new drivers. Mecanum wheels or an omni-wheel H-drive could be used to start this.

Writing some kind of program for a motor to hold an arm up would be tricky, but a good software project. You would only need a motor, gearbox, encoder, and some kind of off-center mass.