@binnur set the channel purpose: Communication+coordination to restore our ATLaS to its gloriosity
@Harper Nalley @Kenneth Wiersema @kaedricholt @randygroves
@Harrison Gilmore 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
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
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.
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 🙂
@adamrideoutredeker has joined the channel
@declan_freemangleason 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 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.
*Thread Reply:* K — hope you’ll be able to stop by in the am
Saturday 10-3 is also the IRS programming competition that Darwin, Ronan, and I are going to.
@channel Here is the plan for the kickoff next weekend —
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
And just to be sure, will these meetings be at the robotics room or some other place.
*Thread Reply:* 753 Village Cir NW
*Thread Reply:* ^^ yup, my house is the backup robotics lab 😉
*Thread Reply:* BTW one thing I will say is when I read I do a scan read and will miss small detail sorry about that.
*Thread Reply:* No worries! When I double check my calendar for the dates, I still get it wrong! Twice! :/
@Harrison Gilmore They will be at Binnur and Riydath house, which is at the above address.
I'll be there on Sunday.
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
*Thread Reply:* @Darwin Clark Are you not doing the IRS thing? That's also on Saturday.
*Thread Reply:* @declan_freemangleason I never learned the difference between Saturday and Sunday. I misspoke.
I can attend with the same schedule as Lucas
I can be there Sunday and saturday
I’ll be attending both
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 :-)
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.
I can come on Sunday from 10-11:15
@declanfreemangleason @ronanbennett 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.
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.
I prefer to use vi anyway - Atom looks like it might be a step up.
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
*Thread Reply:* I can't find either, although I expect some form of it will come out for visual studio before 2019.
@channel we got the robot! quick reminder that it is open-garage ATLaS day this Saturday and Sunday starting at 10am.
We also added cading atlas for someday but it was added afterwards
The bumpers might be a good Pre-season project for next year.
*Thread Reply:* 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.
*Thread Reply:* 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.
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.
@channel 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!
^^ 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
@coachchee 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 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)
@channel great work today! Next week, lets meet on Saturday (5/5) @ 10am. We will go till 1pm.
@declanfreemangleason @Darwin Clark @ronanbennett 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?
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:
@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. @ronanbennett @peterhall 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.
@Kenneth Wiersema: I have a doctors appointment at 4:15, so I'll give you a list of stuff.
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
@peterhall @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 @peterhall I am especially interested in the 24V 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
@channel for those showing up tomorrow/Saturday, we’ll be meeting from 10am-1pm.
Team - fun day today. Programmers, make sure to pull the latest updates from Atlas repo.
@channel reminder, no meeting tomorrow/Sunday 5/6.
Next meeting - Saturday 5/12 (and note, next Sunday 5/13 is Mother’s Day)
@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)
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.
@channel 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 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
*Thread Reply:* K - let’s see how far we can get to.
I won't be at the meeting on Saturday, unless I can get a ride from someone.
*Thread Reply:* Just tell me where / when I should pick you up
*Thread Reply:* I am not going to be there either
@Kenneth Wiersema I have a meeting till 8:30 am Friday morning. So I can let you in after 8:30 am .
I will not be able to attend the meeting this morning, sorry for the short notice.
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.
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 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.
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
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 @declanfreemangleason @ronanbennett @Darwin Clark if you make it, robot should be ready to test drive train and harvester controls tomorrow.
*Thread Reply:* I can come. Very excited to test, and I hope you feel better soon!
*Thread Reply:* @declan_freemangleason 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 :-)
@channel our next get together is on Saturday 5/26 @ 10am-1pm. Same bat channel.
*Thread Reply:* I’ll be running about a hour late, I need to help my parents with something.
*Thread Reply:* I have something going on today, so I can't be there. Sorry!
Programmers/Darwin — I updated the Launcher to include support for Network Tables — assuming passes your sniff tests, here is the basic plan:
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 That looks most excellent. I'll update all the keys on the dashboard, and hopefully test simultaneously with the robot code tommorow. Thanks!
*Thread Reply:* Thanks, forgot what the slash through the circle ment...
I’m sorry, my alarm didn’t wake me, be there in a few
@channel 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:
At the end of our meeting, we should be ready for the July 4th parade! WOOT!!!
@Darwin Clark commented on @riyadth’s file Are these your headphones? Probably a programmer...: Yeah, those look like mine. Sorry! I'll pick them up at the next meeting.
Wow! That’s awesome. May I have a list of everyone who contributed? Thanks!
*Thread Reply:* @ronanbennett @declanfreemangleason @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!
*Thread Reply:* duplicate entries are fine — riyadth & I’ll merge the list
@riyadth commented on @riyadth’s file Are these your headphones? Probably a programmer...: Maybe when you pick up your Kindle?
@Darwin Clark commented on @riyadth’s file Are these your headphones? Probably a programmer...: Yes! That would be a perfect time... At least it will be fully charged!
pushed a few minor updates to Atlas upstream —
@binnur 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 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.
@channel we can meet Sunday @ 10am -- let me know if you will be able to attend.
*Thread Reply:* I can be there, but I'll have to leave and come back in the middle for a short guitar lesson.
*Thread Reply:* I can't make it this time, but any other weekend after this I'm free Sunday
*Thread Reply:* Sorry I know that this is so last second but I can't come my parents planed something last second on m
@channel 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!! 🤖
To clarify -- we will not be meeting on Saturday 6/2
Programmers — I tested & pushed the OI controls to upstream. Other than bling, everything is now operational. @riyadth will share his findings on bling in a bit
*Thread Reply:* Great! I can't wait to see everything working together.
@declan_freemangleason your code changes (output not updated enough) and throttle controls work — I did not test the drive straight mode.
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.
*Thread Reply:* That definitely explains some of the things I was seeing.
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
@riyadth Out of curiosity, why do we not experience this same issue on the main robot? Is there a slightly different system on the robot?
*Thread Reply:* 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.
*Thread Reply:* 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.
*Thread Reply:* 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.
*Thread Reply:* I'm not sure I understand the question completely, but I'll explain what's going on. First off, @declan_freemangleason’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.
*Thread Reply:* 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.
*Thread Reply:* 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.
*Thread Reply:* 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.
*Thread Reply:* 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.
@declan_freemangleason @Kenneth Wiersema @coachchee 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!
@Kenneth Wiersema @declan_freemangleason have we identified a representative driver for our test drive of Atlas?
*Thread Reply:* @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
@peterhall let’s target Saturday at 11am. Crossing fingers it will be quick. @declanfreemangleason @ronan_bennett @Darwin Clark I think we need two programmers, let me know if you are available
*Thread Reply:* I would love to show up, would like to Q&A stuff about the driver station with @peter_hall
*Thread Reply:* 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?
*Thread Reply:* Yes - we can spend time testing it.
*Thread Reply:* I can come, but if we’re just test driving I don’t think I’d have anything specific to do
*Thread Reply:* That sounds useful I think that we should try to get it to work.
*Thread Reply:* @ronan_bennett you are always welcome to hangout — you know where to find us if you are bored 🙂
Do you want me to come to retension the launcher?
*Thread Reply:* @kaedricholt @Harper Nalley and @peterhall retensioned the elastics, fyi
*Thread Reply:* @kaedric_holt We retentioned the the intake elastics but not the launcher elastics. Those should still be done before the parade.
*Thread Reply:* Should we increase or decrease the tension?
*Thread Reply:* It worked fine for testing but for an actual event i would like the ball to go further.
*Thread Reply:* The reason I ask is because we won’t have that much room in the event
*Thread Reply:* We don’t want to shoot the BSF people
*Thread Reply:* I can do it before the parade, won't take more than ten min.
*Thread Reply:* I think they should stay where they are.
*Thread Reply:* They’re powerful enough to shoot, but not too powerful
*Thread Reply:* Since @peter_hall is the one driving, it should probably be his decision.
*Thread Reply:* How about we fire the ball before the parade and pay attention to how far it goes. Then we can make a decision.
@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.
@binnur that time sounds good. I'll be there!
great @peterhall @declanfreemangleason @Darwin Clark see you tomorrow @ 11am
@binnur 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
@channel we are ready for an Atlas pickup! 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_freemangleason 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 @riyadth when will it be convinient for the students to pick up ?
I’ll need to coordinate w/ @tarkan 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.
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 @joncoonan might take atlas directly to his graduation party 😉
@binnur, when would be best for you this afternoon or evening?
@Cruz_Strom How about after 6:30pm tonight? I'll be around
Thanks @Cruz_Strom . When can you deliver on Mon .