atlas-restoration

@Binnur Alkazily has joined the channel

@Binnur Alkazily set the channel purpose: Communication+coordination to restore our ATLaS to its gloriosity

@Riyadth Al-Kazily has joined the channel

@Cruz Strom has joined the channel

@Justice James has joined the channel

@Ryan Olney has joined the channel

@Harper Nalley @Kenneth Wiersema @Kaedric Holt @Randy Groves

@Harper Nalley has joined the channel

@Kenneth Wiersema has joined the channel

@Kaedric Holt has joined the channel

@Randy Groves has joined the channel

@Harrison has joined the channel

@Kevin Hawkins

@Kevin Hawkins has joined the channel

@Enrique Chee has joined the channel

I'm starting a document that details what we need to do. I welcome comments, especially questions that seek more detail. https://docs.google.com/document/d/1AmPcWapx7P3KLbJXjeJBnOhBpJZQtGSAcz1UN1YNhS4/edit?usp=sharing

@Binnur Alkazily pinned a message to this channel.

@Peter Hall has joined the channel

Do we want to do a full re do of the electronics. It might be nice to have a newer radio. Also what about bumpers on the arms (just a thought.)

Why should we do bumpers on the are isn't there already the lights on the arms

Yes but they don't work

We’re going to be looking at replacing the lights with the new system that we wanted to install on Themis, and if anything we could stand to replace the pool noodle bumpers at the top of the arm

The old radio works fine, as far as I know. And I remember the D-Links being more reliable than the new ones...

I also think we should keep motor controllers as-is (ie, don't put in CAN Talon SRX controllers). The ones in ATLAS work fine, and the RoboRIO can drive them easily. Plug-and-play.

But we should definitely take the time to re-do the wiring to make it as neat as possible. We don't want the public to think we make our robots out of spaghetti... :-)

The biggest challenge might be to rearrange components under the "hood" to see if we can fit in another battery. Or better yet, find a way to mount a battery on the outside so it is easier to change. At the very least, improve the control system cover so that it is held down with (say) velcro, making it easy to open and close in a hurry. (ie, on the street in the middle of the 4th of July parade.)

I had a thought about trying to put the batteries on the side of the robot if there was space, I need to see Atlas though.

We will need to keep in mind that the programming needs to be redone for ATLAS after we change out the brains. The original code for the C-RIO won't run on the RoboRIO (with updated libraries) without a bit of work. So just like in competition season, we're going to have to make hardware changes, then hand the robot over to programmers to get it finished in time for parade season.

@Ronan Bennett has joined the channel

FYI — I am planning weekend of April 28/29 for our kickoff (ATLaS will be at an event 4/27). This weekend I’ll reach out to set up date & time. Thanks all for joining us on this fun & important activity!
dates corrected -- thank you Randy for date review :slightlysmilingface:

@Adam Rideout Redeker has joined the channel

@Declan Freeman-Gleason has joined the channel

@Darwin Clark has joined the channel

@Violet Advani has joined the channel

@Binnur Alkazily do you mean 4/28-4/29?

@Chris Mentzer has joined the channel

@Nora Wilson has joined the channel

yup!!

@Terry Shields has joined the channel

@Ethan Rininger has joined the channel

/poll “Weekend meeting time?” “4/28 Saturday 10am” “4/29 Sunday 10am” “Afternoons, 1pm works better”

^^ planning for the kickoff — thinking 2-4hr meeting time — flexible based on your availability.
Also note Saturday is 4/28 and Sunday is 4/29! (can’t fix the poll…)

@Binnur Alkazily 4/27 is a Friday, 4/28 is a Saturday.

K! We officially figured out that I cannot deduce calendars! Or living in a different year... ~~fixing it, tx!~~ nm, can’t fix the poll…

Saturday 9-noon is the Islandwood volunteer event.

Saturday 10-3 is also the IRS programming competition that Darwin, Ronan, and I are going to.

Here is the plan for the kickoff next weekend —
- We’ll do two kickoffs: Saturday (4/28) & Sunday (4/29) @10am. Targeting a 2 hr meeting, unless we are on a roll and you want to stay, i.e. you have the flexibility.
- You are welcome to come to both meetings, either, or none (though would like to see you :smiley: )
- I may put out a poll prior to the weekend to get a appropriate headcount (though, we all know how great I am w/ calendars now…)

Once we have the tasks identified we can break into groups. If we need parts, we’ll identify the logistics for getting them during the week.

We are meeting at: 753 Village Cir NW (cell for Binnur or for Riyadth )

K — hope you’ll be able to stop by in the am

And just to be sure, will these meetings be at the robotics room or some other place.

Awesome, I'll be at both

@Harrison They will be at Binnur and Riydath house, which is at the above address.

753 Village Cir NW

K great

I'll be there on Sunday.

^^ yup, my house is the backup robotics lab :wink:

I will be there on sunday, and if you go beyond 12:00 on saturday I will try to make it then too.

I will also be there only on Sunday

I will be there on Sunday, Not Saturday

I can attend with the same schedule as Lucas

I can be there Sunday and saturday

I’ll be attending both

@Darwin Clark Are you not doing the IRS thing? That's also on Saturday.

@Declan Freeman-Gleason I never learned the difference between Saturday and Sunday. I misspoke.

I will be at both also

BTW one thing I will say is when I read I do a scan read and will miss small detail sorry about that.

No worries! When I double check my calendar for the dates, I still get it wrong! Twice! :/

Who is taking charge of gathering all the stuff to deliver to Binnur's home ? I suggest those planning to attend meet on Wed. afterschool to gather the stuff.

We will also be at the Wednesday meeting, and can pick up stuff we will need. We just can't fit the robot in our car :-)

I can drive the robot over during the week

That’s already been taken care of, Jon will be transporting the robot Friday. I can gather items from the list Wednesday, but I think we’ll be wanting to get other things after our first few meetings.

Absolutely. We don't know everything we will need yet, so we will likely make a more complete list later.

And it is unlikely that we will need parts on the first weekend. That time will be spent planning, documenting the design, and probably disassembling the pieces we know we won't need (like the CRIO controller)

Still, it would be better to do this now rather than later. I’ll head in Wednesday after school to gather items, and @Peter Hall , I would like you to be there, as I want double confirmation on most of the electronics parts that we’re confident on using.

@Kenneth Wiersema Can do

I can come on Sunday from 10-11:15

I’ll be there on Sunday too

@Declan Freeman-Gleason @Ronan Bennett since the programmers have to rewrite the code anyway, are we going to use gradlerio?

according to this thread on chief delphi, gradlerio + visual studio code are going to become the new defaults. this could be a good chance to familiarize ourselves with it.

https://www.chiefdelphi.com/forums/showthread.php?p=1759892#post1759892

Funny, that's exactly what I was planning to switch to! (Or Atom)

For most, the greatest difference will be the IDE change, and faster deploys (if you choose to switch; you can actually use whatever you want.)

No eclipse!! Yes, please!!

It was actually fairly easily possible this year with what we had, but it was easier to standardize on a sub-standard IDE than change mid-season. Still, I'm happy to see Eclipse go!

Also, are we planning to rewrite Atlas's code in gradleRIO or whatever we are using now (I think it's ant?)

