Android Controll System

[Jcbconway]

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).

[protoserge]

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.

[Team3266Spencer]

I'd love to help if I could or at the very least try this out after the build season.

[Jcbconway]

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.

[protoserge]

Originally Posted by Jcbconway

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.

I think that's what our C&C people have done. I'm just their CD spokesperson

I'll check on which filtering method was applied, but I believe your approach is very similar to what we've done (Arduino and IMU).

[toastnbacon]

This sounds cool! I'm really excited to see this in action! I'm afraid I don't know much about it, but if I can help at all, let me know!

[protoserge]

IMU Details:

• Arduino + IMU chip
  
• UDP packet streams over Ethernet

Basic algorithm:

1. Kalman filter at 50 Hz brings in IMU data: 3-axis gyro, accelerometer, and compass
2. The output is a corrected Euler angels for roll, pitch, and yaw
3. Encoding in IEEE floating point format in a UDP packet

Presently, we have LabVIEW for decoding (you can build anything to unpack/decode the UDP)

[Jcbconway]

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!

[Jcbconway]

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....

[taichichuan]

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.

TIA,

Mike

[protoserge]

Originally Posted by Jcbconway

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....

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.

[techhelpbb]

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.

[Fifthparallel]

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.

[DjMaddius]

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.

[protoserge]

Originally Posted by Fifthparallel

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.

Alliance formation using swarm in 2020 for 100 points. I called it first.