Quote:
Originally Posted by Kims Robot
We will likely be the center team, hosting the controller, but we had plans of having saturdays where other teams could bring their robot in, demos at Ruckus, webcast trainings and phone conferences to involve teams further out, and a lot of documentation on our wiki & forums. We will be inviting all of the teams that want to drive out here to be involved in any/all of the process, but these were just the teams that we have been interacting with for Ruckus planning and the teams that have been attending our Labview training all summer.
I think for us, it just made sense, we can run the Beta testing, but bring in expertise from all the other teams in the area to help out and assist in problems as welll as taking time to teach as many teams as we can.
|
With that many teams it would be interesting if some of the teams programmed in Labview and others programmed in C++. It would be very difficult for a single team to program the robot in both languages (the dashboard is a different story). Especially when one is a visual language so find & replace can't help. Also, it would also be far too confusing for the students who need to focus on a language to learn for that year. However, with more teams, each team can focus on their language of choice and share the robot. You can even have different programmers reprogram the robot between Labview and C++ without switching cables
Labview is obviously Rolling Thunder's forte. I've gotten to know SparX programmers enough to know they are C gurus, even diving into the adc library to modify it. They sound like perfect candidates to help develop the open source C++ libraries as a C++ lead team. Your collaboration has the potential to do more "Beta Testing" than any of the other recipients by developing thoroughly in both languages and comparing first hand.
Obviously, the choice between Labview and C++ is the most important decision programming teams face this year. I am not trying to make that decision for anyone, or give anyone more work/confusion. Just a idea I would like all the Beta Testing collaborations to consider.
Good Luck to all teams as we break new ground,
Brian
<SIDE RANT> I don't see the major advantage to installing the cRIO controls system on multiple bots. Without multiple power distro blocks, digital sidecars, etc... it is an intense electrical task to move the cRIO between robots. Even if you build a modular panel, it still is time consuming to switch. IMHO, no matter how many teams you have:
-Use 1 testbed bot
-Load it with sensors and mechanisms
-Maximize precious uptime for your programmers
</SIDE RANT>