Yes, we should use gradleRIO. It doesn't affect the code, but we should get used to it (there should be no significant change.)

gradlerio is just the build system, as far as I can see. What IDE are we planning on - I see mention of visual studio?

Yes, it's just the build system. It replaces Ant. We're not as bound to anything anymore (we weren't actually that bound to Eclipse either), so we can probably just let people choose. Both Atom and Visual Studio Code are pretty good choices.

Atom - is that atom.io?

Yes, it’s atom.io. Atom is more of a text editor than a full fledged IDE right? Does it not really matter that much to have fewer features?

I prefer to use vi anyway - Atom looks like it might be a step up.

I like the install animation ... :slightlysmilingface:

I was just thinking for build season what the best option would be to recommend to beginners if we’re moving away from Eclipse

Never played around with Atom - just installed it. Almost anything is probably better than Eclipse. I think that it's gotten way to complex for its own good. Of course, some of that is because Java is complex.

The atom user interface is incredibly simple, I think it would be a good fit for beginners.

I've been playing around with both of them, and they seem very similar. I slightly prefer Visual Studio, but only because it's the default for FIRST next year.

Atom is pretty simple, but check if it has suggestion/quick fill for wpi library. This is one of the nice things about eclipse, in that you don't have to remember all the library+methods, the IDE can suggest it for you. They may provide plug-ins, and that would be a good option

same applies to visual studio

I can't find either, although I expect some form of it will come out for visual studio before 2019.

we got the robot! quick reminder that it is open-garage ATLaS day this Saturday and Sunday starting at 10am.
- If you are helping w/ earth day, thank you!
- If you are heading to programming competition, good luck!
We look forward to getting our hands dirty and get started w/ Atlas. And, if you have safety glasses, please bring them.

I'll be a little late

During the Atlas Restoration meeting, this is what we decided on what we want to do. Green means finish before July 4th, and red means we want to do it someday.

We also added cading atlas for someday but it was added afterwards

The bumpers might be a good Pre-season project for next year.

Training new people

How important is the battery voltage display on the driver station? I think it might be very important (as in "MVP" level of importance), because it is important for the drivers to be able to see when the battery is getting low.
I ask this because I think that we need to use one of the modern PDP boards in order for the RoboRIO to measure the battery voltage...

(The old CRIO controller would read the voltage through a special analog input port, but the modern software doesn't do that by default...)

We used it during the driving practice as a way to tell when we needed to change the battery. Might be useful during events too.

we had a nice small kickoff this morning. Tomorrow we’ll plan to wrap up by 1pm. Agenda is to 1) review the plans from today; 2) break into groups to start working on each of the areas; 3) come back together as a team to review progress and identify next steps for the week and the next weekend.

