team973 / 2017-inseason Goto Github PK

This includes determining what's wrong with the current setup

https://gist.github.com/yabberyabber/5baa4e6f1198c0c831b58fbb260d85ed

Need a drive controller that reads from the BoilerPixy subsystem and moves around until the boiler target is centered and at the right distance.

Log files will not clone using git clone or unzipping a zip of the repository. File name issue? Reproducible on Windows 10.

We need a subsystem for the 2 pixy's that look at the boiler.

This subsystem will have 0 actuators, but will talk to the pixy's to figure out the x and y offsets of the boiler target.

Off the top of my head we need 2 public methods:

• double GetHorizontalOffset (returns a number from approx -1.0 to 1.0 with 0 as center)
• int GetVerticalOffset (returns a number from 0 to 160 because that's the width of the camera)
• double GetDistance (returns the distance in like inches based on vertical offset... I vote we interpolate this unless you wanna do the trig)

Slow down when peyton pres t hebutton

if the rio supports syslog it'll be a lot more foolproof than the current method of creating data logs

Hey Andrew @yabberyabber

Sorry, to use this to get a hold of you. I didn't know an email address.
Looking at the code again with a unix terminal at my finger tips I see getting the current time like so,

time_t rawtime;
time(&rawtime);

That doesn't seem right by the man page on the c time function. Try

time_t rawtime;
rawtime = time( NULL );

Also the buffer size in strftime, should really be with the sizeof operator.

sizeof( buffer )

Cheers

Need a subsystem to handle the lights. Here's the interface we want:

• void SetOn
• void SetOff
• void NotifyFlash(int nFlashes)

When we need to do vision, we'll call SetOn
When we're done with vision, we'll call SetOff
The smartest way to do this is probably in the drive controllers that use vision

When someone calls NotifyFlash(n), the lights will flash n times then return to the previous state (on or off)
When the robot gets ahold of a gear, the gear subsystem will call m_lights->NotifyFlash(3) and the driver will see it and know.

This is my favorite subsystem. It's heckin cute. https://pics.onsizzle.com/live-breaking-news-dang-heckin-doggo-do-a-zoom-he-6204849.png

I think we can take out like half the states but let's sit down and draw another state diagram

Allen has a template for making it look nice and pretty in a google spreadsheet.

Allen also has opinions on what constitutes good control layout.

Single pneumatic solenoid. Default closed.

In auto

• Just expand it at the start (for now)

In teleop

• Give Connor a button to expand it and a button to retract it

I'm imagining 4 additional drive controllers.

AutoBoilerTargeting - targets the boiler and goes to a set distance
AssistedBoilerTargeting - targets the boiler but lets the user do the throttle
AutoGearTargeting - targets the gear and drives towards it and handles the peg colliding with the spoke
AssistedGearTargeting - targets the gear but lets the user do the throttle

The assisted targeting controllers might not be necessary. It feels unnatural. Is this evil?

Subsystem that runs one pixy and returns the horizontal offset of the target.

The reason this is a subsystem is so it can be easily shared between two drive controllers (there's gonna be an AutoGearDriveController that just does the whole scoring operation and there's gonna be a AssistedGearDriveController that does the turning and lets the driver do the throttle)