This is a simple/basic write up of our robot and it’s controll system.
Hello fellow FRC teams! Us programmers from team 3767 are developing an Android controll system that will comunicate over USB to the driver station, then to the robot. THe controll system will do various things including cordinate based controll, like data feedback, and data based calculations to increase algorithm stability over the course the competitions (Learning essentially). Ofcourse this will all be shared publically once complete. The system is 3 parts, the Robot, the Driver Station, and the Tablet (Android). Basic Structure Breakdown
**Robot: **The robot must be able to calculate and keep track of its posistion on the field. Driver Station: The driver station must handle all 2 way comunications from the tablet to the robot, as well as handle all the standard (or custom smart dashboard) components.
**Tablet APP: **must comunicate 2 way to the robot as well as store/collect data and analyse for specific paters. In our case we are using an ultrasonic system to calculate absolute posistion and other systems to estimate posistions, so the data colected/analized will be used to adjust algoritm paremeters to increase system accuracy of the estimate posistion algorithms.
This is a very VERY fun project but in the post season we will be realeasing all of the source to any team interested for experementation as well as help in developing the systems/app better. We currently only have 4 programmers and no programming mentors so we are very busy! But doing good!
My questions for anybody is what are your oppions, are you interested in developement, and just general feelings towords the entire ideas
–Jake (Lead Programmer 3767)
PS. I will try and send the driverstation source and android app source to a database somewhere before competition week but I dont think it will be in time for anyone to test/inmplement into this years game … however you could have fun playing with it on your other robots! (if you have more then one).
The interface you’re developing sounds pretty awesome!
We are currently working on a co-processor based IMU solution that communicates via Ethernet. We’re willing to share this once we get time to tackle additional projects.
stinglikeabee, I was looking into building a custom cirucuit with an ATMEGA328 (arduino based) to comunicate via ethernet to handle the constent calculations for an IMU. However I never got around to getting any firther and at this point there will not be any time to do so. I am curious how your algorithms work? We are using a Khalman filter that adjusts the wight for the Gyro trust depending on the amount of noise we get from the accelerometer, HOwever we are liiking into adjusting this based on our left and right drive encoders instead to as well as a special cases for if we get hit/bumped.
**
Team3266Spencer**, Yes I will be sure to keep you posted! (by this thred probs). There are many areas we need help with, that is not just the android app. the driver station can be improved as well as writen in multiple languages to allow more teams access.
stinglikeabee, I would be interested in seeign what it is you are doing! Im also good for advice/help when it comes to arduino as I have many years experience.
toastnbacon, Hey, anything helps! glad to here your interest and when we get around to sharing all the source with everyone you can study it and improve it at your own pase!
stinglikeabee, Your IMU is 9 degrees of freedom I assume? I actually do not have much expeience with magnometers (I assume that is you comapss aswell?). How is it working for you? What you are doing sounds impressive and if I had some more time I would probably try to do this for our team aswell since we are predicting a loss in precicion with our current method…
So, did this project ever make any progress? I’m very curious as to being able to attach Android or Arduinos to the driver station. We need a lot of I/O for this year’s design.
I apologize for not responding back. I typically check CD at work and I forgot to get back to you. I believe it is a 9 DoF. I’ll ping the expert to see what his experience with it is.
As part of the proposal to the 2015 control system FRQ I prototyped a working interface that would allow Android devices either on the robot or as the driver’s station though it was optional (FIRST declined this proposal so you won’t be using what I created in 2015). It worked just fine with any Android device that fully supported USB host mode which some older devices do back into 2.1 and any device that claims USB-On-The-Go (which is Android kernel functionality) support should.
I’m very gratified to see students come along and demonstrate that not only is this not beyond you to understand and utilize similar techniques and technology many of you are more than capable of doing it yourselves.
I choose USB because though many Android devices support WiFi and bluetooth there’s many additional layers there that can cause unnecessary complication. Team 11 does use bluetooth with their Android scouting application the students write.
I look forward to watching this develop if I can be of assistance please let me know.
I’ve been thinking about doing this with an MVC-type thingy that uses node/backbone/m-jquery and passes around json data between the two clients (robot and browser) and a server (running somewhere).
The benefit to this is that while you can still use TCP/UDP streams for robot comms, you can also have mutliple connections going to multiple bots all inside of any webkit-based web browser on any system.
If I may ask, why use android at all? Other than the learning experience, you could do all the analysis on the driver station itself rather than on a tablet connected via usb.
I’ve been working on this for the past few weeks during downtime. Currently, I think a driverstation mockup done up in CSS and uses AJAX or KO to pass around JSON data between the FMS and (possibly multiple) robots. Right now I’m getting the robot to HTTP /GET json data from a node server (running on a RaspPi? we shall see, I have one sitting at our shop) and parse it in C++
On that note, what I would definitely like to see FRC do in the future is begin to take a “grown-up” look at what FLL currently does – program robots to do a task – except with multiple robots running in concert per one team. This could scale to more co-opertition (notably missing from this years game) between teams on one alliance using 9 robots (three a team) to solve “physics” problems in a Portal/HL2-esque way.
Unfortunately, that’d just be way too complicated unless the NT stuff gets simplified down. It makes cross-language compatibility a nightmare (for everything other than lower-level languages, that is) and it’s mainly why I’m not using it for my little side-project (writing hex and bin values for a keep-alive in JS is the 7th circle of hell). Even the current writing style the WPILib and FRC uses makes it so that data transactions are incredibly heavy across the network (esp. for 6 teams + the FMS). It would also place a heavier emphasis on software engineering & architecture (not a strong suit of a majority of teams prior to this year) – but at the expense of mechanical ingenuity, which does not seem to be a direction any want to go in.
A boy can dream though.
However, this Android control scheme is pretty frackin’ awesome! What language was it written in? How do you pass data around? I didn’t get a good look at your OP, but is it just the joysticks and buttons on the tablet and it treats itself as a HID? I might actually be dying of anticipation.