We’ll see most of you tomorrow!

Lucas the problem I have is based off the time we have with pre-season, I do not believe that that would be a good use of time, especially because we may only need one more person on bumpers. Saying that Nora is going to be on bumpers again.

First, I’d argue additional people. Why? Because you and Nora have done it before, therefore one of you could do one set, and the other could do the other set. Second, there have been discussions about increasing our pre-season activity.

Ok

That makes sence

^^ btw, we are mostly in the garage -- so, bring sweaters for warmth.

Any talk about the driver station for ATLAS ? e.g. label all the buttons on the joystick. Using a laptop with better battery life than the Classmate ? What is the battery life on the current laptop (Classmate ) ? Thanks

We've started a discussion on the driver station, including making easy-to-use controls (with labels and cheat-sheets for non-experts). We will need to update the software on the driver station to the latest NI version. And that might mean we need to update the OS on the Classmate. And if that can't be done, we may need to update to a new(er) laptop. I'm not sure what the battery life of the Classmate is, but it's probably not great.

FYI. We do have an extra battery for the Classmate.

Sorry, I'm running a bit late. I should be there in 10 minutes.

Programmers should fork https://github.com/Spartronics4915/Atlas and clone that fork onto their machine. Then you should `cd` to the fork and run `git remote add upstream https://github.com/Spartronics4915`.

Then (while the working directory is `Atlas`) you should run `./gradlew` (if on Mac or Linux) or `.\gradlew.bat` from PowerShell if on Windows

@Enrique Chee team has a good list for the week. It includes moving off from the classmate to Helios for driver station for better maintainability. They have plans to pick it up this week.

Who (today) was going to follow up on the infrared sensor to detect a ball is ready to launch? Someone needs to find out what sensors we have in stock, and figure out how to mount one somewhere near the radio (pointing to where the ball is). We forgot to confirm that workstream before we left today...
(The programmers will need to know soon what type of sensor we are going to use, and where it is wired up to on the RoboRIO)

@Riyadth Al-Kazily that would be me. I do not think that we have an extra in the shop. As it does not show up in the inventory. However it is possible that the inventory is not correct. So I will church in the shop when Kenneth and I go to gather more materials this week.

If we cannot find one I suppose we will have to order one.

OK. Can you check what stock we have for ultrasonic sensors, and bring them next week? (Along with any IR sensors you can find, if any) At the very least we can hook up an ultrasonic sensor and see if it works well enough. (The biggest challenge for us is how we mount it to the polycarbonate on the back panel - maybe we can drill some small holes and zip-tie the sensor on)

Yes I will take a look

great work today! Next week, lets meet on Saturday (5/5) @ 10am. We will go till 1pm.

@Declan Freeman-Gleason @Darwin Clark @Ronan Bennett and programmers, I added an Overview.md file to capture the system requirements. Please review, add/modify.

The infrared sensor that we used on Themis is the Sharp GP270A41SK0F with a range of 4-30 cm. I bought 5. I think one got broken, and there were at least two others used on the two robots. I gave the rest to Peter. I don't know whether they all got used or not. Should I order more?

We should have them . @Randy Groves I will order them if needed. I tried a month ago but they were out of stock .

K - would you like me to send you the order info from my order?

@Randy Groves Sure. Thanks . Is it this one ? https://www.pololu.com/product/2474

