@Clio Batali has joined the channel
Home base for electronics/pneumatics! Make sure to also join the programming and engineering channels, but always check back here for cool resources!
@Riyadth Al-Kazily has joined the channel
@Kate Treviño-Yoson has joined the channel
@Jack Stratton has joined the channel
@John Sachs has joined the channel
@Lia Johansen has joined the channel
@Adrianna Carter has joined the channel
@Olivia Pells has joined the channel
@Benjamin Soldow has joined the channel
@Jon Coonan has joined the channel
@Declan Freeman-Gleason has joined the channel
@Rose Bandrowski has joined the channel
@Peter Hall has joined the channel
@Samantha Rosen has joined the channel
@Harper Nalley has joined the channel
That video was referenced in an article on Hackaday.com: http://hackaday.com/2016/10/30/primer-on-servos-hits-all-the-basics/
Thanks Riyadth! Everyone should watch/read these.
@Binnur Alkazily has joined the channel
@Jeff Dalton has joined the channel
New mentor question... I assume power is electronics. I'm curious what is done for power consumption management at design time. Is there a strategy? A more specific question is... does the drivetrain ever make power compromises (via design, build, and/or driver) in support of payload power consumption? Has power been an issue in past years? I'm just looking for short quick answers/links. Anything longer, I can wait 'til the next meeting.
Interesting question! The only year that we've actually had to take steps to manage this was this past season (due to all of the various motors, jetson board, and strain on the drivetrain due to the terrain complications). We've never had to make compromises, but motors do have to be selected intentionally for certain tasks. For more information/experiences from other teams, I'd definitely recommend checking out the forum Chief Delphi.
We did, however, remove the nvidia jetson board after encountering power drain/spike issues, and our discovery that we weren't finding its service useful at the time.
@Kaedric Holt has joined the channel
@Charlotte Larson Freeman has joined the channel
@Jack Chapman has joined the channel
@Adrien Chaussabel has joined the channel
@Chris Mentzer has joined the channel
@Finn Mander has joined the channel
@Jeremy Lipschutz has joined the channel
@Chris Rininger has joined the channel
Hey electronics/pneumatics people! At last, we’ll be meeting as a proper group this Wednesday (yay!).
The plan is that we’ll be deconstructing the old electronics system of our testing robot (ARES 2) in order to rebuild a bare-bones system for the programmers to test code routines on. Should be fun, but, before then, PLEASE remember to bring an engineering notebook. We will be learning lots of stuff, and it would be extremely useful to be able to write stuff down!
@Clio Batali pinned @Enrique Chee’s File to this channel.
@Mike Rosen has joined the channel
@Sophie Holzer has joined the channel
@Marie Sachs has joined the channel
@Dana Batali has joined the channel
@Kenneth Wiersema has joined the channel
What day are we getting the challenge?
(it's a Saturday, and we'll be meeting bright and early to start brainstorming)
@Alex Larson Freeman has joined the channel
Hey guys! I think it's high time to dust off this channel. Here's some holiday homework: 1. Please make a chiefdelphi account asap, and read through at least a couple threads to get used to the environment. Keep note of new words/terms you don't know and look them up or ask! (Eg COTS) 2. Please read through this doc about PID's (http://www.pc-control.co.uk/feedbackcontrol.htm). You do not have to be an expert, but everyone should at least understand the basics. 3. Finally, check out (skimming's fine) the inspection checklist that our robot had to pass last year (https://firstfrc.blob.core.windows.net/frc2016manuals/GameManual/2016-inspection-checklist.pdf). This year should be pretty much the same, so we all have to keep this in mind as we build.
Time to talk countdown clocks! For those unaware, a few volunteers will be building a countdown clock before school starts back up that we can use to count down until bag day. I've gotten all of the necessary materials collected (LED strips, buck boosts, and arduinos galore!), and have begun getting the coding up and running. That said, we have some hardware work to do in order to finish the project (mostly soldering and gluing... maybe some cad and 3d printing?). For more details, and if you'd like to be involved, please dm me or add a reaction to this message so I can start a group chat with everyone interested in it. Thanks!
@Julian Bonifaci has joined the channel
@Jim Carr has joined the channel
@Conrad Weiss has joined the channel
I think I may have left my engineering notebook in the electrical area. If people could just put it to the side on Sunday, I'll get it on Monday. Thanks! :smile:
Found it! It'll here for you Sunday
Everyone who didn't do the homework assigned over break: you have until Sunday! Scroll up! We basically did #2 during the meeting, but please check out #1 and #3 before the next meeting
Here is the list of sensors the programmers are interested in that I sent to Clio:
Distance Sensor (Different types?)
Color Sensor (Related thread: https://www.chiefdelphi.com/forums/showthread.php?t=153561, get a few kinds)
Camera that Dana Mentioned (https://www.amazon.com/Pixy-CMUcam5-Smart-Vision-Sensor/dp/B00IUYUA80)
When selecting a sensor to connect to the DIO (digital input) pins of the RoboRIO, we should choose a sensor that has an NPN output (and not a PNP output). Otherwise we will probably have to add more circuitry to make it work reliably. Here's some information from Chief Delphi: https://www.chiefdelphi.com/forums/showthread.php?t=143251
And for those who are interested, NPN and PNP are descriptions of bipolar junction transistor (BJT) configurations. It refers to the layers of a transistor, and how the silicon is "doped" (n-type or p-type doping). Here's more information than you ever wanted to know about transistors: https://en.wikipedia.org/wiki/Bipolarjunctiontransistor
http://www.schneider-electric.co.uk/en/faqs/FA142566/ Difference between PNP and NPN. Worth checking out!
@Timo Lahtinen has joined the channel
Two most common distance sensors are sonar and lidar. the first uses sound to measure distance .... We have some of these in stock... These are good for measuring short distances (<2m). Lidar uses laser and is accurate to 40m. If a case can be made for lidar, I can donate one. I'm not certain laser is needed for this year's challenges
And we need to verify that class 1 lasers are allowed this year
10.49.15.2 - use for the roborio webpage
I found some helpful link for the AMT10 series encoders. This link is a Chief Delphi post about one team that used them (https://www.chiefdelphi.com/media/photos/40929-Chief)
Here is a data sheet for the encoders as well. (http://www.cui.com/product/resource/amt10-v.pdf-Data) and a set of assembly instructions. (http://www.cui.com/product/product-resources/amt10-v-assembly-instructions.pdf). However, this last link has a good mounting instruction video. (http://www.cui.com/product/product-resources/amt10-v-assembly-instructions.pdf). -Katie
Would it be more ideal if a single CIM motor was used or two mini CIMs?
more than you might want to know about AMT10 encoders: http://www.digikey.com/en/ptm/c/cui-inc/capacitive-module-encoders-amt10-and-amt11-series/tutorial
(these look cool!)
http://www.andymark.com/E4T-OEM-Miniature-Optical-Encoder-Kit-p/am-3132.htm This is the E4T, which is effectively the same as our E4P’s. Here’s our current kind: http://www.usdigital.com/products/e4p#description
Also, another really useful resource: http://electronicdesign.com/components/understanding-resolution-optical-and-magnetic-encoders
@Brian Hilst has joined the channel
fyi: my reading is that the E4P differs from the E4T
The E4T is designed to be a drop in replacement for the E4P that offers higher maximum speed and increased output drive.
ie: max freq for e4p is 60khz vs e4t 100kHz, this also produces a different CPR (counts per revolution) range: 100-360 vs 100-500... All this is background to determine the magic constant for CPR. I have yet to determine how the 100-360 CPR is selected.
question: do we have 4 or 6 pin connectors. The former is "single ended", the latter is "differential".
What resolution are these encoders?
The encoders provided are 360 CPR. With 4X quadrature decoding, you get 1440 positions per revolution. Which gives you a unique position every 0.25 degrees. The maximum RPM for these encoders is 10,000 RPM.
Here is how maximum RPM is calculated:
For the E4P, the maximum output frequency is 60 kHz (60,000 cycles per second). A 360 CPR encoder produces 360 pulses on each channel per revolution. To solve for how fast the encoder's shaft must turn per second to reach the maximum output frequency, divide the maximum frequency by the pulses per revolution. 60,000 / 360 = 166 revolutions per second. To convert to RPM multiply by 60 (10,000 RPM).
4 pins - thanks for looking into the math (the CPR thing confused me quite a bit when looking through the docs)
here's a comment from last year's drivetrain code:
// Drive train QuadEncoder calibration
Wheel is connected to 48T sprocket, chain driven by 15T sprocket. 15T
sprocket is connected to encoder via 3:1 geartrain (1 turn of 15T
sprocket is 3 turns of encoder). Encoder is 256 cycles per revolution.
Multiply by 4 to get 1024 counts per revolution at Talon.
1 wheel rotation = (48 / 15) 3 1024 encoder ticks = 9830.4 encoder
ticks per wheel revolution
Verified experimentally by rotating a wheel 360 degrees and comparing
before and after tick counts.
here it states that we get 256 CPR... Which differs from the 360 reported above. Guess we'll have to perform experiments as was done last year.
if we put 5 encoders on 5 motors (2 drivetrain, one flywheel, one intake, one carousel) will they all be the same?
What is the exact part number for the encoder we have? That will let us determine all of its operating parameters via its datasheet. The part number is in the following format:
See the last two pages of the datasheet for how to interpret these values:
Thanks! So it is 250 CPR, 0.25" bore, No index, Single-ended, default cover, default base, bulk packaging.
We can work with that.
riyadth - thanks for unraveling the mystery!
@Clio Batali - now that I understand the possibility that we'll be dealing with a variety of encoders, I wonder if we (programming) could ask your team to maintain a google spreadsheet that has the location/function, motor type, CAN ID and encoder type plus CPR for all motors?
perhaps we can make a link to it "sticky" in both programming and this channel?
new 2.2 firmware for CANTalons
background for each potential i2c device:
bno055: has internal 10K pull-up resistor (need to verify model): (https://cdn-learn.adafruit.com/downloads/pdf/adafruit-bno055-absolute-orientation-sensor.pdf)
cmucam pixy: has internal 4.7K pullups to 5V on SDA and SCL: http://cmucam.org/projects/cmucam5/wiki/PortingGuide
@Dana Batali Another thing to recognize about the i2c bus is that the master (RoboRIO) must use a data rate that is compatible with all devices on the bus. In other words, if one device is able to work only at 100kHz, while another supports 400kHz, all communication must be at 100kHz (no switching back and forth between data rates). So we should determine what that rate is (unless the RoboRIO only supports 100kHz, which is the slowest normal rate).
From the RoboRIO user manual I see `the two lines on the I2C port all have 2.2 kΩ pullup resistors to 3.3 V`
also trying to determine if we need a logic-level converter for the pixy
According to the manual, the RoboRIO would be fine if that's the only thing on the bus: `I2C lines with 3.3 V output, 3.3 V/5 V-compatible input`
But, since there is a second device on the bus (the IMU), we have to be sure that it can tolerate the 5V pull-ups
Since the I2C 'active' or 'asserted' state of the pins is to pull them to ground, as long as every device on the bus can tolerate the pull-up voltage, then it should work.
According to the Adafruit documentation you pointed to, the I2C lines on the IMU are also 5V tolerant.
I think there should be no electrical problem connecting those two devices to the same bus
interesting - its a 20 CPR model (which means it might not be the best for high-precision applications)... It does seem easier to mount and use though.
Since it mounts to the CIM directly, it will be spinning at up to 5000-ish RPM. That's 83 revs/second, so the encoder will generate over 1600 cycles per second. With an assumed 10ms loop period in the CAN Talon, the controller would see 16 cycles (64 edges) per period, and so the resolution of speed control would be almost 2% (1/64). So the precision certainly isn't very high, but it's probably high enough for most applications.
For position control, we would typically use a gearbox on the output of the motor (reducing output shaft rotational speed), so the effective resolution of the system would be increased.
If anyone wants more information on encoders and how they work, just ask. I'm happy to draw pictures on whiteboards.
23x25.5 are the inside dimensions of the chassis if nothing is eaten up by mechanics this is how much space we get
@Enrique Chee has joined the channel
This is a link to the field assembly pdf with helpful dimensions of the field. https://firstfrc.blob.core.windows.net/frc2017/Drawings/2017FieldAssembly.pdf
Link to autonomous options. Feel free to add on! https://docs.google.com/a/bisd303.org/document/d/1sNYY5Gshu0nbd1onoQH5YnHifYy855KE0jqbipR7qgs/edit?usp=sharing
Possible autonomous routes-credit to Samantha Rosen.
@Declan Freeman-Gleason: @Niklas Pruen see distance information for autonomous ^^^
@Niklas Pruen has joined the channel
Update - no longer accurate. We're going vertical! (back of the intake, approx 5x6x24.5 inches... subject to change)
FYI: More than you ever wanted to know about crimping terminals on wire...
Here's the 2017 inspection checklist v1 https://firstfrc.blob.core.windows.net/frc2017/AuxDocs/2017FRCInspectionChecklist.pdf.
@James Slattery has joined the channel
FYI: a fuse holder for testing climber (etc.) safely:
They come in 10-packs too:
It uses automotive ATC fuses, like these:
It can accommodate up to a 30A fuse, and maybe would work with "resettable" circuit breakers like these (to save on fuse costs):
Here's a Chief Delphi post from Chill Out featuring their adaptation of an RC plane USB training controller as the primary driver control. I talked with them in the pits as well, and they're convinced this kind of controller hits the sweet spot that sits between the flight stick option and the Xbox controller option. They did have amazing driving this year. It is possible this kind of controller for driver + the custom controls for operator discussed a while back is a great combination. https://www.chiefdelphi.com/forums/showthread.php?t=158754
The first link is to the electronics things to know for the year
The second link is to the summer robotics inventory spreadsheet
Thanks for sharing those, Peter
Peter, thanks for putting together the link for electronics things to know. The second link has a column that says need. Can you explain is this need for this summer ?
I was searching around, out of curiosity, for information on how various teams mounted electronics/battery on the bottom of their robots for Steamworks to maximize ball storage space, and this thread was in the search results. Seems like there are some great tips here, so sharing... https://www.chiefdelphi.com/forums/showthread.php?t=123332&highlight=electronics+belly+pan+underneath
In case there is ever interest in bottom mounted electronics (teams that do it seem to find it more accessible), there was an extensive discussion on that very topic the past couple days... https://www.chiefdelphi.com/forums/showthread.php?threadid=159515
Key thread to follow - gold mine of tips about how to not lose radio and end up with a dead robot on the field. I'm sure we know some of these, but not all... https://www.chiefdelphi.com/forums/showthread.php?t=159634
@Randy Groves has joined the channel
@Terry Shields has joined the channel
@Peter Hall pinned a message to this channel.
@Mark Tarlton has joined the channel
Yet another example of a custom button box:
By rule, wireless devices are outlawed, so bluetooth aspects of this controller aren't relevant in our case.
@Ethan Rininger has joined the channel
@Anna Banyas has joined the channel
@Martin Vroom has joined the channel
@Ian Ruiz has joined the channel
@Cruz Strom has joined the channel
Plan for this Saturday's meeting is on the bottom of this document marked as day 4
@Peter Hall DO NOT put any anderson pole connectors on any new motors !!! Just use wire nuts until the final stage of the project. Come see me to talk about this. Thanks
I have not put power poles on any new motors. but i will make sure it stays that way. However the vast majority of our motor controllers have power poles on them from last year. so it may be difficult to connect them with motors
Also do not add any AP connectors on any new mc. I will show you what we will do while testing and building. Once everything is finalize we will any the AP connectors.
add not any
@Jules Blythe has joined the channel
Electronics Inventory (This is as of october.)
@Peter Hall pinned their GSuite Spreadsheet
I'm not sure if anyone else saw this - the papers and all the other knowledge shared in the thread seem very well done and the topic is undeniably important to the electronics team. https://www.chiefdelphi.com/forums/showthread.php?threadid=160758
I need two volunteers to stay for three hours after our Sunday meeting to wrap up some electronics loose end.
I can do that. @Peter Hall
I might be able to @Peter Hall
@Peter Hall please watch
Possible tip on fine control of pneumatic actuators in the Q&A. See question 91, asked by a veteran team, for guidance on legal use of electrically controlled pressure regulators. Answer says, "An electrically controlled pressure regulator is (or at a minimum contains) an actuator. If it meets the criteria of R33 (likely as an "Electrical solenoid actuator" or "servo" with the corresponding restrictions) and is controlled per R35, as well as meeting any other applicable rules, it would be permitted." I'm not sure how much the restrictions are restrictive, but it made me curious about whether or not a scissor lift powered by pneumatics could be made to stop at several positions using a gadget like they describe.
Apologies for the late notice, but something came up. I won’t be at the meeting today.
Robot #1 electronics & pneumatics as delivered to programming tonight!
@Peter Hall pinned @Terry Shields’s Image
@Terry Shields @Peter Hall @Riyadth Al-Kazily @Darwin Clark: programming would like to request that we add an ethernet switch/hub to the base chassis electronics package. We need this to plug an ip camera and the raspberry pi into. The hub itself needs power and connects into the one free port on the radio. In addition, both cam and raspineed barrel connectors into 5V. Amperage ratings are up to 2A, iirc, but will need to check. Note that helios had/has two cameras and the switch/hub and associated connectors for reference. As we get further down the road, we may learn that raspi is sufficient for all camera requirements (both auto and driver vision). If this is the case we could/should simplify by eliminating the switch/hub and IP camera.
@Darwin Clark has joined the channel
I am concerned that the pneumatic system this year is the most ambitious one we've ever put together, and we don't have a good idea of how the system will be designed yet. I would like to meet with some members of the pneumatics team tomorrow to sketch out the design (as we understand it so far), and make sure that we know all the parts we need to order, and can explain to the programmers how they will control it. I would especially appreciate one or more non-senior students who want to learn this stuff for next year. And I think it would be a good idea that everyone on the subteam read the robot rules section about pneumatics before tomorrow's meeting: https://firstfrc.blob.core.windows.net/frc2018/Manual/Sections/08-Robot.pdf
I'll be there!
Awesome! And when you read the rules section, be sure to note any items you don't understand, so that we can discuss it so everyone can be an expert.
Team, here is a description of how the scissor lift is designed to be controlled. We need to come up with a list of all possible types of solenoid valve that we are allowed to use, as this design uses parts that may not be "legal"
If we need to, I can contact Finn and ask him for help. He is still on the island
Let's see how far we can get tomorrow, and maybe we can write up our plans and ask Finn to review them.
That’s a great idea @Riyadth Al-Kazily I’ll definitely be there.
There may be another pneumatic cylinder to rotate the "harvester" arms (that guide cubes to the grabber) from the 'up and stored' position to the 'down and active' position. No intermediate position is expected.
Unfortunately, I don’t think I can make it tomorrow, but I’ll read the rules and ask about it next meeting!
No worries! And here's a very informative presentation from Simbotics that explains a lot of the principles of pneumatics. Hopefully it will help make sense of how it works. https://www.simbotics.org/files/pdf/pneumatics.pdf
Thanks for all of these great resources @Riyadth Al-Kazily
@Riyadth Al-Kazily Thanks for the tutorial link. I will be at our Sunday meeting to discuss pneumatics rules and our system design.
@Peter Hall I think we may need a rules clarification. R83 part D says:
D. Solenoid valves with a maximum ⅛ in. (nominal, ~6 mm) NPT, BSPP, or BSPT port diameter,
However, I think that's supposed to be 1/4 in. (which I think is the diameter of the ports on all of our parts... Can you find out if there is an update about this anywhere? Or am I reading the rule incorrectly?
General reference for pneumatics:
@Peter Hall @Terry Shields @Enrique Chee From my reading of the rules, an COTS solenoid can be used as long as the pressure rating is sufficient for our task, and it uses 1/4-inch NPT ports. I think we should consider using something like this from Amazon in order to save space in the robot: https://www.amazon.com/dp/B01K6L613M
Do any of you see issues with this, especially from a robot rules perspective?
@Peter Hall @Kenneth Wiersema please check rules . If legal I will order.
I ordered it.
ok, then What I ordered can be used for demo.
I just order this directly from Bimba. Won't be sent till 1/30. We still need to find a vendor that has the rest that Peter requested.
This is what Peter requested from each subteam (lift, intake/grabber, climber) .
I need help finding this cylinders !!!
I was able to order some but not all cylinders from Bimba if I reduced the quantity . Most are avaliable 1/30 . We paid a hefty $100 for 2 day shipping.
Ok good,I will try to find another vendor tomorrow so that we can order the the others.
Won't receive till 2/7/18 !! $100 2 day shipping again. So , in summary @Peter Hall, we still need to order two more of M-048-DP and two more of 0410-DP. Please find new vendor on Mon. and let me know.
@Riyadth Al-Kazily @Peter Hall: can you confirm that we are using this encoder: E4P-250-250-N-S-D-D on the 2018 drivetrains? (from western digital)
I cannot confirm this, but I believe I saw an encoder marked xxx-360-250-x-x-x-x being installed. This would indicate 360CPR instead of 250CPR.
The electronics team needs to make sure that both robots have identical encoders, and let us know what they are. Is there a document where we can capture all the relevant hardware information for the programmers?
@Peter Hall When do you think you will have the 2 vouchers ready to be ordered ? Digitial and Auto ? Thanks
I'll have that finished by the end of tonight
@Enrique Chee do you have the login info for Automation direct. It rejects the standard.
Just me email a list of the items you want to order with the link or part number . Thanks
Also it requires that we log in to the first inspires website to get the code.
I have the code .
@Peter Hall - pinging you on the answer to my above query about encoders on the the drive train... What model are we using?
@Will Hobbs @Peter Hall @Kenneth Wiersema @Rose Bandrowski
Will confirm on Friday
I don't know off the to of my head but I looked up the part number that Dana mentioned and it looks the the same as the ones we installed. it is very possible that the a appearance has nothing to do with it.
@dana would it help to know before Fri ?
For the Automation Direct Voucher https://www.automationdirect.com/adc/Shopping/Catalog/PneumaticComponents/AluminumPneumaticManifolds/MRA-6CB X3
For the Digi-Key Voucher https://www.digikey.com/product-detail/en/american-electrical-inc/162050/288-1154-ND/266519 X1
Not trying to cause trouble during finals week. We were having nontrivial problems with the drivetrain on Sunday. Any chance I can borrow it for a day or two? @Enrique Chee
Of course . When would you like to pick it up ? Anytime tomorrow
Any time works... When is best for you?
@Dana Batali Regarding installed encoders on Robot #1. Agreeing with @Riyadth Al-Kazily here. I’m pretty sure the part number for installed encoders is: E4T-360-250-x-x-x-x
How about between 9 am and 10 am ? On Tuesday ?
I'll be there
@Terry Shields - thanks for the heads up. We're okay with either the 360 or the 250 as long as its consistent between chassis. Last year we employed the 250 and this is the way our code is currently set up. FYI: this number is central to the way we measure distance and speed, and a wrong number would make our robot's behavior either too-fast or too-slow. After I look at the robot today, I''ll report back what I find.
Be sure to check that the count is consistent between gearboxes on the same robot as well. Otherwise you're going to go around in circles a lot :-)
Dana and I checked. We have 360 encoders on the primary robot and 250 on the secondary. @Peter Hall @Will Hobbs @Kenneth Wiersema @Rose Bandrowski. On Friday please replace the 250 with 2 new 360. I believe we have 2 new 360 encoders.
Thanks for letting me know. I was not aware that we had more than one type. We will switch them on friday
@Peter Hall @Terry Shields:
one additional requirement from programming: we need to ensure that the motors are numbered and wired exactly the same on both chassis. For drivetrain on robot #1 this is the state:
Motor 1: LeftMaster with encoder (360cpr)
Motor 2: LeftSlave
Motor 3: RightMaster with encoder (360cpr)
Motor4: RightSlave with IMU wired in
All ordered. Please add to inventory. Auto and Digikey @Peter Hall
Awesome, will do.
@Peter Hall Please find out on Friday how many magentic reed sensors and pivot mount we currently have. We did not order any pivot mounts or magnetic reed sensors for our new cylinders. Thanks
@Dana Batali We will make sure our 2 robots match (mirror images of each other to the fullest extent possible): we will document all installed electrical-pneumatic components, including sensors installed. @Enrique Chee @Peter Hall We need a count of encoders currently in stock too. With 2 complete robots going I want to make sure a single failed encoder does not leave us (literally) stoped in our tracks.
@Paul Vibrans has joined the channel
@Peter Hall Please share our team inventory sheet with your subteam and mentors like @Terry Shields and @Riyadth Al-Kazily. @Peter Hall Please confirm what encoders we have and what we need to order on Friday.
Ok can do
This is the link to the 2017-2018 inventory https://docs.google.com/spreadsheets/d/1bmWkvP3pyDZnIK-7-0UKK7PyeKFqyp173MM4soqi8/edit?usp=sharing
@Peter Hall pinned a message to this channel.
@Peter Hall It is probably a good idea when sharing documents to enable comments from viewers (rather than just "view only" permission). That way we can suggest changes or ask questions right in the document. And if you're not worried about us changing anything in there, you could open it up for full editing.
ok, I'll change it.
peter please change sharing permissions to can comment not can edit
I am worried about someone accidentally changing something
(Now I have to think up some intelligent sounding comments...)
Are there any limit switches? Should we buy some? We need some for the 2018 robot.
we have lots of limit switches, 17 to be exact. If we need more than that we could order more.
apologies if this has already been reported, I just ran across these pneumatic devices in the 2018 screenstepslive KOP:
@Terry Shields @Riyadth Al-Kazily @Peter Hall @Samantha Rosen Here is another legal manifolds for FRC.https://www.vexrobotics.com/vexpro/pneumatics/solenoids-and-manifolds.html
These are even better than the ones I found on Amazon, as we can mix and match single and double solenoids on the same base. We should determine the most likely configuration (since we don't know final routing paths for tubing, etc.), and order the parts.
ok, I have not ordered any. Any suggestions ? How many stations ? 3, 4,5, or 6 ? fittings ? also will this manifold fit with the solenoids we bought from AM ? Do we need this also ? SMC SY3000-26-9A Blank Station Kit
Also we ordered these manifolds with our vocuhers that Peter suggested from Auto. MRA-6CB | Valve Manifold: 6 stations (PN# MRA-6CB) | AutomationDirect
My suggestion is for the students to figure out which solenoids need to be individual and mounted on the mechanism, and which need to be centralized (and part of a manifold). But that is a hard thing to decide right now. If we end up buying too big a manifold, we will have to plug off unused ports. Right now I don't have a best guess on manifold size, but I can give it some thought today, and we can discuss it tomorrow.
@Riyadth Al-Kazily @Charlotte Larson Freeman @Samantha Rosen @Terry Shields @Peter Hall @Declan Freeman-Gleason :
regarding the encoder wiring between chassis. At the end of yesterday's meeting, Riyadth mentioned that there is a a standard wiring practice for the encoder signal wires. Needless to say, that's great. I'm now concerned that the "bug" i reported on the 2nd chassis, might actually be a bug in chassis 1. We're after maximum self-similarity between robots so that the same wiring and software configs are set the same way. We're also after maximum field serviceability: where spare parts can be easily swapped in with very little thought. I want to underscore the fact that these drive encoders are central to our ability to autonomously get across the field and we're happy to change our software to accomodate the "standard wiring". Please let me know which path seems to best characterize our current situation: was this a bug in chassis #1 (at which point, we'll change our software) or a bug in chassis #2 (the fix being a rewiring)?
Thanks! (sorry for the longish msg)
The question for the team (particularly @Peter Hall) is: How do you decide what colors of wire from the encoder are soldered to what pads on the Talon interface boards? Is there indeed a recommended color mapping?
The issue in question is where the phase A and phase B outputs of the encoder connect to, and if that is something we want to always do the same way (so spares can be pre-made).
The wires and breakout boards that we used were all soldered last year. If they are different or incorrect we can change it. I believe that Samantha fixed one yesterday. We do have more that have been made so hopefully we can just do a switch.
We only "fixed" one because Dana pointed out it was reading "backwards" on one side of the robot. But that would be the expected behavior if the two sides of the robot were wired exactly the same (since the gearbox/motor combo on one side is flipped around from the one on the other side). So this is a classic "fix it in hardware" vs. "fix it in software" problem. If the team is going to build spare cables and bring them to the competition, do we want to build "starboard" and "port" cables, and mark them carefully so they are used correctly, or do we want to make a "generic, one size fits all" cable, and require the software team to manage the differences?
I believe all encoders should be wired the same. We are already inverting the sense of the encoding in software on the inverted side since we have to invert the drive direction as well.
I agree with Dana.
@Dana Batali The chart you showed looks like something we could easily do. It sounds like it would be quicker for us to fix than the programmers.
so can i get an answer to the original question: is there a non-standard wired encoder on chassis 1 or chassis 2? Does different wiring account for the different behavior?
@Ted Larson Freeman has joined the channel
We need a document to keep track of the plumbing and wiring, and to let people know how their subsystems will interact with one another. I have created a document which may be helpful. It is a spreadsheet with tabs for different bits and pieces of the robot. Everyone has edit access to this document. If you like it, then we should all fill it out. If it needs to be changed or additions are needed, make those changes. https://docs.google.com/spreadsheets/d/1BIEKobwB9IJG3j5JsCzXHE07xLhpMP6ny9q-SbXM8/edit?usp=sharing
@Binnur Alkazily pinned a message to this channel.
Order #: 210158
Date: January 22, 2018
Status: Payment received
Shipping on: 02/07/2018
Spartronics/Bainbridge Island High
9330 NE High School Rd
Bainbridge High School Rm.316
Bainbridge Island, WA 98110
Part Number Description Price Qty Total
M-129-DP With Magnet [M]
1-1/4" Bore 
Stroke: 9 Inch(s)
Double Acting - Pivot Mount [DP]
Bumpers Standard $78.50 5 $392.50
Order Total: $496.52
Keep in mind the above items will not be here till 2/8/18. This might affect our time table of completion. @Rose Bandrowski @Kenneth Wiersema @Will Hobbs @Paul Vibrans @James Sovick @Julian Bonifaci
@James Sovick has joined the channel
@Peter Hall Please see above and inform the subteam on the time table for parts.
FYI, I will not be able to attend the meeting this evening :-(
Note that I did find that there is documentation on how to wire up the encoders in the Talon SRX Users Guide (page 27): http://www.ctr-electronics.com/Talon%20SRX%20User's%20Guide.pdf
Please print out that page and post it in the Electronics area, and highlight the color coding of the encoder wires. Then at some point we will need to check the wiring of the encoders on both chassis and re-wire as needed. (I accidentally instructed Sam to re-wire one of the controllers that was reading "backwards" -- it turns out it was doing what it was supposed to, and is now backwards...)
Also, I recommend poking your noses in with the other subsystem teams to see if there is any help needed for sensor mounting or control tubing/wiring installation. Especially for the scissor lift team, which will be first to deliver.
(I will be at tomorrow's meeting, but arriving a little late...)
One of the Andy Mark Current Sensors (am- 2706) is broken and we’re going to be ordering a new one.
If so , we should ahve a spare .
Yes, AM-2709 is the correct Current Sensor device we need. They are ~ $34 each. We checked physical inventory last night and found no spares in house. Suggest we order 2 since we need to replace 1 on a motor control test board .
@Riyadth Al-Kazily RE: the Talon SRX user guide above… We printed out “page 17”. I believe that is the page you wanted since it shows the Data Port pinouts for connecting encoders and limit switches.
That's a good page (17), but not the one I meant. And I was on the wrong page too. I meant page 23 with the section titled '1.4.6. Encoder (and Limit Switch) Breakout', as it shows this: 'Tip: The selected colors in the diagram match the cable harness colors for some U.S. Digital Quadrature Encoders.'
FYI. currently out of stock
Done. We have page 23 ready to mount on the wall too.
Inspection Checklist, please look over https://firstfrc.blob.core.windows.net/frc2018/Manual/2018FRCInspectionChecklist.pdf
@Peter Hall @Samantha Rosen @Charlotte Larson Freeman (and others on electronics/pneumatics) Review the checklist Kenneth posted, and we'll discuss it tomorrow.
Thanks will do
I will also print one out
Thanks @Riyadth Al-Kazily, I’ll print a copy as well.
Nice work @Charlotte Larson Freeman! @Kate Treviño-Yoson can you post a version of the motor wiring diagram as well?
Sorry, it failed to upload when I posted it yesterday!
Thanks @Kate Treviño-Yoson! That's great! Now it would be good for the electronics/pneumatics team to make sure that the spreadsheet I posted earlier matches up with these diagrams. Use the diagrams as "truth", and make the spreadsheet match. What we need is all the motor addresses and pneumatic channels to be very clear in the spreadsheet, so that the programmers know how everything is wired. Also, for the motor controllers, there should be a list of the sensors that are attached (I think there is a column for that, but if not then feel free to add one.)
Bonus points if you can add those diagrams to the spreadsheet on their own tabs (named something like "Diagram of motors" and "Diagram of pneumatics")
Sharing comments made in the programming channel...
I was looking at the pneumatics diagram shared there.
@Chris Rininger If the drop-down forks are all to be activated simultaneously, then there will be only one additional solenoid. If it is a release mechanism (ie, activating it causes something to fall into place, rather than activating it will push a cylinder that holds something in place), then a single solenoid will be sufficient (as we're not concerned about what happens after the match is complete, and the solenoids are all deactivated). One solenoid can pipe air to multiple cylinders, so there could be several latches that are released by the cylinders, all fed by one solenoid. If, however, you want to be able to release one side and not the other, then there will need to be two solenoids, each going to a separate set of actuator cylinders.
Thanks @Riyadth Al-Kazily Given how unrecoverably catastrophic it would be for forks to drop at the wrong time, I was also thinking redundancy might not be a bad idea.
Consider a servo as a secondary. It could pull out a pin that allows the cylinder to move. It is much smaller than a second cylinder.
@Justice James has joined the channel
Thanks @Kate Treviño-Yoson
Shared with programming leadership & feedback was putting a camera onto the robot is in the domain of electronics team, so copying here... Now that the lift is more or less on the robot, reminder that we will need a high camera that can look down at or at least on the same level as the scale platform so the driver/operator can see to place cubes. I'm not sure if Ethernet or USB is better, but my hunch is USB because a single coiled cable might carry power and data. Camera could be something non-wide-angle and fixed mount like maybe a simple Microsoft Lifecam HD-3000. Just keeping it on the radar because I think it will make a big difference.
@Kenneth Wiersema ^^^
Maybe worth looking thru the cad for potential placements
@Will Hobbs ^^^ I actually think that putting the camera on the scissor lift is the domain of engineering, coordinating wiring is the domain of the electronics team, and making that assembled system work is the domain of the programmers. It takes a village. Most importantly, and firstly, the team who designed the scissor lift has to figure out how to mount a camera in a way that does not impede scissor lift function. @Peter Hall and the electronics team can provide some camera options to use, and can help with the wiring. I do believe that the programming team would prefer IP cameras to USB cameras (because they just work...), but they may have other ideas.
They make coiled ethernet cables: http://www.cablescience.com/coils/electronic-1/ncc-series/network-cat6-coiled-cords.html. Might be able to use the coil around a pencil + heat gun trick on the power cord to the ethernet camera. I think with some trial and error we can get something to work - the key is a stable non-interfering camera mount, to Riyadth's point.
in case we go USB route (or we could hack this one for ethernet power also): https://www.amazon.com/Tripp-Lite-Hi-Speed-Coiled-U022-010-COIL/dp/B01L0EFB1M/ref=sr114?ie=UTF8&qid=1518228096&sr=8-14&keywords=coiled+wire+10+feet
Best to run the camera wiring alongside the air tubes. An exposed coiled cord will snag on things.
@Peter Hall @Declan Freeman-Gleason @Will Hobbs @Kenneth Wiersema do we have double of the cameras we will be using for the 2nd robot ?
I talked with @Dana Batali, he said there are 3 IP cameras on hand. Assuming 2 cameras per robot (one low one on back of lift), should probably get one or two more... Dana knows the model to get
we need to be careful here... THe Axis cameras are not what we want, what we do want is the dlink-933L or dlink-930. The 933L is on the second chassis and I think we have two 930s from last year. If we need more than that (they can failrly easy be moved from one mount to another), here's a link: https://www.amazon.com/D-Link-DCS-933L-Night-Camera-Extender/dp/B00CAT0QMQ
Cool thank Dana I will add those to my order list
and btw: we do have two raspberry pi3s so that's taken care of
@Dana Batali Do we have a second picam?
(at my home atm)
@Peter Hall @Charlotte Larson Freeman @Samantha Rosen @Terry Shields I just checked the programmer's chassis. It has 360CPR encoders installed (which is what you said was on the other robot also). So, we need more 360CPR encoders to replace the broken one and for backups. I would suggest to purchase at least 3, probably 4.
The software team needs the robots to match, and they should match this chassis. So do not put the 250CPR encoders on any robot.
FYI, I just debugged an issue with the pneumatics on the test board. It turns out that the solenoids don't actuate if the pressure is too low. We had the pressure turned down to about 25PSI for "safety", and the valves would not switch. When the pressure is turned up to 60PSI they switch just fine. So, when checking if solenoids and cylinders are working, be sure to set the regulator to 60PSI (or at least above 45PSI).
I also figured out how to read the schematic symbols on the side of the pneumatic solenoids thanks to this handy web page: https://library.automationdirect.com/pneumatic-circuit-symbols-explained/
@Charlotte Larson Freeman @Peter Hall can you check if the 360 encoders are sold by Vex ? And do we have any on Aries or spare motor from previous projects .
We usually get them from AM but they are backed ordered till 2/15.
It would be good to have some more even if we do have some on test systems (I don't think that we do) I'll let you know if vex has them by tomorrow morning
@Dana Batali do you still have the second vision camera? If not where would I find it, and If not, can I get it from the second robot
I don't see the 360s on Vex. However Charlotte found them on US Digital.
Also what diameter light are we using @Dana Batali
We are using the LED rings on the test robot right now
I found some in the robot room, so it would be preferable to have two set ups
We have two sets of the LED rings (they are identical to each other), but only one assembled camera system. If the mechanical team can make a plate (like the polycarbonate sheet we use now, or a piece of wood, or whatever), I can work with the electronics team to mount the camera and lights to it, and then it should just bolt on to the robot (assuming the plate could bolt on to begin with)
How I’m thinking we need a spacer to deal with the light, and can I get a rough plate size to cut
I am working with Darwin and Dana to select some rectangular LED panels that could be placed on the sides of the camera lens.
Good, I'd prefer 2 in tall panels to fit there
I may not make it to the extra build session today - but even if I make it — I’ll be late.
Good news @Peter Hall I ordered a bunch of 360 encoders and cable wires from US Digital this morning. We should have them by Wednesday. If programming finds that encoder for motors 3&4 is not responding properly we can swap it out. Until then let’s just keep that encoder cover down with tape.
It would be a good idea to find out how much current the articulated grabber CIM motor needs. It may be possible to use a smaller circuit breaker than 40A, which could save the mechanism in the case where the software fails and rams the screw off the end. The programmers should have access to log data that shows how much current it takes. We should run a test with a cube in the grabber, and swing it back and fort a few times to see how high the current consumption is.
@Peter Hall Do we have enough potentiometers for the 2nd robot and spares ?
I have an idea for mounting the pnematics that we can talk about tomorrow
But the brackets could be super useful
If the flipper motor, the one that moves the articulated grabber, takes less than 20A to operate, we should replace it with a Mini-CIM to save weight. At 20A, the Mini-CIM is more efficient than the CIM or for the same torque, runs faster. If the circuit breaker is supposed to be the safety feature that interrupts power when the motor stalls, it should be set at the value closest to 66% of the maximum measured current measured during normal operation. That means that during normal operation the movement time will be as little as 3.9 seconds and as much as 47 seconds before the breaker trips. The TALON should be set to limit current to 40A regardless of operation, which will trip a 20A breaker in 1.5 to 3.9 seconds and a 10A breaker in 0.3 to 0.6 seconds.
What circuit breaker ratings do we have in inventory?
We can also consider establishing a max current in software
I believe that we have 5A, 10A, 20A, 30A and 40A breakers available (@Peter Hall can verify if I am correct). The 40A breakers fit in the large slots on the PDP, the others all fit the smaller slots, so the motor controller would need to be moved if we switch to a smaller breaker.
Do you mean moving the controller or the wiring connections to the controller? A software current limit is better as long as it does not trip on noise spikes. That is the wave of the future in big power circuit breakers.
I mean moving wiring from one set of terminals on the PDP to another set. That's the power distribution panel, where the breakers are. The 40A breakers have a different blade size than the smaller ones. Software current limits are the better solution, BUT software has bugs, so we need a hardware backup :-)
yes that sounds right
links to electronics to do list
@Peter Hall pinned a message to this channel.
Looking at this Chief Delphi thread suggesting that, if planning to practice with a robot that heavily uses pneumatics for extended periods, it is a good idea to add a fan to cool the compressor. See posts 10 and 11 in particular. https://www.chiefdelphi.com/forums/showthread.php?threadid=162794
I share that because I sense we will arrive at a point when we would like to do some extended driving practice (or maybe that is just hopeful thinking on my part...) :slightlysmilingface:
:smiley: that sounds like a good problem to solve, when we get there :slightlysmilingface:
@brian_bonifaci has joined the channel
@Peter Hall @Charlotte Larson Freeman @Will Hobbs I believe the fiasco has been resolved. I just went through the process of ordering three more D-Link 933L cameras. We will have 4 (currently have 1) D-Link 933L cameras in inventory, and currently have two D-Link 930L cameras. On the primary robot there will be two 933L cameras (One for cube-view and one for scissor-lift view). On the secondary robot there will be the exact same setup. The reasoning for this is that the 2nd 930L is currently mounted on Helios, and there is no need to unmount it when we don't need to. ON BOTH THE ROBOTS THE CAMERA BEING USED FOR CUBE VIEW, AND SCISSOR-LIFT VIEW NEEDS TO BE LABLED. @Peter Hall Will begin work on figuring out the wiring for the scissor-lift camera. The spreadsheet is updated.
@Peter Hall @Charlotte Larson Freeman we got a broke limit switch
@Peter Hall I have found a relay that should work unmodified (in place of the one in the box that I put together). I still don't think there is an issue with using the one we have (as a "custom circuit"), but I ordered a couple of this new relay just in case. It should be shipped out shortly, and I think it will be here before the first competition. It will be easy to swap the other one out if we need to.
Awesome thanks. I don't think it will be a problem anyways but it's good to be careful.
Did we finish mounting the bling?
It’s on the robot in the chassis.
Has it been routed? Or is it just sitting there?
It is snaked through the base of the chassis. It could be mounted in another place. But I think that where it is is good. It will light up the robot from the bottom.
@Peter Hall Do we need a spare IMU? With 1 installed on each robot I cannot locate a spare in electrical inventory.
It would be good to have one. @Peter Hall please send me link of where to purchase and send to Jack and Kaedric to request.
@Peter Hall VERY IMPORTANT: Be sure to pack the 12V to 5V regulator that is on the plywood board test system (unless you already have another one of those packed). That could be what we need in order to get the network switch to work reliably. Also, make sure you have a spare VRM.
@Peter Hall @Terry Shields It looks like there is a potential issue with the high-volume compressor pulling a lot of current, and if the VRM is also heavily loaded then it can blow the fuse: https://www.chiefdelphi.com/forums/showthread.php?t=155037&highlight=vrm+fuse+blowing
Suggested option is to power the PCM from a breaker on the PDP (which I think we might have a port available with a set of PowerPoles connected to?)
Another option might be to reduce the load on the VRM by moving some of the 5V items to the Bling power converter. For example, the Ethernet switch could be moved to the Bling voltage regulator...
(Oh, and the two cameras could move as well...)
@Declan Freeman-Gleason The extra load on the VRM could be dropping the voltage to the cameras briefly, which could be the reason you were seeing one of them "glitch" into black&white mode...
Is someone able to pick up additional 20A fuses? We may need spares...
We’ll get 10A and 20A spare fuses somehow before competition starts. Perhaps even the auto parts store just down the street from our hotel. Or we work a deal with other teams in the pit.
And I think we can rewire power from our current setup to reduce load to VRM.
We need the fuse to pass inspection . Hopefully some teams will have one .
I will go to auto store at 7:30am for fuse
Agreed. Although terry I think that the more likely problem would be a short somewhere
We have never had a problem with this problem in the past and I don't see it being a power consumption problem other that a short drawing extra.
@Peter Hall read the Chief Delphi thread and do the math to add up the currents of all the loads on the 20 amp circuit. The total current is probably over 20. I am pretty sure we don’t have a short. Putting the PCM on a PDP breaker is a must, and I recommend moving at least one (better both) IP cameras off the VRM to protect radio power as much as possible.
@Riyadth Al-Kazily we also need to check if this compressor does not have the defective part that was mentioned in CD POST that you shared last night .
Yes, but the first priority is to rewire it. We will probably be fine with the defect as long as we are on a separate circuit.
@Peter Hall I just realized that the LED headlight power wires are probably 18 gauge, and could be connected to the PCM. We would just need to swap the breaker to a 20A. That could be the quickest wiring solution for the PCM
@Enrique Chee if you are not successful, Slack us and we’ll stop at Home Depot
We got the fuses
If I am needed and not responding to slack messages, call me at
@Peter Hall ^^ my cell
@Peter Hall I was just looking in to Bling, and it appears that the LED strip is plugged in to 12V (but it should be 5V). We need to connect it properly after the next match, and if it doesn’t work we should take it out before we bag tomorrow
The twisted red/black wires of the bling harness need to connect to the yellow/black output of the voltage regulator (which also feeds the cameras)
Since we found that the LED strip is still dead after switching to the 5 volt supply, we should remove the strip from the robot before bagging. And with it the Arduino and wiring harness. Unless that would prevent other planned holdbacks, of course. (I am thinking that we can replace the bling strip and properly test it, then put it back on the robot at Glacier Peak.)
@Peter Hall and team: One thing we need to do prior to Glacier Peak competition is verify the wiring & connections for compressor. While in queue waiting for Finals Match the compressor stopped running even though pressure was only reading 80lb. While Peter had his hands in the robot tracing some of the wires the compressor started running again - and ran fine thereafter. This could be a symptom of a loose connection and its worth taking a few minutes to trace the power cable/connections to the compressor.
If we have the chance, we should also consider adding another set of power cables to the PDP on an unused port, in case we need to add a circuit in a hurry at the competition. If we ever have the electronics board off the robot, it would be a good time to do this. Just cap off the ends of the wires with wagos, and tuck them away for future use.
Oh, and I would very much like to see the spare bling tested and prepared to swap on to the robot when we can. A lot of effort went in to creating bling for this robot, and I for one want to see it shine. (Let's be extra careful to not connect the LED strip to 12V this time... We should double-check the wiring changes we made at competition, and replace the 3-way wagos on the 5V regulator with 5-way wagos as well.)
We were talking about doing just that yesterday! That’s definetly something we’ll do when we get the robot. (And we will be able to do that- we have an hour of the mechanic’s two hours of unbag time.)
@Peter Hall @Charlotte Larson Freeman I never got the order for the solenoids you mentioned Thurs. :disappointed:
Chief Delphi threads like this make me happy for some reason. A bunch of people striving to squeeze every drop of optimization and failure avoidance out of a seemingly mundane thing... in this case, the ubiquitous robot battery: https://www.chiefdelphi.com/forums/showthread.php?threadid=160778
@Peter Hall Do you have extra IR ? @Will Hobbs
@Peter Hall TODO for you: The wiring on robot #1 is not set up to power the raspberry PI. From what I understand from @Riyadth Al-Kazily when the vision platform was pulled at competition the USB wiring to power the PI was pulled as well. Riyadth also expressed a need to condense the cascaded 3-way wagos into a single 5-way wago (For the output of the 12v -> 5v converter.) I am delegating this task to you during the next time you get to work on robot #1.
The wagos and USB connector for this operation is in the 'vision' drawer. (In the electronics section)
Good use of pictures! To be clear, we are talking about the 5V output of the silver voltage regulator. The 5V output is on the Yellow/Black wire pairs from the converter. That voltage source should feed the following:
Raspberry Pi (via USB adapter cable)
Bling LEDs (via Bling wiring harness)
Ethernet camera #1
Ethernet camera #2 (if we're still going to use 2 cameras..)
So, one 5-way WAGO will have the supply from the 5V converter (yellow wire), and then the red wire of the Raspberry Pi adapter, red wire from the LED harness, and wires with marks on them from the camera cables.
The other 5-way WAGO will have the ground from the 5V converter (black wire), and then the black wires from the Raspberry Pi adapter and LED harness, and the wires WITHOUT marks on them from the camera cables.
@Riyadth Al-Kazily Thank you for giving more in-depth instruction.
@Enrique Chee ^^^
I can't open that document. Can you give me read and/or comment access?
@Charlotte Larson Freeman Could we get the 'anyone with link can view' access?
@Peter Hall I'm sure you know this, but when wiring the new motor for the intake/grabber unit, be sure to use the correct wire gauge for the breaker size you select. This motor almost certainly doesn't need a 40A breaker on the motor controller, but you probably should ask @Paul Vibrans if he has done any calculations to determine motor current. 14 gauge wire if you use a 30A breaker, and 18 gauge wire if you use a 20A breaker. And I think the most important thing is to make sure the wire is protected from rubbing against moving aluminum edges, so that we don't wear through the insulation and short out the system.
We have already routed 14 gauge wire up the scissor lift
The only thing that still needs to get done is adding Anderson poles to everything and plugging it in
Also there are two solenoids that need to be plugged or removed
Nice! That should make things easy to finish off. Any concerns with wires being pinched or scraped as the scissor lift moves? I don't think it would take much to cut through the insulation...
It’s is routed the same way the pneumatics are routed. But we will check before we test anything
Great! Easier for me tomorrow morning.
@Terry Shields @Riyadth Al-Kazily@Charlotte Larson Freeman @Samantha Rosen I am concerned about the RoboRio power input on the robot. At Mt. Vernon Terry and I when fixing the RoboRio power wired the common (black) wire into one of the pcm/vrm ports. The reason for this change is there is a piece of aluminium stuck in the dedicated RoboRio common port. The change does not effect the robot performance. However, looking at rule R52 I am worried that it may need changing.
Can you post a photo? I out of town on business but can give it a look
@Riyadth Al-Kazily It is on the primary robot. So I will this afternoon.
Are you considering swapping out the PDP or extracting the bit of aluminum?
I was thinking that swapping PDP would be easier because we would have to take the PDP out to get aluminum anyway.
But for that we need to drop the board which we don't have the time to do.
@Peter Hall In announcements, Kenneth mentioned that the new harvester/grabber (HG) concept will need a pneumatic channel: "Set up an extra solenoid (already on the robot) to produce the floating affect."
I am not familiar with the design from a controls point of view, and I don't know what "floating" means here. Do you fully understand what needs to be done to make this thing work? Can you explain it (or better yet, draw a diagram)? If not, do you need mentor assistance to make it happen?
Pneumatics can be in one of three states:. Pressurized open, pressurized closed, or unpressurised (floating).. in this third mode the piston is free to move without resistance. The arms connected to the piston are controlled by the elastic bands rather than air pressure. I assume the two solonoids are arranged in series. The first solonoid determines whether it's in pressurized or floating state, and the second solonoid controls open or closed state when pressurized.
That sounds basically like what was used for the original grabber, which had an "enable" solenoid at the air source, and downstream of that there was an "open/close" solenoid. So the system would be un-pressurized before enabling, and then the code would enable the upstream solenoid when the match starts. From then on, only the open/close solenoid is used. If that is what is needed, then the system should be ready to go with no modifications (assuming the existing grabber cylinder is begin replaced with the new HG cylinder).
And this made me think that another "plumbing" option would be to use two solenoids in parallel, both fed from the air source. Both have their primary (default) outputs plugged, and their secondary (switched) outputs are plumbed to each end of the actuation cylinder. That way, when both solenoids are off, the cylinder is vented to atmosphere on both ends. Turn on one solenoid, and the cylinder is pressurized on one side. Turn that off and activate the other solenoid and the cylinder is pressurized on the other side. Turning on both does nothing useful (pressurizing both sides of the cylinder).
Based on my understanding of the current pneumatics nothing needs to change
(It's always easiest when nothing needs to change.)
The second description of how the valve work is correct. Open one solenoid valve and the cylinder extends. Open the other solenoid valve and vent the first and the cylinder retracts. Close both solenoid valves and both ends of the cylinder vent, allowing it to float. Opening both solenoid valves together will cause the cylinder to extend weakly.
This might be a nice feature when ejecting into the vault, depending on how tight the springs hold the cube in the float condition.
Sounds right to me.
Does anybody have a preference on which pneumatic option we go for. James has informed me that he does no think we need the slow open state so I am currently leaning towards not changing anything. If you care please say it now because we need the programmers to know fast if we are changing anything.
From what Paul said, it sounds like he believes having that state will help the HG complete the task of loading the vault. Has the HG been tested at the tasks it needs to complete to see if the state is needed? The tasks to test or at least simulate (that I can think of)
- Pickup single cube against wall (i.e. in platform zones)
- Pickup cube from several in a row against a wall (can also happen in platform zone if a robot has pushed cubes so they are all beside each other)
- Pickup single cube on floor not against wall (i.e. from portals)
- Pickup cube from bottom of stack
- Deliver cube to exchange
- Deliver cube to switch
- Deliver cube to scale (various positions)
Why can we not power down? We’re running into issues with the elastics as the new hg system cannot be lifted right now. The other idea is to add a pneumatic at the bottom of the scissor lift. @Paul Vibrans @Riyadth Al-Kazily What do we need to do to get this to work?
To power down the scissor you would need to add a single solenoid between the source manifold and the top of the scissor cylinder(s). Then programmers activate that solenoid when the venting solenoid is also activated.
I do not believe that a (reliable) power down could be implemented without adding a solenoid. I never saw the original power down experiment, or a diagram of the circuit, so I can’t comment on that
Power down requires the bottom pivot for the cylinder to be modified to handle down force. You con try it without modification but it may pull the cylinder out of the pivot slug and create havoc. There is a spare slug that has been modified to accept a set screw to try to hold it onto the cylinder
Good article on why we use ferrules: https://hackaday.com/2018/04/12/to-ferrule-or-not-to-ferrule/
Recently someone asked on Chief Delphi for good electronics resources, and there were several replies. I'm sure our team knows about some of the resources, but perhaps not all, so sharing... https://www.chiefdelphi.com/forums/showthread.php?threadid=166016
Yeah some of the those resources I have not seen before. Thanks @Chris Rininger those could be very helpful.
Clean new reference diagram https://www.chiefdelphi.com/forums/showthread.php?t=166190
Like I mentioned today at the meeting. This is the document that will have the meeting plans for the rest of preseason.https://docs.google.com/document/d/1rn2Na1XzFZ9OmWQp9ZZIAB5FD-3wtCHXK2U-wZgHH4/edit?usp=sharing
Hey all, I took the liberty of copying, and cleaning up the document that @Riyadth Al-Kazily started last year. I want to get this spreadsheet out there early, so that (hopefully) it will serve as a good communication vector between programming and electronics. https://docs.google.com/spreadsheets/d/1lR9CYn1wjTvvSBQCanzgtiyTt8GZbboRyQQt7uvdE/edit?usp=sharing
Thanks @Darwin Clark I think it will be very good to have this at the beginning of the season rather than introducing it in the middle like last year.
@Ronan Bennett has joined the channel
@Peter Hall I found your clock source code: https://github.com/ClioBatali/arduino-countdown-clock
@Riyadth Al-Kazily awesome
Teensy LC pinout. Looks like one of your buttons is connected to the on-board LED pin, but otherwise everything should work. I see that there is a 5V output pin, which is already connected to the LED strip, so that part is good to go.
I used that pin because that what the potentiometer was plugged into.
The one I added is in either 13 or 14
The two buttons are connected to 14 and 15.
Oh, that's perfectly fine then. It will work (when we write new software).
Do you have a plan for how the buttons work? That is, are they to set the brightness (like the potentiometer did at some point), or the time?
Also, I copied that 3128 control system layout into its own document, then I split the image into four parts, blew the parts up, and now it can be made into a 4:1 scale poster.
CD thread worth following (first post sounds familiar :grinning:): https://www.chiefdelphi.com/forums/showthread.php?threadid=166631
Thanks @Chris Rininger I have seen this thread and have been talking to folks over lunch about implementing the design in post #6. I think it could be a great way for electronics to guarantee the space we need without bothering the mechanic and most importantly having good accessibility. @Harper Nalley has also been working on some similar designs.
There is a Humble Bundle sale on electronics books, in case anyone is interested in that kind of stuff. (They even sneak in a few programming books :-)
Mentors and students who intend to work on pneumatics in the upcoming season should read and understand the attached American National Standards Institute (ANSI) standard for fluid power (air and hydraulic) symbols. When the time comes to create circuit diagrams for the pneumatics, everyone will be able to understand everyone else because there will be a common language. There will be a test!
@Tanner Nalley has joined the channel
@Camden Greenhalgh has joined the channel
@Miles Vilke has joined the channel
@Noah Solomon has joined the channel
@Max Hays has joined the channel
@Merrill Keating has joined the channel
@Kate Swietlik has joined the channel
@Jacob Preston has joined the channel
@Emerson Nicholas has joined the channel
971 is one of those silicon valley teams that always seems to do well. We can learn a lot from the wisdom their team has developed. I was investigating their control system software and ran into a pile of photos that showed lots of details about their wiring and pneumatics practices... Here they are:
Their new to them CNC mill is just like mine!
@Dana Batali thanks I’ll take a look
They also seem to rely heavily on a CNC router (that might be a bit newer).
@Stephen Reinhardt has joined the channel
@Alexander Perkins has joined the channel
@Adam Rideout Redeker has joined the channel
@Jeffrey Tappen has joined the channel
FRC 3847 is one of those teams that has a big focus on gathering and sharing knowledge across all disciplines. The electrical guide in this CD post seems well done & worth a read. It's not about robot electrical layout - it's about all the tools and components they use + best practices for how to use them, including step-by-step procedures and pictures for several things. https://www.chiefdelphi.com/forums/showthread.php?t=160752&highlight=mechanism+library+CAD
@Peter Hall FYI, I will not be able to attend the meeting tomorrow.
@Riyadth Al-Kazily thanks for letting me know.
Another excellent resource - I watched this 1678 electronics-pneumatics robot wiring presentation a couple nights ago, and in 23 minutes they do a great job. Good link to have on hand to share with anyone who wants a sub-1/2-hour overview. https://www.youtube.com/watch?v=LWMRDBBXYmI
@Ulysses Glanzrock has joined the channel
Hello Electronics Subteam,
I hope all of you have had a wonderful Thanksgiving. The other captains and I have decided that we would like to put together extra meeting dates in the Mechanics shop to help get things done before Build Season. The Mechanics, Electrical and CAD subteams all have tasks that need to be finished. All of these meetings are optional. Below are the dates:
Monday 11/26 1:45-4:00
Monday 12/3 1:45-4:00
Wednesday 12/5 3:10-5:00
Monday 12/10 1:45-4:00
Please fill out the survey to whether or not you can come to the meetings by Sunday at 12:00 P.M. (Noon). Please fill out the survey even if you are not planning to come to the meetings.
Here is the link to the survey:
If you filled out the link in the email I sent out, please do not fill out the survey again.
@Mitchell Teresi has joined the channel
@Peter Hall FYI I will not be able to attend the meeting tomorrow evening.
@Riyadth Al-Kazily thanks for letting me know
Teaching Soldering & Shrinkwrap
Thanks @Harper Nalley could you add that to the teaching checklist.
@Peter Hall Done
There's a discussion in the CAD channel about belly pans that may be of interest to the electrical pneumatics team. https://spartronics.slack.com/archives/C7X917F5H/p154398891100250 https://spartronics.slack.com/archives/C7X917F5H/p1544051148012300
@Mark Tarlton I did a little research of the 'laser' aspect of the A1M8 and this is what I came up with. According to the datasheet, the emmited infra-red light has a wavelengh of 775 to 779 nm (operating at 3mw). I did a little reading about reflection rates, and what I found seems to indicate IR absorption vs. reflection in plexiglass (and related materials) seems to be pretty wonky (main source: http://www.plasticgenius.com/2011/05/infrared-and-ultraviolet-transmission.html?language=enUS). The general impression I found was light in the 700-1600 nm range would be almost completly transmitted THROUGH the polycarbonate, therefore negating the ability of the lidar. Thoughts?
Graph of polycarbonate transmission rates
"Transparent" matches my guess. If you take a red laser pointer and imaging shining it around the playing field, that's what I imagine the lidar sees -- that is, very weak reflections off the plexi surfaces and a poor image of those objects. I'm going to dig through my junk drawers and see if I can find a laser and run the experiment. You may want to get a second opinion from Dana or others.
@Dana Batali @Riyadth Al-Kazily Thoughts?
I agree that transparent means invisible to Lidar. Same with perfectly reflective (unless perpendicular). The hope is that there are enough “diffusely reflecting” surfaces to get a lock on. I would guess that the diamond plate metal on the back wall will be good. Same with any non transparent glossy surfaces
Since the robot should always know "approximately" where it is, and there are fixed, non-transparent components to the field all over the place (ie, the supports that hold up the polycarbonate), shouldn't it just be a matter of matching up whatever the lidar sees to the map of known visible objects, and correcting the error in the "assumed" position? That is to say, you should be able to solve this in software, with enough effort.
Certainly, I was simply focusing on WHAT the lidar would see, as Mark brought up the question of IR during a previous team meeting. It appears the lidar would NOT see the polycarb, which changes the problem from a software side :slightlysmilingface: (Because the polycarb wall does not act as a visible object for us to reference)
In regard to light sensors: Some quick surfing yielded these: https://www.firstchoicebyandymark.com/fc-42ef-d2mpak-f4. @Riyadth Al-Kazily Would these work fine as a 'basic' color sensor? The main application would be to detect the white Gaffer tape. If not, what would you recommend? Considering the imporance for this years game, its a risk they might run out of stock...
What I think we might want is a linear array of sensors, spaced some distance apart from one another, that will measure the amount of light reflected from the carpet. I envision a row of LEDs and photo-transistors, pointed downwards under the front edge of the robot. Then the output from each of these sensors is fed into an analog input of our controller, and can be read by the robot code. That way, it can simultaneously see multiple measurements along this line, looking for a small area of high reflectance (representing the tape), and using an algorithm to move the robot so that the high reflectance area stays in the center of the strip of sensors while we move.
The sensor you indicate may work, but it is very expensive, and I think you'll want 5 or more, spaced about half the width of the tape apart, at the very least. (Maybe we can come up with a way in software to use only one or two of these sensors -- I know that's done in FLL for line following.)
In my mind, we want a scaled up version of this: https://www.amazon.com/SunFounder-Follower-Infrared-Detection-STM8S105C4/dp/B01HB5YVUG
Maybe we could use a bunch of these spaced about an inch apart: https://www.amazon.com/OSOYOO-Infrared-Obstacle-Avoidance-Arduino/dp/B01I57HIJ0
A good whitepaper on control system design, and it includes the use of IR (infrared) reflective sensors to detect tape on carpet. Very interesting use of pairs of sensors to filter out "noise" due to robot movement (ie, bouncing) which produces a similar signal to the reflected tape.
(I found the whitepaper in a search on Chief Delphi for "carpet tape sensor")
(The whitepaper has lots of useful ideas for the electronics and programming teams to consider - everyone please read it)
(Note that there is a "mechanical" component to the effectiveness of these sensors that we must be aware of: ambient light at the event will be different than where we calibrate and test our system (at school). We need to shield sensors like this well, to keep out as much stray light as possible, and we need a method to recalibrate easily when we get to an actual event. I learned that problem in FLL, the hard way...)
Wow... Thank you so much for the information. I was mainly trying to weed out priority in terms of ordering parts, because I was unsure if one PARTICULAR sensor was going to be in high demand, but from the looks of this, we can use (the many) devices designed for micro-controllers to come up with our own solution; So less concern in terms of deadline. Granted, all the discussion about the 'solution' should probably be tabled until after week 1 (On account of not knowing our strategy yet, what we want to spend effort on, ect. ect.) but it's good that we've got some reading materiel. Thanks @Riyadth Al-Kazily !
@Lauren heinzelman has joined the channel
In this weeks rule changes R86 was edited to disallow an offboard compressor from being used. Here is the rule "Throughout an event, compressed air on the ROBOT must be provided by its one onboard compressor only. Compressor specifications must not exceed nominal 1.10 cfm (~519 cm3/s) flow rate @ 12VDC."
well you could theoretically still make a sand flea jumping system. This rule change only means that if you have pneumatics on your robot then you have to have the compressor on the robot. VS historically they have allowed you to charge your air tanks with an offboard compressor.
@Violet Advani has joined the channel
Instead, teams will precharge with onboard compressor and then change to a fresh battery, right. Not sure what they're accomplishing with this really.
I think to stop someone from "supercharging" a tank beforehand? I'm not sure, either.
Robot Controls Layout Design
Looking through Chief Delphi, searching for schematic & wiring diagram software I have become a convert to the simple method for initial layout of our robot electrical/controls/pneumatics/wiring. (I stress “initial”).
The answer is: cardboard, X-ACTO knife and color sharpie pens
Benefits: everyone can be involved (even new students); Layouts can be 100% to scale; we can even model the components as 3-D cardboard boxes (added bonus: paste a picture of the component on top, and mark locations of key connections); it’s a quicker way for students to learn how the components interact and get creative for mounting and wiring path layouts; we rarely give wiring paths their proper due, let’s get away from the spaghetti factory look and give wiring paths their proper due.
We have cardboard , pens , and many X-acto knives .
Have someone convert the boundary dimensions of the product into CAD for integration or pass these dimensions soonest to the CAD people. Also check with the CAD people often to see what just got put in the space you thought you could use.
@Terry Shields sounds like a great idea. We should definitely try it out.
okay: I'll admit that this is off-topic but very much related to electronics and very easy to get excited about if you are "of a sort" :wink:
Remember there is foam core board as an option
Ok, that was pretty cool! I was a little thrown off when they mentioned the card plugging into the computer's 'ISA bus' -- but then this was 1996!
I was reading about actuators, and thinking about how to flick panels onto the targets without using pneumatic pistons. COTS servos <$75 are allowed in the rules. How close can an electric servo motor (or two) come to the quick thrust of a pneumatic piston? For example, I'm looking at this one: https://www.amazon.com/LewanSoul-LD-3015MG-Standard-Digital-Control/dp/B073F4TRSK/ref=sr13?ie=UTF8&qid=1547534999&sr=8-3&keywords=linear+servo+PWM
Saw this - the electrical component template stickers are interesting because of the drill hole markers: https://www.chiefdelphi.com/t/swyft-robotics-company-and-product-announcement/335907
FIRST clarified R6 (panel shooting).
>At Inspection, Inspectors will expect teams to demonstrate compliance with R6 using the configuration and operation of the ROBOT that results in the farthest shot of a HATCH PANEL, i.e. the greatest distance of which the ROBOT is capable.
Would this affect the type of cylinders used on the panel grabber?
Maybe the type (or size), but also probably the air flow to the cylinders. We can add restrictors to allow us to "fine tune" the force of the pushers, at least over some small range of adjustment.
@Peter Hall If we are ordering parts from Automation Direct (do we get a coupon or something?) we should order some relays, which are a newly approved motor control solution we may want to make use of. Automation Direct part numbers AD-SSR6M12-DC-200D, AD-SSRM6M25-DC-200D, AD- SSR6M45-DC-200D. The number after the "M" is the current capacity (in amps). Looks like only the 12A is in stock, which would be useful for turning on and off smaller motors or bling circuits. I suggest ordering at least two to have on hand: https://www.automationdirect.com/adc/shopping/catalog/relays-z-timers/solidstaterelays/panelmountrelays,hockeypuckstyle,10a-75a(ad-ssr6series)/ad-ssr6m12-dc-200d
Note that the big relay on the list has the wrong part number in the game manual (section R36.B Relay Modules). It is listed there as AD- SSR6M45-DC-200D, but it is actually AD- SSR6M40-DC-200D. They get it correct in table R59.
@Riyadth Al-Kazily I don't remember if automation direct is in the vouchers (Though it rings a bell) I can check and we can get those ordered at Fridays meeting either way.
Yeah, the relays are not too expensive, so I'd still suggest having a couple on hand so that we don't have to use my "DIY special" like for the vision lights last year.
2 relays have been ordered using our vouchers.
Sorry I haven’t bee super active. I spent 11 hour on oral finals yesterday
No need to be sorry. I had some free time interval. I will spoil you for now. Not after Friday. @Peter Hall
@Peter Hall Do we need encoders ?
No, we are all good
@Peter Hall please check that that the new air cylinders we ordered will match the fittings we have in inventory.
@Peter Hall Did you start to make one of these spreadsheets? I recommend merging your information into this one, so there is only one "truth" to electronics/control mapping.
He did, I reccommended we move to this one, for convention in addition to the features of this version. He agreed. @Riyadth Al-Kazily
I've started editing this one with some thoughts.
I remain staunch in my opinion that the use of port and starboard is obfuscatory :astonished:
For velocity, I prefer "furlongs per fortnight". :wink:
Here's a CD thread on using two pistons together for 3 or 4 positions, including one post with a nifty diagram. Multiple people say they've used the approach with success, and it seems recommended over the 3-position pistons. https://www.chiefdelphi.com/t/3-position-pistons/140746
@Riyadth Al-Kazily This is the hat I ordered: https://www.raspberrypi.org/products/poe-hat/. The exact link is here, made by MakerFocus: https://www.amazon.com/MakerFocus-Raspberry-Expansion-Brushless-Supporting/dp/B07HGRT335/ref=sr12?ie=UTF8&qid=1548045670&sr=8-2&keywords=raspberry+pi+poe+hat.
The PoE-hat you ordered assumes the power injector is an official 802.3af thingee that uses 48V DC for the power. I've got a couple of those but they all plug into 110V AC outlets. I was thinking of something low-tech more like this https://www.amazon.com/Injector-Splitter-Ethernet-Connectors-WS-POE-IO-1-35/dp/B00EBNBZ8I . Even then, You'd have to check with @Riyadth Al-Kazily about input voltages.
Darwin, as I feared, this is a "POE (TM)" hat. The real deal. We won't be able to use it directly on the robot (unless we first boost the 12V battery voltage to at least 36V, which is probably not worth it). The injector/extractor set that Mark linked to may work, but we do need to convert from 12V to 5V at some point. It would be better (if using that injector) to inject 12VDC, and convert to 5V at the Raspberry Pi, as this would minimize the current flow on the Ethernet wires. That would mean we need to include a voltage converter module in/on the RPi enclosure...
At this point I think we should proceed with separate 5V inputs to the RPi enclosure, and convert from 12V to 5V centrally, maybe with a high-current converter that can power multiple RPis.
@Peter Hall This board will allow us to connect 4 more analog sensors to the RoboRIO (for a total of 8): https://www.andymark.com/products/rev-robotics-more-board-v2-0
What about a motor-generator set using two 775 PRO's connected together. 12V in and 5V out with voltage regulation by changing motor speed. Needs filter capacitors on the generator to smooth out commutation noise. Plenty of watts available!!! Even more watts available if we drive the generator with a reduction gear having a 2:1 ratio.
Can we add a large flywheel?
We might as well. While we are adding gears we could drive the flywheel with a speed increaser to get more watts for our kilograms. Do we need black-out ride-through capability?
Does this work ? EPBOWPT DC 12V 24V to DC 5V 10A 50W Converter Regulator 5V 50W Power Supply Step Down Module Transformer https://www.amazon.com/dp/B01M03288J/ref=cmswrcpapaifvPrCb52YGTZ2
Probably. We should already have several types in stock. We use them for Bling as well.
@Lane Johnson has joined the channel
@Peter Hall @Declan Freeman-Gleason I don't know if you two decided where the IMU is going to live on the robot. You should work with the CAD team to figure out a spot that the sensor can be placed, where it will stay for the duration of the season. Since electronics are likely to go vertical on one side of the robot, it makes no sense to place the IMU with the main electronics board. Maybe we need to design a small platform that sits between the drive CIM motors to hold the IMU in the center of the robot?
And is there even an IMU on the initial control board for the first chassis? I think that might be an important feature to include for the programmers.
(Oh, and btw, I will not be in tonight, if you haven't figured that out already...)
Thanks @Riyadth Al-Kazily I’ll add those to my order list. I also have some other stuff to order. Will you be there on Friday. I’d like to go through it with you.
@Riyadth Al-Kazily @Declan Freeman-Gleason I have not put an IMU on the chassis. I’m happy to do it when we get there on Friday.
I do plan to attend on Friday.
That would be great. Please try to put it as close to the center as possible.
@Peter Hall We can get a similar wire duct on Amazon. Here is one that is 1" wide and 2" tall (which gives us more room for wire, without taking up more width). I think it may be a better choice than the 1"x1" stuff.
Ooh great I’ll switch that out with the one on the order list.
@Peter Hall @Riyadth Al-Kazily -- What do you plan to use for the ball position sensors? I'd like a link to the spec sheets so that I can think about mounts for them. Thanks
@Peter Hall We will need some green LED rings for the vision system. At least two rings per robot (front and rear facing cameras), so I suggest ordering 6 (two spares). I can't find any on Amazon, but here is a link to Andymark:
Note that they are available in different distance ranges. We guessed that the 4 to 30cm range would be best for internal ball sensing, but they also have a 10 to 80cm unit (which we are also using for climb height sensing).
All the sensor models/ranges have the same form factor, I believe...
(And to be clear, it was our (my?) thought that the sensor would be placed such that it could measure the cargo position in an analog manner, so that discrete position sensors would not be needed along the chute. If this is not possible, then we can come up with a simple discrete sensor that just reports cargo "present" or "absent" within a very short distance range.)
@Justice James ^^^ 4 to 30cm for cargo detection and hold
@Austin Smith ^^^ 10 to 80cm for climbing. Note, team is also planning on front facing distance sensor to determine the robot lineup from the L3 platform
@Austin Smith has joined the channel
Yeah, I did get that from our conversation. I was thinking about angling them so they could see what's coming up the chute. I'll read the spec sheets and get back to you on distances.
Here are my rough notes on our sensor needs (may be a bit of overkill) :
Intake Sensor that detects a ball passing through the Intake Arm and on it’s way up the ramp.
Chute Low Sensor (high looking towards intake) that detects a ball is within the control of the Chute (at the intake end)
Chute High Sensor (low looking towards exit) that detects a ball is within the control of the Chute and as not been ejected fully.
Chute Elevation (Optional) indicates the elevation angle of the chute…
Two front facing distance sensors. One on each leg of the "U" chassis. That said, I don't think anyone owns the mounting of those sensors. @Mark Tarlton can you make extra mounts? (Also, realize that these sensors cannot be mounted to the frame, even with a screw, as they conduct to ground via the plastic. The sensors must be isolated.)
@Riyadth Al-Kazily Can we use 3D Printed mounts and stick that to the frame? Is that enough isolation?
Tip on wiring the LEDs for camera
> One more thing: assuming you’re using 12V LEDs, power them from a 12V regulator like the VRM, not directly from the battery. Not only will this help save your LEDs from burning out due to overvolting, it means they won’t dim when you’re driving.
Yes, that would be great.
(I assume the fancy 3d-printer filament is not conductive... Regular PLA/ABS would work fine.)
@Riyadth Al-Kazily @Darwin Clark @Peter Hall ^^^
This is a really useful thread… @Darwin Clark—be sure to look at this post about IR: https://www.chiefdelphi.com/t/best-led-color-for-vision-tracking/342361/12
I believe that Darwin is looking at cameras with built in IR and visible light sources. That will simplify everything since power then comes through the RaspPi connection.
IMPORTANT: We are constrained to 8 analog sensors on the robot (without having to take on some extreme measures which will impact the programmers). Right now we require at least two sensors for the climber (to know when to retract the stilts), and the desire was for two sensors on the front of the chassis to detect alignment with the platform.
There are a variety of chute sense points, which hopefully can be achieved with 4 or fewer analog sensors.
Where it makes sense we should consider digital sensors, and reserve analog inputs for where they are mandatory.
We should also consider how important the front-facing sensors (for alignment) actually are...
iirc - these connect to the analog sensor (ie: they produce analog voltages)... Do we have enough analog ports on the roborio or was that
hah - riyadth just beat me to it!
The base RoboRIO has only 4 analog inputs. We are getting a board that plugs into the expansion connector on top of the RoboRIO to add 4 more.
@Darwin Clark @Mark Tarlton I understand the current direction is a green LED ring around the lens of the regular RPi camera. So visible, not IR light.
@Dana Batali @Riyadth Al-Kazily -- Thanks for the info. I'll try to simplify the sensor locations. We may want one of the 80cm sensor looking down the path to track distance through the chute
Any sense of how well collimated the light source and sensor are? I'm concerned about getting false returns from surrounding structure.
@Randy Groves did most of the exploration of this last year... We used it to detect if the cube was captured and it seemed to work reasonably well in that configuration
The site says these are out of stock. We should find another source...
@Riyadth Al-Kazily @Declan Freeman-Gleason Correct ; IR is in experimentation, probabbly going to be an off-season project. Current plan is to use LED rings.
The gp2y0a41sk0f sensor that we used last year has a 4-30 cm range. I did not do any testing that would determine collimation. So - unknown.
Don't see anything in the data sheets about the width of the light beam: https://www.pololu.com/file/0J713/GP2Y0A41SK0F.pdf, https://www.pololu.com/file/0J845/GP2Y0A41SK0F.pdf.pdf (yeah I know it says a41, but it's the sheet for a51 - 2 - 15 cm)
Thanks for checking. I read the spec sheet as well and the usage comments just warned that nearby objects might interfere. I wonder if we can put 'blinders' on it as part of the mount to reduce detection of objects surrounding the view field of interest.
We need to remember to electrically isolate the sensor from the frame - we got bit on that last year!
Actually, it looking at the mechanical drawing of the sensor again, they may already have some blinders on it at least on one axis, and for the other axis it may be focused on the gap between the emitter and detector. It may be pretty good actually.
Right, Riyadth mentioned that. I'm going to try to print some mounts using PLA.
Ok I’ll take a look this weekend
How does one share a folder on Google drive with a slack channel? I've got some results of curve fits for the a51 IR sensor
I think you just need to right click on the folder and select "Get shareable link". Anyone with that link should be able to see what's in the folder.
(ie, paste the link in the slack message)
Cool. Then here's the link:
Don't like that! It will share ALL of my google drive with Slack. I just want to share the one folder. Other options?
Maybe I just import them into slack?
If you click on a folder, it only shares that folder. At least that's how it works for me.
I don't know what import into slack does.
Links are better as we are low in data capacity — as @Riyadth Al-Kazily said, just click on the folder you want to share and get a shareable link for that folder
Well - maybe it did share it - can you see the folder link and get to it?
I see the folder, with 5 spreadsheets and a text file.
I can open the files too.
Yup — you are good, only shared the directory for the “Curve fits for a51 IR sensor”
Worth thinking about https://www.chiefdelphi.com/t/shock-mounting-electronics/343671
just discovered wolframalpha's unit converter!
Nice! Very handy!
#engineering Wolfram Alpha is a nice web resource for technical problem solving ranging from physics constants, conversion between measurement systems to quantum physics and beyond. Alpha is an AI system with a long and interesting history. A good find by @Dana Batali! https://www.wolframalpha.com
This is the list of the cylinders we are using
@Harper Nalley What does column 'C' represent (single/double)? (I recommend putting headings on the columns) I assume it's not the solenoid type, because that seems to be column 'D'.
@Riyadth Al-Kazily Oh, sorry, that means two cylinders per solenoid.
Maybe just a "number of cylinders" would be easier to understand?
(The chute cylinder was 4in before you changed it, and is now 3in - maybe a typo?)
That's much easier to understand. Thanks!
@Harper Nalley any reason why this is not part of the 2019 Deep Space Robot Control Map? Document linked to right about your slack message?
Oh, oops. It's because I hadn't thought of that
There we go, it's now in the Pneumatics tab
@Peter Hall Darwin is in need of more green LED rings for the vision project, but as you know AndyMark is out of stock. I found these, which seem similar. The 60mm (same as AndyMark) are out of stock, but they have bigger ones (which are good, because they are brighter). I recommend ordering 4 of the green 80mm rings: https://www.superbrightleds.com/moreinfo/led-halo-rings/led-halo-angel-eye-headlight-accent-lights/49/315/
@Terry Shields We were talking about the option of different tanks. Here's a CD thread on that. https://www.chiefdelphi.com/t/air-tanks/340921 And here are a couple tanks mentioned: https://www.amazon.com/Air-Lift-12958-Aluminum-Tank/dp/B00GWITQ54/ref=ascdfB00GWITQ54/?tag=hyprod-20&linkCode=df0&hvadid=316708741155&hvpos=1o1&hvnetw=g&hvrand=12179999147365778427&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9023862&hvtargid=aud-466346483690:pla-589242904769&psc=1
I believe tanks like this should work for us, as long as they are rated at or above our 120PSI storage pressure limit: https://www.amazon.com/Pro-Force-FT5-5-Gallon-Portable-Tank/dp/B002MKP5TM
They also have some tanks with multiple ports, which could make plumbing easier: https://www.amazon.com/Vixen-Air-Gallon-Suspension-VXT3100/dp/B078X1TR71
Sounds good. I should be able to get that ordered. However at this point we might want to look a shipping times.
Agreed on shipping times, but delivery after bag date is OK. We have two rings to prototype with, and just need more because they are a bit small, and one has started to fail already. I'm mostly concerned about having the parts on hand by the time of the competitions.
Cool well I’ll get that in today.
I was speaking to a guy on reddit, and this team uses some pretty interesting pneumatic routing as well as integrated manifolds
This is my post and his replies are in the comment section
For what it's worth, I just found the following equations in https://www.dfrobot.com/wiki/index.php/SHARPGP2Y0A41SK0FIRrangersensor(4-30cm)SKU:SEN0143
Large multi port tank seems like a good way to go if you have a location for one.
They are for hooking up to an Arduino Uno, though, so it may not be of use.
@Peter Hall We should get one of these for each Raspberry Pi on the system. (It is a better solution than the single 10A voltage converter I had you put on the electronics board.) We will attach this module directly to the enclosure with the Raspberry Pi inside. As such, we will need (probably) 4 of these per robot, so we should get at least 8. https://www.amazon.com/DROK-200102-Converter-Regulator-Transformer/dp/B016XI9CZQ
And here is another tank that is smaller size, only 1 gallon, rated for 200PSI, aluminum, for $55 https://www.avsontheweb.com/avs-1-gallon-aluminum-m-p-m-air-tank-raw/
@Peter Hall yes or no LED ring ?
@Peter Hall yes on the 8-port swtich and 8 of the converter that @Riyadth Al-Kazily suggested ?
@Peter Hall voucher orders ?
Yes on both the converter and the switch. We have not had a chance to order from vouchers yet
Very nice. Beautiful work. There was a team last year that did a similar wiring technique. They sandwiched their wiring between 2 sheets of clear polycarb separated by 1” spacers. It was a very tidy layout. This one is even cooler because the wiring practically disappears behind the black surface.
@Enrique Chee We decided to push off the voucher orders until we could actually spend time going over them for two reasons: one, none of the stuff were things we needed for this season. two: the vouchers expire in either one or two months depending on voucher.
Ok. We did need air tanks and we could get a free one in the past from Clifford
@Enrique Chee Yes, but since we have already ordered the air tanks and the one we would get free would probably arrive after bag day. We would have ordered everything on Wednesday, but both Peter and I were too busy to sit down and order things and given that the vouchers expire in a month at the minimum, we decided that they were lower priority.
@Darwin Clark Now that the Raspberry Pi cases are ordered, I am suddenly wondering if we have the Raspberry Pi computers and camera modules already, or if those need to be ordered. What is our current inventory?
@Riyadth Al-Kazily This is the current vision inventory https://docs.google.com/document/d/1VAWjx5tWGk5hjXwvIm2mpfydWXaFvTXtSP7LAbNkdI/edit?usp=drivesdk
@Darwin Clark: perhaps there's also a need for the provisioning assumptions for a single robot? Perhaps it already missed my radar.
2 driver cameras mounted front and back both with 100 deg lenses.
1 or 2 () vision cameras mounted with standard 47 deg lenses. With additional power relays and LED (with12V connection)
All raspi-cameras should have 5V, 2.5A power plus ethernet connection.
@Mark Tarlton posed the question last night: do we need two vision cameras? If the vision control options are focused on hatch-targets, then perhaps one will suffice? If the vision controls request assist for cargo-placement, then perhaps two will be needed.
btw: on inventory - if this is correct we need at least one more 100deg raspicam
My concern is that we have exactly 4 RPis in the list, and with 4 on the robot then those "should" all be in the bag on Tuesday. How do we ensure that we can continue to develop the code after bag day? More Pi!
Also, to Dana's comment, I agree that we need a "How to build a [vision|driver] camera" checklist, so that we can start putting these things together.
And as a note, we (electronics) don't plan to include the relay to turn on/off the vision LED rings. The added complexity doesn't seem worth the effort, and we are in a mode of shaving off some ounces of robot weight. Instead, the light rings will be wired to 12V power at all times. The only outstanding question is: how critical is it to have a regulated 12V source for the LEDs, immune from battery drop during heavy acceleration? If slight fluctuation is OK, then wiring becomes much easier. The plan is for each RPi to have its own 5V regulator (purchased, in the electronics inventory), and the vision cameras can tap in to the 12V supply at that point (near the camera). Otherwise, we need a separate cable for each vision camera, back to the VRM.
regarding bagging - i would think an efficient way to handle this would be to consider this as part of the holdback. Would only consume < 3lbs of our allowance i would guess.
Clearly - the decision on how to allocate the holdback is a leadership_team decision.
As long as the overall holdback is coordinated, I think this is a valid (and valuable) approach. But mechanisms weigh a lot, and if something goes wrong we may reach our holdback limit quickly.
That said, the cameras should be pretty standard, and we should be able to build them up and stick them on tonight (assuming there is enough robot to stick them to). Since instances of the cameras should be very similar, we should be OK with cameras built with similar parts for development.
Plus, I'd like to test as complete a robot as possible before bagging, which includes all RPis, power distribution, and network connectivity...
Since R-Pi are COTS components, they shouldn't count against holdback allowance, right?
@Dana Batali Correct on the 100 deg, I'll order 2 additional. Electronics seem to be organised, the holdback questions is good for @Peter Hall or @Harrison . I'm certainly in the ball park of only needing 1 vision camera, simply given the implementation (if the goal is vertical alignment, we should only need to align one side of the robot, so only one view is needed). As a general point, given coach Chee's viewpoint on the 2nd robot, I've been planning to have parts for one robot, with backups.
@Harrison has joined the channel
The second robot MUST have driver cameras, front and rear, to support driver training (my opinion, at least). As far as I can tell, @Darwin Clark, the team expects you to deliver all cameras. Maybe it’s a good idea to delegate driver cameras to someone else?
@Riyadth Al-Kazily I'm not aginst mounting a drive cam tonight, however I'm certainly OOTL with that work. @Martin Vroom could probably give better insight. It would definitely be unwise to mount a vision camera tonight, there is much more work that needs to be done on that front. We could discuss mounting a vision camera with LED ring, but no SD card, if you are interested in testing electronics (and even then, the pi would not be pulling anywhere close to 2.5A) . Only caveat with that plan, is the SD card has to be easily accessible.
What is "OOTL"? (It's possible that I might be old...)
All cameras must be mounted such that the SD card is accessible (ie, so that we can swap a new one in place between competitions where we kill the Pi...). And at this point it might be fine just to mount an empty camera case on the robot (ie, find out where we can mount it, and fabricate whatever physical interface is required).
OOTL -- obscure, otherworldly teen language? or out on the limb??
@Riyadth Al-Kazily I don't disagree, but I've been playing it by ear with regard to the 2nd bot. We can discuss this at tonight's meeting. (I subscribe to a subreddit r/OOTL, meaning out of the loop... It has a fair amount of subscribes, so I thought it was some popular lingo...)
i really like @Mark Tarlton’s translation!
Do we really need an 8 port network switch ? As opposed to a 4 port ?
Depends on how many cameras we put on the robot. 4 port is fine for 3 cameras.
Can we use the double solenoids from previous year that have less mass ?
Can we use the double solenoids from previous year that have less mass ?
I think we can. We may also want to use one double solenoid for both front legs, and another for both rear. They will fill slower, but that's half as many solenoids required.
And if that's OK (speed-wise), then we can also reduce one PCM.
A few of us discussed today that we should only need 3 cameras: 2 for driving both directions and 1 for vision on the side where game pieces are placed
@Terry Shields @Peter Hall here is the chief delphi link regarding our current encoder E4t-360-250-s-d-d-2 and that we have 3 failures in a short few weeks — aside from recommendations, see the last entry regarding installation advice
@Nora Wilson has joined the channel
Here’s a thread with recommended networking switches if we think ours may be having problems: https://www.chiefdelphi.com/t/small-networking-switch-needed-for-eboard/341716/2
@Peter Hall Information on the encoder breakout board versions from the Talon SRX manual:
220.127.116.11. Encoder (and Limit Switch) Breakout – Blue Revision
The latest revision of the Talon SRX Encoder Breakout Board has
additional level shifting to ensure proper operation with 5V Quadrature
sensors, regardless of Talon SRX hardware revision (see
Electrical/Mechanical Specs – Note 1). These boards are easy to identify
as they are blue.
NOTE: Quad A and Quad B are reversed on this revision. Users
intending to use features that require the Talon’s Quad A pin should wire to
the Breakout’s Quad B pad (Rising Edge Counter for example).
Additionally, migrating from the black to blue revision will cause the sensor
direction orientation to change.
Does one of our robots have the blue boards? The second chassis that we were working on today is using the old (black) boards...
(Also, we are using 5V to power the encoders, based on the wiring @Emerson Nicholas did today. Is that correct for our versions of the SRX hardware revision, or do we need to use blue boards for all of our robots? We should confirm the versions of Talon in the SRX manual...)
According to the specifications, Talon revision 1.6 and up can use 5V sensors directly. Before that version, the Talons may be damaged if used with 5V quadrature encoders.
(Note that the Talon version needs only to be checked on the Talons that have encoders connected to them...)
@Peter Hall @Harper Nalley @Emerson Nicholas We (eventually) should clearly label every Talon that is hardware version 1.5 or earlier, so that we know which ones are compatible with 5V encoders and black encoder breakout boards. Maybe a special zip tie around one of the power leads? Something that won't fall off...
When I get there tomorrow I will mount the main breaker on the second robot. Once that happens we can check the version numbers on that robot.
@Riyadth Al-Kazily @Ronan Bennett @Declan Freeman-Gleason I pasted the test robot talon info on google sheet
@Peter Hall is there a list of available pneumatic cylinders that we have on hand? we're using 4" cylinders for chute lift and hatch grab. I think we have 2 5" in stock. What else do we have in the 6" or 7" range?
@Peter Hall I unfortunately will not be able to make it to tonight’s meeting as planned. Let me know the status when you get a chance.
@Harper Nalley ∆∆∆ (Peter is gone till Monday)
I just pressurized an air manifold removed from one of our robots. Our assembly quality is depressingly bad. Of the 9 threaded connections to the manifold, 5 of them had significant leaks, one of them large enough to keep the compressor from ever reaching shutoff pressure. I no longer have any doubts as to the reason the compressor was running so hot.
I have tightened and sealed the threaded connections so that there are no leaks greater than one bubble every 10 seconds from any fitting and only 4 leaks total. This manifold could be reinstalled in either robot.
I am very concerned that half of the other threaded connections in the pneumatic systems of the robots are equally bad. All should be checked with a soap solution, which is a much better test than listening.
What about the original assembly caused the problems? Is it problems with how the thread-sealing (teflon?) tape was applied to the connections?
Fittings not threaded in enough and no testing after assembly that would have revealed this fact. One fitting could not be sealed just with tightening and required disassembly and application of sealant. The pre-applied sealant on fittings is no substitute for proper initial tightening and sometimes it is not enough even with lots of tightening. All joints must be pressure tested. Pre-applied sealant only works for first time assembly. Fittings removed and reinstalled require a new application of sealant. We should use Loctite 545 on threaded fittings that are re-used or refuse to seal with a factory applied sealant after proper tightening.
I was curious about leak sources in these systems & found this article that indicates wedge-type fittings are superior to push-to-connect fittings when subject to movement & vibration. Something to look into as an option? Link: https://www.airbestpractices.com/system-assessments/leaks/choosing-durable-no-air-leak-pneumatic-tubing-fittings
Paul, I take this on as a failure on my part to check the teams work. It should have been a 100% verification test for threaded pneumatic connections on the manifolds and solenoids. We could even have done these tests early in the preseason. It did not have to wait until now. Paul’s reasoning for the failures make perfect sense.
Chris, the article you link to is good - but walking away from push-to-connect tubing connections would be difficult for us. Maintenance in the interior of the robot is very difficult with all the space limitations. And if we had to replace a tubing run with Ferrule fittings that require a small wrench to loosen/tighten a compression fitting would be a tight space nightmare at competitions. I think a 100% system wide pressure check (especially at threaded connections) is the better way to go.
At 125 psi the push-fit connectors are okay if installed properly. It’s the threaded connections that give no hint of a bad joint. Leak testing is the only true verification.
Having participated in leak-hunting today on the second robot, I can confirm that all leaks were due to improperly tightened fittings (at least one of which did not require a wrench to remove). In addition, lack of Teflon/PTFE tape was also a problem. There seemed to be an assumption that the white paint on the fitting threads was enough to seal the connection. I would like to make sure that we always use at least 2.5 full wraps of Teflon tape on all threaded fittings.
Teflon tape can be a problem upstream of solenoid valves. I know of some air control people in the marine industry who prohibit its use. Shreds of Teflon can jam the moving parts of air valves.
Yes, that is true. My recommendation is to make sure that Teflon is all on the outside of the threads, to minimize the amount of junk in the pipes. But I think that the risk of leaks is much higher than the risk of junk in the valves, so I think we should keep using it. Would the alternative be some sort of "liquid" sealant?
Loctite 545 as recommended earlier. I have used Loctite 638 and Loctite 290 as sealants even though their advertised purpose is something else. We have both in inventory but the down side is that they require heat to undo the threaded connection.
With regard to the white paint that comes on fittings, it is a Loctite product that forms a rubbery substance when squeezed in the threads. If things are not tightened enough, the micro capsules that need to break to effect the seal remain intact in a sort of porous sponge that lets air through. Only one of the manifold connections that I repaired needed more than tightening. The one problem connection is sealed with Loctite 638.
On the topic of custom controls, someone on chief delphi recommended this board that supports 32 buttons and 4 analog pots. Seems like it might be an upgrade from the digital-only board we’ve playing with that supports fewer buttons, while being easier to work with than the TI Launchpad. https://www.ultimarc.com/a-pac.html
@Cruz Strom @Ronan Bennett @Riyadth Al-Kazily @Declan Freeman-Gleason ^^^
This is a solution in need of a problem. I'd like to focus the team on designing a useful control box first, then we can fill it with the necessary electronics to meet the need. If someone provides a box with buttons/joysticks/knobs/meters/lights, I can work with the electronics and programming teams to fill the box with the necessary electronics, and connect it to our drivers station. Have we learned from our first attempt at a control panel yet? (I haven't seen one, so I don't know.)
I think a "cartoon" control panel with a lot of make believe is what we really need. Follow that up with a physical version. That then leads to selecting the electronic "guts", and finally that leads to how it is interfaced to the driver station.
Maybe a great first step would be a "design kit". Something like button-sized vinyl "stickers" (the kind that just stick by static cling) and a whiteboard. Lay out and label the buttons on that, do some driver simulations (command the driver/operator to quickly perform some function to see if the layout is intuitive), and then use that layout as the template to cut a top panel for the control system. Constrain the size such that it fits our driver station, and we can build the lower part of the box so that it can be re-used from season to season. Everything else is easy from that point.
Sounds good. @Cruz Strom am I remembering correctly you already sketched a design? It would be pretty easy to sketch a design in Google slides or even just on paper if not.
@Cruz Strom @Ronan Bennett @Riyadth Al-Kazily I don't have stickers, but I do have a bunch of digital bits and pieces from the past two years trying to influence custom controls to happen. I pulled them into a Google Slides file, and they include a complete toolkit like Riyadth describes. Have at it (I think it's fun). Link: https://docs.google.com/presentation/d/1mNVlv8LKfYuwsqN11DIgq5OYA5VoIBJiyWEetvf8Gqo/edit?usp=sharing
@Mitchell Teresi has left the channel
@Peter Hall @Riyadth Al-Kazily @Terry Shields something we might want to discuss is using a small 60mm computer fan if the compressor temperature continues to be an issue. I am pretty confident that my heat shield solution will work, but just in case it doesn't it might be nice to have a backup plan.
Can you verify in the rules what types of fan are (or are not) allowed, and determine how we can power the fan? (ie, directly from a PDP breaker, or via the VRM, or some other method.) Maybe Chief Delphi has some ideas.
Reminder: We need to install and connect a depth sensor in the robot 2 chute before we hand it over to the programmers. We have the mount printed and ready for installation. I believe we used either tape or hot glue to secure the sensor to the mount.
At lunch I plan on doing more research into it. the problem I think we might have is the rule against all but two brushless motors
I also want to see if the RoboRIO would be an option for plugging a fan in because most computer fans are 3 pin, I've only been able to find a couple two pin fans and all of them are brushless
I know some fans are allowed for cooling motors and motor controllers, but I don't know if they are specific for those purposes. Chief Delphi will know.
Okay, I will do more research at lunch
I did a little research as well, and I recommend we do add a metal "extension" to the compressor (before the push-fitting) to also allow more heat dissipation. I think you suggested a metal T-fitting (with one side plugged), and that would be fine. This combined with a fan would probably work well to keep the tubing from melting/bursting.
Yeah, I may have mentioned this to you, but I was also thinking about trying to create small fins with copper tape. Do we have any of the old motor controllers that used fans @Peter Hall?
Rule R34 states: "Hard drive motors or fans that are: included in any Kickoff Kit, distributed via FIRST
Choice, part of a legal motor controller (including manufacturer provided accessories),
or part of a legal COTS computing device" which leads me to believe that we would be allowed to take a fan off one of those motor controllers provided they are two or three pin and that we can solder wires onto the contacts (I say this because I doubt the fans are connected to the MCs via wires).
I think those motor controller fans might be our best option. I am pretty sure we have some. (I don't think we ever got any of the AndyMark FirstChoice fans... We should do that in the future...)
Did you consider using a higher temp tubing like nylon for the run to the tanks?
yes. I looked into that yesterday and we have some, but not enough to make it from the compressor to the tanks. What I'm looking into is a possible emergency fix for right now before we can hope to receive nylon tubing (unless Ace has some). @Mark Tarlton
Ok .. amazon has some - one day delivery but 100' length. would need to order real soon though.
the specs are 200F, 290 psi 0.18" ID 0.25" OD Nylon12
@Riyadth Al-Kazily okay, I've never seen any fans in the EP area that would be able to fit the requirements. I don't see us getting to this point, but if we absolutely had to, do you think we could take the fans off ATLAS. Of course this would be a very last option.
BTW, I have 12V 2.25" fans if you want to try it. 3 wire with computer pin socket.
@Mark Tarlton that tubing should work, right @Peter Hall?
Are the fans brushless and what is the amperage?
0.110A -- I assume brushless but I'll double check if you're interested.
if they are brushed, that would be perfect
but I don't know if we can put it on the VRM because our 12V ~ .05A ports are full and the open 12V ports are at 2A
DC computer fans are all brushed DC motors and can be connected directly to our PDP without a controller or relay.
@Riyadth Al-Kazily would amperage be an issue?
brushed?? Really? I thought all computer fans are brushless.
No, my brother has some brushed 140mm fans I think and I'm pretty sure my laptop cooling pad uses brushed motors
I agree that we should try to figure it the compressor overheating however given that we have not had this problem before I wonder if we did something wrong on these robots. It might be prudent to double check our work and look for some resources on chief delfi that show the same symptoms.
If this is an issue we cannot fix any other way I think the motor controller fans will be the best option because we already have them and there is already a way to wire them into the components we use.
This is what I have http://www.pchub.com/nonoise-g6015m12b2-server-square-fan-rg-sf60x60x15-w3-12v-0110a-p165419 I have lots of 5V fans and a few 12V. Given that the wiring goes to the fixed part of the fan frame, I'm betting that this is a brushless fan.
Brushless motors do not have a commutator to energize alternating coils on the moving windings. Instead, they have fixed windings with a rotating magnet on the shaft. As such, the fixed coils of a brushless motor must be turned on and off in sequence using an external motor controller. They are typically three-phase, with three sets of coil wires. Since a fan has only two wires, it will either have a brushed motor (using the commutator to sequence the coils), or have some sort of embedded motor controller (which would be a lot more expensive than it needs to be). Since fans are usually speed controlled by an external system (like the computer BIOS, in response to CPU temperature), the two wires are PWM-ed like our main drive motors. The fan motor must be a brushed motor for this to work.
@Harper Nalley Amperage will not be an issue for the motor. It will likely be well below 0.5A in current consumption, with most fans at or below 100mA.
@Mark Tarlton That is a fancy fan you point to. I am probably very behind on my fan motor technology. I am going to find some to take apart and learn something new. (I wonder how they do PWM speed control with two wires going in to the electronics controller... Must be extra fancy!)
@Peter Hall In the past we have seen this tubing issue at least once before, but I can't remember which season/robot. However, most of our old robots had the 4-way connector with gauges and valves mounted to the compressor, allowing the air to cool a bit before encountering the plastic tubing. We can (should) add some extra length of metal tube to the compressor before the fitting. That will help a lot to keep the tube cooler.
I looked again at the theory of fan motors link and noticed "An integrated circuit present on the fan printed circuit board controls the coils. It will energize the coils in a way that will keep the motor spinning. In other words, this integrated circuit will change the magnetic field generated by the coils in such a way that the they will repel the magnet present in the rotor, causing it to spin and keeping it spinning."
ICs -- they're everywhere.
@Harper Nalley Good catch on rule R91. The relief valve must be connected to the compressor via rigid fittings. We will have to make that change on the competition robot.
@Riyadth Al-Kazily good, that adds more metal to the compressor. @Peter Hall should we redo the PTFE tape on the fittings we’re bringing to competition if we have down time today?
The motor will need a motor controller and a breaker on the PDP, both of which we should have in stock. Programmers will just need to manage both motors together, or see if making one a follower of the other will work even though they are not being controlled via PID.
@Mark Tarlton is a cim not powerful enough?
I think the 775pro we're using gives the best power to weight. Weight and space are two tight constraints. We weren't seeing good eject performance. If we can't find another solution then adding another 775 may be the next option
We added the 2nd motor to Robot #1 . We will need the new controller added when we unbag on Monday
We move the depth sensor on Robot #1 from the left side of the chute to the right side to be closer to the electronics. The wiring will need to be rerouted when we install the chute tomorrow.
@Peter Hall @Harper Nalley I will not be able to attend this evening. Please remember to somehow secure battery cables so they do not come loose again. And train the entire team to not pull cables when handling the batteries.
@Emerson Nicholas There are a lot of good articles on the Internets about current limiting resistors for LEDs. Here's one: https://www.evilmadscientist.com/2012/resistors-for-leds/
I bought a cheap multi-servo motor controller, printed a “thingi”, and put the pieces together to get a feel for what servos can do last weekend. I think for light to medium duty tasks requiring some precision they could be a good option. Maybe even scale prototypes. Short video: https://youtu.be/g67pw-Fm5do
In my opinion, servos are EXCELLENT actuators for latches and release mechanisms. Not as good for applying force directly, but they do have their place. We used them as ball "ejectors" in ARIES, pushing the ball into the flywheels, and they worked reasonably well.
I would like the mechanical team to become familiar with what servos (and other actuators) can do, as the mechanical design needs to take the actuator capabilities into consideration. From the electronics perspective, servos are the easiest actuators to wire up, as they plug directly into the RoboRIO, no special cables or interfaces required.
@Peter Hall @Harper Nalley @Emerson Nicholas I spoke very briefly with Terry last night about the "dead robot" problem that we saw in the videos. He said it looks like a communication problem. I suggest that you make sure that you check that the RoboRIO is connected directly to one port of the radio (via Ethernet), and that the radio power connector is solid. (If the RoboRIO Ethernet is going through the network switch, we add another layer of possible failure (the switch and it's power supply)).
If you think the problem is somewhere else, let me know what you've tried, and I'll share ideas. If you've fixed it already, then awesome!
The field folks recommended that we power the radio using both the barrel connector and PoE. They said both can be connected simultaneously without problem and provides extra resiliency to power disruptions
@Riyadth Al-Kazily We fixed the comms issue. It was the radio power. The zip tie around the radio bracket broke and the radio can partially out of its case but the barrel connector was so well attached to the case that is didn’t come with it. @Mark Tarlton we will use both POE and barrel connector next year to ensure this doesn’t happen again.
Did anyone come by the table yesterday with more information on what's inside this sweet controller? I noted that they paired it with an Xbox controller that plugs into this box.
I was reminded by this article on a custom MIDI controller. All the electronics in it could be used to control a robot.
An updated TI Launchpad board became available at some point, with more options for building a driver control station. And it apparently doesn't need LabView to program it. We should keep it in mind, and maybe order one sometime: http://processors.wiki.ti.com/index.php/UsingtheStellarisorTivaCSeriesLaunchPadintheFIRSTRoboticsCompetition
A good presentation on the various issues that can cause your robot to stop communicating with the field, making everyone sad: https://www.midatlanticrobotics.com/wp-content/uploads/2016/01/2016MARFTAKickoffPresentation.pdf
new opportunities for pneumatics plus bling?
It might not meet the FRC pressure rules. It still looks fun for bling.
agreed - i was imagining driver-station bling-gizmo
Somebody on ChiefDelphi Suggested this Pneumatic leak detection device. A little pricey but seems cool https://www.amazon.com/INFICON-711-202-G1-Whisper-Ultrasonic-Detector/dp/B000TRJA8M
What? The "feather on a stick" isn't good enough for you? :slightlysmilingface:
What is wrong with a small pig bristle brush and soap solution? Total investment is about $1.
If you're interested in programming and off-season electronics projects, this kit looks like a good deal. I got one for myself :-)
@Nora Wilson has left the channel
Good general thread on wiring from earlier today. Most may be known, but I'd bet there's a thing or two to learn from the original post or discussion. Plus there's lots of pictures :grin: https://www.chiefdelphi.com/t/favorite-tools-materials-and-techniques-for-frc-wiring/353212
This guy commented on a post I made about doing electrical systems in small spaces. His team, 1126 uses a pair of pre-made polycarb boxes to house their electronics. Scroll down to the comments section to see photos.
That is a presentation 1126 made for their Electronics box
QQ: What are the min pieces I would need to create a pneumatic mechanism testing setup? (like the pneumatics equivalent of our motor testing boards). Bonus points if I could also use the pressure source to air up car tires :slightlysmilingface:. Thanks
@Chris Rininger You need a compressor, piston(s), air tank(s), a valve with a manual switch, pressure gage, and a pressure relief valve (somewhat optional). For car tires, the number of air tanks you need depends on the type, diametre, and use of the tire. For example, an offroading tyre is going to have a significantly higher volume than a track racing tire, but it will also have a lower pressure.
I recommend that we develop a test setup that uses a full-sized 110V compressor (like the one in the robotics lab). It will happily store a lot of air volume, and has a regulator to get to our 60psi working pressure. I picked up some fittings that we should be able to use to connect to the one we have. For actuation I recommend a small electronics module with a battery, some buttons or toggle switches, and standard pneumatic solenoids. Then the experimenter can push buttons to actuate/retract the cylinders. We won't even need a bleed valve, as it will bleed when we disconnect the compressor.
I'm considering building my own kit for personal learning via design/build projects (also still working with servos). Would the solenoid valves with manual push/pull or electric switch control built in be useful for reducing components/simplifying?
A pressure regulator would be nice as well to maintain constant pressure output
@Paul Vibrans has left the channel
QQ: Paul was talking about using one of the Neo brushless motors introduced last year for one of the variants of his summer gearbox design. I know we have a Neo motor or two... Do we also have Spark Max controllers needed to run the Neo? http://www.revrobotics.com/rev-11-2158/ Thanks.
@Peter Hall do we have above spark max controller ?
@Enrique Chee I don't believe we do, will check on wednesday
There’s also a USB mode for testing Neo motors using the Spark Max that, I believe, may eliminate the need for the motor testing board when using Neos for test mechanisms / prototypes not hooked up to a robot control system. It’d be good for a programmer + electronics team member to read a couple of the write-ups teams did on the Neo + Spark Max last year and then figure out how to get them set up for off-robot testing and on-robot use. Seems like a fun project.
Any update on Neo/SparkMax? Teams are switching to 4-Neo single speed drives (including a lot of teams who used to have used 2-speeds). It seems like a tool we need to understand and be prepared to use.
The Neos could be super useful for this year and I plan to include the spark max motor controllers in the parts order this fall. It might be a little late to use them for the drive train. But if we can prove that we can use them effectively before build season starts then I think it would be a great option to consider.
@Declan Freeman-Gleason has joined the channel
@Max Morse has joined the channel
@Jiana Lyons has joined the channel
@Carter Anderson has joined the channel
@Harrison Paul Cate (Electronics/Pneumatics) has joined the channel
@Aidan James Thayer has joined the channel
@Melony Bourgeois has joined the channel
@Dashiell Neff has joined the channel
Good discussion on selecting encoders. Seems worth sharing since we had some encoder problems in the past. https://www.chiefdelphi.com/t/why-choose-which-encoder/365759.
Adam Heard said the CTRE Cancoder or mag encoder with the new hex bore housing (or in a versaplanetary) are top choices for most needs, along with the new motors with encoders integrated.
@Freeman Tuohy has joined the channel
This is the electronics preseason document. New members. Meeting plans are at the top of the document. The document contains a checklist of all of the basic skills we would like new student to know before build season. If you are a new student and would like to review some of the material we have already covered or if you would like to learn even more there are some very useful links to electronics and pneumatics resources near the bottom of the document. https://docs.google.com/document/d/1rn2Na1XzFZ9OmWQp9ZZIAB5FD-3wtCHXK2U-wZgHH4/edit?usp=sharing
Also, if you are a new team member, please chime in on Slack with questions, observations, and ideas. The sooner you get comfortable with this communication channel, the more you'll learn, and the stronger our team becomes. And once we really start talking about stuff, things get a lot more phun.
@Jack Scheiderman has joined the channel
@David Scheiderman has joined the channel
@Emerson Nicholas Here are some pictures of the programming chassis.
Another new low profile encoder: http://www.team221.com/robotopen/product.php?id=155 Supposed to be lower profile and easier to mount than other options
For those of you who might be interested:
Thanks Randy. If this test device comes to market as advertised it is a kick-ass product!! I’m signing up for a couple of them now.
Just wanted to let you guys know that I will be unable to make it to the meeting tomorrow, something came up last minute. Sorry
That’s ok. Hope to see you at FLL this weekend.
And here are a couple of options for some pixels to light up (type WS2812B is the best):
And here is a power supply with enough current to light up a bunch of LEDs (5VDC, 6 amps):
And learn everything you ever wanted to know about NeoPixels ("addressable" RGB LEDs) here:
@Jacob Miles has joined the channel
Andymark made this, we might want to order a couple when the season starts
Have we used this style of encoder before? (mounted on the output side of the CIM)
I know we've used gear-driven encoders on the chassis gearboxes in the past, and have had bad luck with repeatability and reliability since they can be fussy to install correctly. I like the idea that this is an enclosed, apparently modular unit, but we can't use it if it isn't compatible with the gearboxes that we use.
I recommend that we discuss with the mechanical team ASAP to determine what drive gearboxes they are considering, and try to find an easy-to-use modular encoder that fits. This might be it (or the low-resolution version of this, since high resolution in a drive application is not necessary).
Here’s another new encoder that looks pretty versatile. https://www.chiefdelphi.com/t/hollow-bore-absolute-encoder-by-221-robotic-systems/364254