What have you developed or are in process of developing?

[jtrv]

Hello,

With the recent rapid growth of our programming and control systems, I'd like to take on a big challenge this year. Nothing that would require multiple build seasons, since this is my senior year and I'd like to finish it while I'm still around, but hey, anything works. I've looked into splines from 254 and that seems probably the highest bar we can set for ourselves. We have a PID system working.

So i'd like to know what you guys are in process of developing to maybe spark some ideas for myself.

[Caleb Sykes]

We are in the process of developing a 2-ball autonomous for our off-season events.

Additionally, we have been playing around with field-centric tank drive code. Our robot was symmetric last year, so a field centric drive that gives no preference to the "front" or the "back" of the robot might actually be very beneficial.

[Arhowk]

Originally Posted by inkling16

Additionally, we have been playing around with field-centric tank drive code.

ehm... what...

I've just been toying around with a square bot (omnis with equal horizontal and vertical force) as a way to learn some mechanical (already knew more electrical than the experiment would be able to teach)

Whenever I get a few minutes of free time i also work on fss (First Scripting Syntax) which was designed to be a combination of C++, Java, and Wurst (which in itself is a combination of python and the native scripting syntax) but I've spent so much time developing a code editor window for java that i have no idea what im doing anymore, not to mention anytime my freetime is over an hour i just end up watching anime. (it would be worth mentioning I'm our team's only programmer)

fun little ideas for your team that i jot down in a notebook whenever i think of some -
Automatic error recovery
Code logic probe
Custom dashboard for modifying constants (SmartDashboard just nver appealed to me in that aspect)
Text-based auton system (i did this in under an hour, its not that hard. in another two hours i had a full gui and automatic compiler + deployment, which is ironic because i've been working on redoing that gui for the 2015 system for over 5 months now)
Voltage modulation (send a motor 8 volts)
vision processing (<insert cliche method to process images here>)
automatic controller detection (ps3, xbox 360, logitech, flightstick, yadaydada)
auton mode swapping (2014 we did it with start and select on the driver controller)
automatic ping reports (idk just a thought, if you thought ur robot had shaky comms during the match u can just upload the ping reports)
spibus absolute encoders (those won us an innovation in controls award and a judges award last year)

[Caleb Sykes]

Originally Posted by Arhowk

ehm... what...

We are roughly using the approach laid out in this whitepaper. We had a working gyro and some basic autonomous functionality with it last season, and are looking to become even more familiar with this sensor. In addition to the basic functionality described in the paper, we would also like to:
Add a button the driver can press that sets speed_command to zero, allowing the robot to turn in place to the angle specified by the joystick.
Make the maximum angle that allows the robot to turn forward instead of backward (in the text given as the number 100) a function of the robot's velocity, and not just a constant.

[cjl2625]

This summer, I wrote a scripting language for auto mode, using LabVIEW. Can be updated instantly through the dashboard, has support for running multiple commands simultaneously (needed for our two ball auto), and I'm considering adding conditionals (if statements).

I'm also planning on experimenting with vision and potentially on-board kinect.

[SoftwareBug2.0]

Manual override mode: For every PWM/solenoid/relay/digital output on the cRIO you could press a sequence of buttons on a gamepad to set it to a chosen value. Useful for initial bring-up of components, debugging, or if something goes unexpectedly wrong during a match. This was especially useful for us because our normal operation modes involved doing a lot of actions at once.

To use it, you'd basically hit a button to specify the output type, then a couple to specify which output number, and then a couple more to choose the value to set it to. So for example, the values available for the PWMs were full forward, full reverse, stop, or "no override".

This feature was easy to implement because of the overall design of our code. At a high level, it looked like this:

      +------------------------------------------------+
      | +-------------+                                |
      | |             |                                |
      | +>|---------| |                                |
      +-->|state    | |                                |
sensor--->|estimator|-+->|-------------|               |
input     |---------|    |control logic|->overrides->outputs
user input--->goals----->|-------------|    ^
    |                                       |
    +---------------------------------------+

All the outputs are collected together into a datastructure. So after the "normal" control logic ran it was easy to change parts of the output before it was written, and these changes would natuarally be reflected in the state estimation code. This meant that we didn't have to snake any changes through the normal control logic or state estimation code.

[pastelpony]

Im in the process of developing a scouting app as of right now, though when I get access to a robot, I want to test the use of an Intel Galileo and a fork of CheesyVision for my team's use (if it's allowed next year.)

[Kingland093]

My team has been working on vision tracking for the past 2 years… still without success. I've been also looking into encoders and ultrasonic rangefinders

[pastelpony]

Originally Posted by Kingland093

My team has been working on vision tracking for the past 2 years… still without success. I've been also looking into encoders and ultrasonic rangefinders

Are you using LabVIEW?

[Kingland093]

Originally Posted by pastelpony

Are you using LabVIEW?

Java

[DonRotolo]

I'm developing an online training program for FRC robot inspectors. And hoping FIRST will approve it...

(Not off-topic: It does involve programming, and robots, but perhaps not in the usual sense...)

[Fletch1373]

Originally Posted by DonRotolo

I'm developing an online training program for FRC robot inspectors. And hoping FIRST will approve it...

(Not off-topic: It does involve programming, and robots, but perhaps not in the usual sense...)

I'd be interested in helping if you're open-sourcing it or otherwise looking for help!

[nandeeka]

We learning how to use NetworkTables and are using them to give ourselves better data for tuning PID loops.

[nathanwalters]

This year we're looking at using a coprocessor to handle a lot of stuff that would normally be done by the robot itself or the driverstation. Because we don't have to worry about using CPU cycles on the RIO, we'll be able to do quite a bit. We're looking at developing a field-positioning system that integrates input from a variety of sources (encoders, a 9-axis IMU, the camera, etc.) that will be able to precisely determine our position and orientation on the field. We're also looking at a more complex logging framework that will essentially continuously log the state of every part of the robot. That will let us virtually replay the match after the fact to help with debugging. With the new CAN bus APIs, we should be able to grab info about current draw from our actuators, which will provide greater insight into what's happening on the robot at any given time. One student is designing a temperature-monitoring system that will use an Arduino with a bunch of temperature sensors attached to it to monitor the temperature of various parts of the robot. And, of course, we'll continue to refine our LED code

So yeah, that's what we're working on right now. I'm excited to see if we'll get all this working in time for build season!

[Pratik Kunapuli]

Originally Posted by Kingland093

Java

WPI has a decent tutorial for vision processing here. It goes through example code for both Java and C++ and does a pretty good job of explaining the process. My other suggestion would be to look through this white paper. It is Team 341's vision processing code form 2012 written in Java. The thread associated with the paper also answers a lot of questions.