That's not the one I ordered but it would do, as long as our detection is greater than 4". And perhaps we should have both. Here's the order info for the one I ordered (including the 3-pin pigtail:

Oops: https://www.pololu.com/account/viewsalesorder/1J326985?s=423ab82a

@Kenneth Wiersema when are we going in to collect this stuff?

I would like to gather these items after the leadership meeting on Thursday or after school Friday. @Ronan Bennett @Peter Hall I would like you to come in to help with this. @Harper Nalley you are free to come in to get the bumper fabric.

I’d like to use your car Ronan to store the items until Saturday preferably.

Okay, sounds good

@Kenneth Wiersema: I have a doctors appointment at 4:15, so I'll give you a list of stuff.

I can't make it any time this weekend.

Neither can I, something has come up. I will be giving information pertaining to the re-mounting of the kill switch to Kaedric, and bumper repair to Harrison

@Peter Hall @Kenneth Wiersema Do any of you need reminders to pick up supplies for Atlas? I didn't see any posting confirming that items are on hand. And @Peter Hall I am especially interested in the 24V solenoids...

We do have the 24 volt solenoids.

Kenneth can confirm but I think that we managed to get everything electronics on the list.

Everything electronics was gotten, however we couldn’t find a new front plate. Also I couldn’t find the u-bolts, so someone would need to get some that have a diameter of .5 in or a little more. We need 2 or more. I grabbed a small piece of angle bar for a latch, and some flat bar for the main breaker.

Did we get some scraps/pieces of polycarb? I think with and without holes would be useful, if for nothing else but to make some mounts for bits and pieces as we go along.

We have some without holes, didn’t grab any with holes. It’s just one piece, but we’ll have left over from making the toilet seat

for those showing up tomorrow/Saturday, we’ll be meeting from 10am-1pm.

^^ at al-kazily garage

I'll be a little late today

Team - fun day today. Programmers, make sure to pull the latest updates from Atlas repo.

reminder, no meeting tomorrow/Sunday 5/6.

Next meeting - Saturday 5/12 (and note, next Sunday 5/13 is Mother’s Day)

@Kenneth Wiersema @Peter Hall I didn’t see your reminder list posted, so here it is...

@Peter Hall Also could you bring the bling wiring harness that I made? There should be two of them, possibly both on the robots. They have a 3 pin connector for the LED strip, and twisted pair wiring going to power and Arduino, terminated in ferrules.

Thanks, I want to see about heading in on Friday to pick the stuff up. I didn’t have the fuses on my version.

Those were added at the end, and I think Peter was meaning to grab them (with the wire)

Yes

Okay, same deal as the last few times, and Peter and I will be the only people needed to get things

I will not be around Friday afternoon. So please grab Wed. afterschool or Thurs.

Thursday then

thank you!

reminder that our next meeting is May 12th. We'll meet from 10am-1pm. Same bat time and same bat channel . Hope to see you on Saturday!

@Kenneth Wiersema if we cannot meet after school today please see me Friday morning to get stuff for atlas for sat.

@Binnur Alkazily I'm not going to be able to get to this week's meeting until ~12:00... The old HELIOS laptop is fully set up, and I'll bring that when I come. Camden will need to start writing commands. The teleop one should have one that contains an instance of a `Joystick` and just calls the `Drivetrain::driveOpenLoop` method based on that. The quick turn command should have an instance of WPILib's `PID` class, whose input is coming from `Drivetrain::getIMUHeading` and whose output just goes to `Drivetrain::driveOpenLoop`.

I won't be at the meeting on Saturday, unless I can get a ride from someone.

I can give you a ride

Just tell me where / when I should pick you up

@Ronan Bennett thank you :)

K - let’s see how far we can get to.

@Kenneth Wiersema I have a meeting till 8:30 am Friday morning. So I can let you in after 8:30 am .

Okay, I’ll be there then

@Jack Chapman has joined the channel

I am not going to be there either

I will not be able to attend the meeting this morning, sorry for the short notice.

@Tarkan Al-Kazily has joined the channel

I'll be about ten minutes late.

For the next meeting we will need these items, and I also have two pieces of sheet metal that I need to drill around a 5/8 in hole in. During the meeting we took the launcher arm off of Atlas to replace the bearings that were in it. Once we had taken it off, the bearings fell apart, and were cracked and split in multiple different places.
For a preseason project we might need to replace the channel of arm, and re-drill the bearing mounting holes.
Right now I’m thinking we do this after the leadership meeting thursday.

