2168 - Aluminum Falcons Alpha/Beta test site

[NotInControl]

We are releasing our Alpha/Beta test site to the community.

We are hoping this becomes a useful resource for many teams looking for answers to questions regarding the control system and general FRC knowledge.

We have been involved with FIRST since 2007 and some of our mentors have been involved with first since 2004. This website is geared around the 2015 control system, but we also use it to capture some of our lessons learned and recommendations as a team.

The theme for this website, is to not be a blog, but to instead provide quick answers to some of the most frequently asked questions teams may have regarding the Control System and be a one-stop-spot for anything control related to FRC. Some of these answers are provided by our own direct testing, leveraging the results of other alpha/beta tests, or directly from the developers of the control system.

It is still a work in progress, and should be closer to completed by Dec 15. (Some images are still missing, links still missing, spell checking, etc.) so check back frequently.

The reasoning for this release now is to make this resource available to teams now, and to any teams that can not attend our info session which we are holding at our school tomorrow night from 6pm-7pm.

So please check it out and provide any useful feedback. We hope it becomes as valuable to your team as it will be for us.

We have a lot more info to post up, especially around vision, so look for that in the next week or so.

Website URL:
http://controls.team2168.org

Note: all of our Alpha/Beta code will be release by Dec 15

[AllenGregoryIV]

This is amazing thanks for posting it. Only been through the RoboRio page and I already learned a few new things. I'm sure I'll be referring people to this all year long. Thank You

[jhersh]

A few corrections...

• The roboRIO has 512 MB NAND flash.
• Programming (network emulation) is provided via the USB Device port, not the USB host ports.
• The IP of the USB Device network emulation is actually DHCP. If you plug in more than one roboRIO at a time they will be on different networks.
• For SFTP access and SSH / Console login access, you should probably recommend using the lvuser account instead of the admin account so that the home dir and permissions will match the running user program.
• In the section "How do I connect to the Internet using the RoboRio" you should mention that all the acrobatics you are doing are only the result of you deciding to use static IPs. If you were to use DHCP, not of it would be necessary. It would simply work. (You might want to think twice about recommending static IPs. What do you want to continue to use them?)
• In the section "Can I install 3rd party packages/software on the RoboRio?" you should also mention that the default configuration already points at the NI feed server and contains many packages already configured specifically for compatibility with NI Linux RT. The user should be able to start from the "opkg update" step and have success.
• The regulator topology actually sources the 3.3 V supply directly from the 6 V supply.
• In addition to the enable state (as a result of brown-out or watchdog) the user can also query each user rail supply for its voltage and its status (bad input, ok, over current, etc). These distinct statuses can allow for intelligent handling of low voltage situations.
• In section "How do I put the RoboRio in Safe Mode?" the answer is "Hold reset until the status LED lights, then release."
• How to I commuicate with the RoboRio over Serial (RS-232) - On Windows, PuTTY is a good option.

I only glanced through the roboRIO section. You would probably do well to compare your documentation with the ScreenSteps documentation to make sure there are no discrepancies. You should probably also reference the ScreenSteps where available. For things not in ScreenSteps, it is probably worth bringing those things to Kevin's attention.

Cheers,
-Joe

[NotInControl]

Joe, thanks for taking the time to read through the page and post corrections. I will make the changes immediately.

If you find any others please let me know.

Once I dissolve everything, I will be sending Kevin a list of recommendations for screensteps.

Linking to screensteps is on my todo list. I have a list of where the links go just need to incorporate it. Work in progress

Thanks,
Kevin

[NotInControl]

Originally Posted by jhersh

A few corrections...[*]For SFTP access and SSH / Console login access, you should probably recommend using the lvuser account instead of the admin account so that the home dir and permissions will match the running user program.

As of the latest plugins Java still uses admin as the user to deploy code, so the FRC_JavaApp has permissions inline with the admin owner. This is why we still recommend admin. I susspect the same is true for C++ as well, but we have only been testing Java most recently. Moving the application to the /home/lvuser was a recent change, I am not sure if Brad plans to change the user, but all languages should probably use the same user.

Originally Posted by jhersh

[*] (You might want to think twice about recommending static IPs. What do you want to continue to use them?)

The only downside to using mDNS is that every device wishing to use the mDNS address must have a mDNS resolver installed or else the address won't be recognized. I think setting a static IP gives us the best of both worlds, we can set the static IP address and each device will have a known IP address, but still use mDNS names if we wish.

I am aware that on windows machine the NI software installs a mDNS resolver, but in previous years we typically don't have all of the NI software installed on every development machine, only the programming interface (i.e eclipse, JDK, and WPILIB). Knowing the static IP means that I can grab any laptop with a browser and silverlight to navigate to the roborio website, or even use my android phone to gain terminal access without having to install additional software, but for any computer that has an mDNS installed like my mac or the DS we can use the mDNS address.

I believe the latest WPI plugins use mDNS by default and so assume all development computers will have a mDNS resolver installed, not sure how I feel about that just yet (I know we can always modfy the build script on our own to point to the statc IP address) so I am not too worried.

I use ubuntu 12.04 mostly for embeded development, and at least with mDNS on ubuntu there has always been performance issues, which is why I tend to shy away from it on some of the other embedded devices we use. https://bugs.launchpad.net/ubuntu/+s...dns/+bug/94940

I must admit, I never really tested any workaround or updates to resolve the issue in ubuntu, so it may be resolved.

But since FRC is now using it, maybe we will adopt it sooner than later.

Thanks again for the other corrections, if you find any more please let me know.
Regards,
Kevin

[Chi Meson]

As mentioned in the first post, we have released all of our developed software for the new control system. A little bit later than we expected, but it was posted before kickoff

"so take that, R13!"

Find out more on this thread:
http://www.chiefdelphi.com/forums/sh...hreadid=131905

Good luck, and as the bumper specialist for our team, I'm going home!