The cracked bearing outer ring.

And the other pieces.

I just wanted to clarify, is there a meeting tomorrow?

No there is no meeting scheduled tomorrow/Sunday/ Mother’s Day. Wishing fun weekend to all

Programmers — good work today! next week, we should be able to test the harvester & drive train controls. Next week,
- we’ll add commands & joystick controls (I did a pass for the launcher) for drive train and harvester
- we’ll incorporate dashboard updates w/ robot code
- test the new driver station
- other details and tests that is needed to polish the robot code

We’ll meet Saturday 5/19 @ 10am — same bat place

Sorry that I wasn't there today - I had a prior commitment and totally forgot about the meeting. I'll remember to communicate if I won't be there next time.

thanks for the follow up!

If you guys need anything from robotic room for this Sat . please pickup after leadership meeting on Thurs .

That’s what I had planned. I’ll grab whoever I need at the meeting

I have the parts for this weekend. And I got the holes drilled.

Team — reminder that we are meeting tomorrow/Sat 19th 10-1pm. programmers, I have been slowly recovering from a nasty cold and will need to take it easy tomorrow @Declan Freeman-Gleason @Ronan Bennett @Darwin Clark if you make it, robot should be ready to test drive train and harvester controls tomorrow.

I can come. Very excited to test, and I hope you feel better soon!

I can't make it.

@Declan Freeman-Gleason me too — and thank you!

I won't be able to attend tomorrow. We have a beach naturalist volunteer session tomorrow at Lincoln park at 12:30-4.

For those following along a home, we had a great day today. Atlas is coming back to life. We powered him up and there was no emission of magic smoke. First up was the reconfiguration of the radio, and then loading of the new program. The drive motors are all responding to programmers, and the input sensors are being read. And amazingly the pneumatics don't seem to leak! We have successfully tested drive motors, and harvester pneumatics. Next up will be the harvester motor, the launcher pneumatics, and then (finally) the launcher motor (which has been temporarily disconnected for safety).
Mechanics did great work today reattaching the launcher arm (but it will need some work down the road, probably at the school workshop), and also with the new "toilet seat" and battery access panel. But before the launcher motor can be tested, we will need to add a spacer to the launcher limit switch, and mount the second (redundant) launcher limit switch.

To briefly add on: now that we can deploy code, the plan for programming next week is to test all of our subsystems (including things like safety checks), to finalize / rethink driver button mappings, and to add values / sliders to the dashboard.

I have tested the repaired bling strip (after fixing my Arduino program again...) and it works! However, it is a 150 LED strip, which needs more power than the old 80 LED strip, so I ordered a higher power converter to put on Atlas next weekend. (From the Internets I found that you should estimate 60mA per LED on these strips (0.06A), which means we need up to 9A to turn on all the LEDs at full brightness.) Our old converter is for only up to 5A, so it can only be used on shorter bling strips, or strips with more space between LEDs. The good news is that Atlas will be twice as bright as he was back in the old days. (The bad news is that the battery will run down a bit quicker :-)

our next get together is on Saturday 5/26 @ 10am-1pm. Same bat channel.

Programmers/Darwin — I updated the Launcher to include support for Network Tables — assuming passes your sniff tests, here is the basic plan:
1. Initialize and periodically update output to network tables via smart dashboard in your subsystem
--> Subsystem init needs to implement outputToSmartDashboard() methods which sets up the dashboard keys
--> Robot.java @ teleopPeriodic periodically calls the outputToSmartDashboard() for your subsystem
2. Implement updateFromSmartDashboard() in your subsystem which resets any of the default values in your subsystem, such as launcherWinderMotorSpeed
--> Robot.java @ teleopInit calls the update method to reset the defaults prior to starting teleop

Tomorrow, lets review this process+code and implement for Harvester, as well as general code review. See you in the morning!

Declan — any thoughts on why github seems to be defaulting to squash & merge for PR within github? Last weekend, Riyadth & I came to conclusion that squash & merge can result in unexpected merge conflicts… We can discuss in the morning.

@Binnur Alkazily That looks most excellent. I'll update all the keys on the dashboard, and hopefully test simultaneously with the robot code tommorow. Thanks!

I’ll be running about a hour late, I need to help my parents with something.

Wifi password is: t0p;J1ngle

@Darwin Clark pinned a message to this channel.

I have something going on today, so I can't be there. Sorry!

I’m sorry, my alarm didn’t wake me, be there in a few

I think it's t0p;J1ngle

Thanks, forgot what the slash through the circle ment...

nice job today! we tested the subsystem functionality, and we are mostly there — next week we’ll meet on Saturday 6/2 @10am-1pm and what folks think about having pizza after that? Let us know! Plan for next week:
- Validate & finish LED Arduino functionality
- Finish Atlas Dashboard
- Finalize & label OI buttons
- Test & validate button controls
- And, whatever mechanics want to complete (elastic tensions for launcher, …)

At the end of our meeting, we should be ready for the July 4th parade! WOOT!!!

Great ! Thanks Alkazily !

Wow! That’s awesome. May I have a list of everyone who contributed? Thanks!

pushed a few minor updates to Atlas upstream —
- @Ronan Bennett made couple of minor updates to intake commands (https://github.com/Spartronics4915/Atlas/commit/1016f039b1589e8921e6f7489a20e0686a68f0c7)
- updated Overview.md w/ the current state of buttons — figured it maybe an easy way to review and modify next week

@Ronan Bennett @Declan Freeman-Gleason @Kenneth Wiersema pls send me & riyadth email w/ who contributed and we’ll forward to Kevin. Pls include anyone that you also worked with during school hours. Thanks!

duplicate entries are fine — riyadth & I’ll merge the list

@Binnur Alkazily Unfortunately I’ll miss most of the meeting on Saturday - I have SAT subject tests that morning. If the meeting goes on a little past 1:00 I should be able to come for the end. From what I could tell from last meeting, the harvester commands and subsystem are working as intended - all that’s left is assigning final button mappings.

I can't make it either, I'll be in a parade in Gig Harbor from 7:00 to 1:00.

I won't be there either unfortunately.

I can't make it either

I wouldn’t be able to make it-SAT test. Is Sunday a more viable option right now?

Looks like we're going to be helping friends move that day ...

I meant Saturday. Might spill over into Sunday, but if not, Sunday is a better option for me.

we can meet Sunday @ 10am -- let me know if you will be able to attend.

I can make it!

I can make it

I can be there.

I can be there, but I'll have to leave and come back in the middle for a short guitar lesson.

I can't make it this time, but any other weekend after this I'm free Sunday

I can’t make it.

We'll meet at 10am on Sunday 6/3 -- same bat channel. We'll get pizza @ 1pm and wrap-up around 2.
Lets get this robot rock&rolling!! :robot_face:

For those taking the SATs -- good luck!

To clarify -- we will not be meeting on Saturday 6/2

thank you gentlemen!

I think I can make it

Sorry I know that this is so last second but I can't come my parents planed something last second on m

Me

Programmers — I tested & pushed the OI controls to upstream. Other than bling, everything is now operational. @Riyadth Al-Kazily will share his findings on bling in a bit

@Declan Freeman-Gleason your code changes (output not updated enough) and throttle controls work — I did not test the drive straight mode.

Great! I can't wait to see everything working together.

About the bling...
I did some refactoring of the Arduino code, and things were not working the way I expected. Basically, when very "active" bling functions are executing, I could not switch to other "animation" sequences.
It turns out that the NeoPixel (and FastLED) libraries, which control the LED strip, turns off CPU interrupts while it does its work. While that is happening, any character sent to the serial port is lost (from the RoboRIO or from my laptop during testing).
I don't have an easy solution to this yet. We could add a second Arduino, and have the two communicate with each other via digital I/O pins (so one will read the serial interface, and the other will drive the LEDs). It's a bit more complicated than I'd like...
We may also be able to switch from an Arduino to a more "capable" system like a Teensy (which runs faster, and has better hardware), but that may only be a band-aid for the problem.
I'll think it through, and in the meantime I'm happy to explain more of the problem in detail.

And if we really have to, there is a product that can make the LEDs light up for us:
http://www.revrobotics.com/rev-11-1105/

I looked more at the options of a Teensy, or Adafruit Feather/Trinket M0, and found that someone has solved our problem. Those systems (and others like them) include system peripherals called "DMA" (Direct Memory Access), which allows memory to be moved around without affecting the CPU. Using this peripheral would allow the CPU to drive the LEDs while simultaneous reading characters from the serial port. I will dive deeper and see if this is the way we want to go.

I have ordered an Adafruit Trinket M0 to give it a try. I'll let everyone know what I learn. And for anyone who wants more information than they can stand on Neopixel LEDs:
https://learn.adafruit.com/adafruit-neopixel-uberguide/the-magic-of-neopixels

Thank you @Riyadth Al-Kazily

@Riyadth Al-Kazily Out of curiosity, why do we not experience this same issue on the main robot? Is there a slightly different system on the robot?

My unsolicited answer/understanding: In terms of system differences, the Arduino is pretty much running without an operating system, and lacks most of the scheduling capabilities that might come with one. On the other hand, the RoboRIO is running a modified Linux kernel (NI Real-Time OS) that provides things that the Arduino does not, like threads and processes. Better scheduling could be the reason we don't get issues like this on the real robot, but it could also be because we don't run anything with timing requirements this tight (in this case it's probably the latter, after reading the article Riyadth posted about the NeoPixel.) Riyadth can fill in that last bit/any holes in my explanation.

So are you saying that we didn't have this issue on the main robot because there was no timing-specific bling? If there wasn't, I could understand dropping the Arduino on the robot and having it do its own thing, but it was my understand a group involving Adam, Ryan, and Cory were responsible for writing some bling code auduino-side that was designed for integration with the RoboRIO.

All the bling hardware we've used is timing sensitive, which (correct me if I'm wrong Riyadth) is why we offload the actual LED control to the Arduino (the RoboRIO probably can't handle it in terms of timing.) This offloading makes it so the RoboRIO doesn't have to do any timing sensitive work, it just sends some bytes over serial. This is partly why the RoboRIO doesn't have this issue, but the other reason is that the systems have different capabilities and uses.

@Declan Freeman-Gleason @Kenneth Wiersema @Enrique Chee who is the likely parade driver? I like to get Atlas driven and tested w/ main driver or representative prior to returning it.

We are meeting this Thurs in leadership and they can decide then .

Cool! Let me know and we’ll schedule test drive this weekend. Thank you!

I'm not sure I understand the question completely, but I'll explain what's going on. First off, @Declan Freeman-Gleason’s description of the RoboRIO (with Linux and preemptive multitasking) vs. the Arduino (with a "bare metal" "main loop" architecture) is correct, and partially responsible for some of what we see: When the Arduino is busy running a bling sequence, it doesn't allow a second thread to check for new commands. This can be overcome with some creative programming, which is what I attempted to do after everyone left on Sunday. What I found was that even with creative programming, the Arduino is just not fast enough to both play bling sequences and read the serial port. The LED strips have such tight timing requirements that the library functions will turn off hardware interrupts while shifting out the bits, and without hardware interrupts enabled, the serial port does not receive bytes.

The Arduino has a 16MHz clock to run machine code instructions, but the RoboRIO has (I think) a dual-core CPU at nearly 1GHz, so it can juggle a lot more stuff. So, why don't we drive the bling directly from the RoboRIO? It's because of the Linux kernel, and preemptive multitasking. Since multiple tasks share the CPU, the RoboRIO uses a timer to stop the current task, and then start up another task to let it run for a while. Then the timer ticks again, and the next task in line gets to run for a short while. These timeslices are a millisecond or so in length, but this system allows the kernel to provide the illusion that multiple things are running simultaneously. But the bling strip can't tolerate even a single 1ms gap in communication, let a lone random gaps all over the place. So we need a more "deterministic" computer to shift the bits out.

The path I'm following is to use the Adafruit Trinket M0 system, which is a small board like an Arduino, but with a more powerful CPU. I think this CPU has a 48MHz clock, and also uses the more powerful ARM instruction set (a subset of the machine code used on the RoboRIO), but that's not what makes this work. There is also hardware support for input/output that takes the load off the CPU. A bling library for this chip uses a subsystem called "DMA" (Direct Memory Access) which acts like a tiny second core. It can move memory around, but can't do math on that memory. So the main CPU programs the DMA to send data bits out to the wire that the bling is connected to, and off it goes, happily sending out perfectly timed bits. In the meantime, the main CPU can answer interrupt requests from the serial port, and that lets it respond to requests from the RoboRIO to change the bling pattern.

Note that the robot also does need some precisely timed functions: PWM to the motors, and reading encoders that could be sending data in at high speed. When you use encoders to measure speed, the pulses need to be precisely timed. The RoboRIO does most of that timing sensitive stuff with its built-in FPGA (Field Programmable Gate Array), which is a big chip that has a lot of AND, OR and NOT gates that can be wired together by downloading a "program". National Instruments pre-programs that chip to do all the neat, high-speed stuff that the RoboRIO needs to do. It is entirely possible for them to even make that FPGA handle NeoPixel bling strips directly at some time in the future, but we don't have that functionality in there yet, and we don't have the tools to do it ourselves. In fact, I think some of the robot safety features are implemented in that FPGA so that they are immune to CPU crashes.

Side note: Another potential fix for our problem would be to use a more "static" communication mechanism between the RoboRIO and the Arduino. For example, if we wired 4 of the Digital I/O pins from the RoboRIO to 4 digital pins on the Arduino, the RoboRIO could post a 4-bit binary number to those pins, and the Arduino could read them between bling updates. That way the message stays around until the Arduino is ready to read them. With 4-bits of information, we could have 16 different bling "animations" to choose from. This could be enough for us, but I just didn't like the idea of having extra wires that could make the system less robust. Still this is a reasonable backup plan if the Trinket doesn't pan out.

That definitely explains some of the things I was seeing.

@Kenneth Wiersema @Declan Freeman-Gleason have we identified a representative driver for our test drive of Atlas?

@Peter Hall will be the driver of Atlas during the parade.

I am available both Saturday and Sunday at our usual meeting times. So whenever works better for the others. @Binnur Alkazily

@Peter Hall let’s target Saturday at 11am. Crossing fingers it will be quick. @Declan Freeman-Gleason @Ronan Bennett @Darwin Clark I think we need two programmers, let me know if you are available

Do you want me to come to retension the launcher?

I would love to show up, would like to Q&A stuff about the driver station with @Peter Hall

@Kaedric Holt launcher seemed fine and can be easily adjusted prior to parade start. Hopefully there is nothing to do for mechanics but if you like to come by, you are welcome to it. It is your choice.

I can come... I think the drive straight for a long time with throttle control might be a useful command for Peter during the parade... Do we think it's worth it/do we have the time to test that?

Yes - we can spend time testing it.

I can come, but if we’re just test driving I don’t think I’d have anything specific to do

That sounds useful I think that we should try to get it to work.

@Binnur Alkazily that time sounds good. I'll be there!

great @Peter Hall @Declan Freeman-Gleason @Darwin Clark see you tomorrow @ 11am

thank you!

@Ronan Bennett you are always welcome to hangout — you know where to find us if you are bored :slightlysmilingface:

@Binnur Alkazily sounds good

@Binnur Alkazily Hey Binnur, I'm really sorry, but I've had a scheduling mishap on my end, and I won't be able to make it. I will be exta sure to make contact with peter outside of that meeting and discuss the driver station

we are ready for an Atlas pickup! WOOT!!

Yes, woot!

(Why didn't we just program an autonomous routine to let it drive itself back to school? It could have towed the robot cart full of the supplies and driver station...)

@Declan Freeman-Gleason Here is the MTG sorting "robot" I mentioned (posting here in case others were interested):
https://hackaday.com/2018/05/17/automatic-mtg-card-sorter-separates-rags-from-riches/

Phunny ! @Binnur Alkazily @Riyadth Al-Kazily when will it be convinient for the students to pick up ?

@Jon Coonan can you pickup ?

@Jon Coonan has joined the channel

I’ll need to coordinate w/ @Tarkan Al-Kazily as he will be home this week — so, potentially any time between now and wednesday night. For the following week, it would be tuesday the 19th or after.

@Kaedric Holt @Harper Nalley and @Peter Hall retensioned the elastics, fyi

We’re looking at potentially picking up Atlas today or tomorrow, and then having them hang on to Atlas until Monday, where we can put it in the trailer. @Cruz Strom can your car do it?

probably better choice, as @Jon Coonan might take atlas directly to his graduation party :wink:

I can pick it up

@Binnur Alkazily, when would be best for you this afternoon or evening?

@Cruz Strom How about after 6:30pm tonight? I'll be around

Will be there

Thanks @Cruz Strom . When can you deliver on Mon .

@Kaedric Holt We retentioned the the intake elastics but not the launcher elastics. Those should still be done before the parade.

Should we increase or decrease the tension?

I would say increase.

It worked fine for testing but for an actual event i would like the ball to go further.

The reason I ask is because we won’t have that much room in the event

We don’t want to shoot the BSF people

I can do it before the parade, won't take more than ten min.

I think they should stay where they are.

They’re powerful enough to shoot, but not too powerful

Since @Peter Hall is the one driving, it should probably be his decision.

How about we fire the ball before the parade and pay attention to how far it goes. Then we can make a decision.

@Declan Freeman-Gleason archived the channel