Wednesday Jan 25, 2012

2012 FIRST Robotics Competition Season Underway

At this very moment, somewhere around the world, some students are staring at a Java stack trace for a robot. They have three more weeks to finish developing their code, even though the robot isn't done, a motor is fried, and the drive team ate all of the snacks while waiting for the bug to get fixed...

[Read More]

Monday Feb 21, 2011

New SunSPOTs have arrived - faster, and with more memory!

The new batch of SunSPOTs are available to purchase at the Oracle Store! The changes are not just to the box color, but include a major upgrade to the Sun SPOT Hardware. The new "rev 8" Sun SPOTs includes:

  • 400 MHz ARM 926ej-S Processor
  • 8Mbytes Flash Memory
  • 1Mbytes SRAM Memory

The new demo board includes changes such as:

  • IR emitter/detector
  • Speaker
  • RGB color sensor
  • Updated accelerometer

Check out SunSPOTWorld.com for updated information.

Thursday Sep 16, 2010

Room changes for JavaOne talks

It looks like JavaOne is fine-tuning room allocation for various sessions. I suggest preregistering for sessions you are sure to attend (you may get room change notifications), and double-checking on-site.

My two talks have moved three times so far! Shameless plug with new room assignments:

Java in the 2010 FIRST Robotic Competition

Java Native Access: More Java, Less Native

...

[Read More]

Wednesday May 05, 2010

Review of Java for the FIRST Robotics Competition

+

Java Usage

The 2010 FRC season has just completed, which included Java as a programming option for the first time. We don't have full statistics of which teams used which languages, but we conducted surveys at several regional competitions (where “we” mostly means National Instruments and my trusty assistant).

The sample data shows about 16% of the teams used Java to program their robots. There was a lot of regional variation, from 0% Java use at the Dallas and Detroit regionals to 37-40% at the Boston and Manchester regionals. But that same 16% Java average held true for teams at the Championship competition. Extrapolating from that sample, world-wide there should be about 288 teams that used Java this year.

The middle of the US is looking pretty empty! We should get complete data after FIRST conducts its “kit of parts” survey.

Java Results

The Java teams did well. Some Java teams won their regional competitions, and Java teams were in the 2nd place and runner up positions at the world championship! In fact, the number of Java teams in the Quarter finals through to the Championship matches roughly tracked the percentage of teams in Atlanta running Java.

We received feedback from in-person surveys and on support forums. Teams were very happy to be able to use Java because it was either taught in their high school or was well understood by the mentors. They also liked the NetBeans development environment and having a “safe” programming language.

But it wasn't all “teflon wheels and traction control” (a FIRST phrase synonymous with “good”, which I just made up). There were definitely areas that teams wanted improved. Some common issues:

  • Needed more documentation:
    • “Big picture” overview of a robot (IterativeRobot)
    • Cookbook recipes – how to setup and use a gyroscope (for example), and how to use the data
  • Image processing was too slow. Careful tuning of the camera, robot code, and the Dashboard running on the laptop was required to get reasonable performance. This should have been pre-tuned, and the systems should have more “performance headroom”.
  • More diagnostics. Many, many, many robot failures look like either “watchdog” or communication errors, when in fact they may be wiring, low voltage, hardware, networking, USB, field system, or software failures.
    • Need to log more data to detect or rule out error scenarios.
    • Need to present data in a way that makes diagnosis easier
  • Installation/version match issues
    • Built-in installation sanity checks were added, but more can be done
  • Bugs in WPILib and Java IO
  • Late CAN bus implementation

I spent several days at regionals and at the Championship helping Java teams with issues. The most frustrating case was a Java team with intermittent field communication errors, but we couldn't narrow the issue down to hardware, software/Java, networking, or field issues. Another team had some robot logic issues I was able to help with, and several teams had issues that were resolved with wiring or component swaps. I was relieved that the Java system itself didn't seem to be the cause of serious problems.

Beyond looking for teams that needed help, I really enjoyed learning what teams were doing with their robots. One industrious team programmed their robot three times, once in C++, Java, and Labview, and developed an Eclipse module for Java on FRC. Another team experimented with porting several Java libraries to the robot including a JavaScript interpreter. A couple of teams switched from Java to C++ because the CAN interface for Java wasn't complete, but another team simply reimplemented all of the Java CAN interfaces themselves!

Conclusion

The first year of Java for FRC went well. Not without a hitch, but not bad. We'll be working with WPI to improve the system for 2011, especially in the areas of diagnostics and performance. And I'd like to see the use of Java for FRC world-wide match the 30% use that we saw in New England.

I'll add in the usual disclaimers here – speaking for myself, not for Oracle, Sun Labs, WPI, or FIRST. Any erroneous data would be due to me.

Wednesday Apr 28, 2010

“It's Not About the Robots”



Dean Kamen, serial inventor and founder of FIRST (For Inspiration and Recognition of Science and Technology), often says this phrase at regional and championship FIRST Robotics Competitions.

What is it about?

This is my first year with skin in the game – not with a team, but as part of the group at Oracle and WPI porting and supporting Java for the robotics competition.


As I looked over my photos of regional competitions and the world championship in Atlanta I found some shots that exemplified FIRST to me.



The Green Reapers call a time-out in the final rounds of the WPI Regional. Something has gone horribly wrong, and they have to make it right (in front of the whole audience).

This worked at back at school...


No, there shouldn't be any parts left over...
 It takes a village to raise a robot


You can't always get what you want. Or what you need. But you go on anyway.



I guess what impresses me is that after teams learn that a plan for “the coolest robot ever” is just science fiction until it is built and tested, after learning that creating a robot is so complicated that teamwork isn't just nice but a requirement, or kids that never held a screwdriver before can make something unique and amazing, after learning that the math and science they've been learning isn't just useful, but it's kind of fun, after they have a shiny new robot in a picture with the school principle, then they go to competitions. Then they realize that haven't built a robot so much as they've built a “Murphy's Law” detector. And they have to deal with it. And they do.

If this experience doesn't help develop a world-class, science and technology literate workforce I don't know what will.

The most iconic scene that I photographed was team 51 waiting to compete at the world championship, when something happened that required them to swap out the main computer of their robot. Like a NASCAR pit crew, the team jumped to perform this lobotomy while on the floor of the Georgia Dome. Unlike most competitive sports, other teams swarmed around to help them. In this picture, team 40 gets ready to help by re-installing a fresh image to the robot's computer.




Team 40 used Java on their robot, which may explain the gratuitous Oracle logo :-)




The FIRST Competitions teach the kids to bring everything they have – their creativity, knowledge, skill, problem solving, energy, commitment. Then share it – that's how big problems get solved. And if they bring all of that to the competitions, they'll leave with more than they came with. And that's what it's about.


p.s.

Apparently it's also about having fun. And hair. :-)



Friday Dec 04, 2009

Java SDK for FIRST Robotics Competition Released!

Over the last few months we've been working with WPI and 20 high school robotics teams getting the Java SDK for the FIRST Robotics Competition ready for the 2010 season. We've been getting great feedback from the teams including bugs and questions. We've also seen confirmation of the value that Java brings to some teams. One mentor said that they can usually only find a couple of student C++ programmers for the team, but for 2010 they have 10 Java programmers! Or was it 15?

This week FIRST announced a public release of the Java SDK. Here's the official word from Bill's Blog (the official FRC blog):

In addition, I’m very pleased to let you know that an early version of the FRC Java software is now available for download at http://first.wpi.edu/FRC/frcjava.html . I know we promised this for November, and I apologize for being a few days late, but I think you will be very happy with the results. Our hats off to the extraordinarily dedicated Java beta test teams and the developers for all their hard work! Veteran teams, I encourage you to open your doors to rookies in your area interested in getting an early look at Java and how it works with the robot. Remember they don’t have the advantage of having last year’s control system to experiment with.


This early-release SDK is only fully usable by FRC teams that have the cRIO hardware (veteran teams). Check the FIRST forums to read or request more information.

This Java SDK is based on the Squawk JVM and the Sun SPOT SDK. Rookie teams can get experience with the Netbeans IDE and Java ME APIs by using the Sun SPOT Emulator. See http://sunspotworld.com/frc for more information.

BTW, if you're an experienced Java programmer, don't sit around pouting about how you never get to program dangerous, high-speed, 120 pound robots. Consider being a programming mentor to a local FRC team! See our mentoring tips wiki as well as usfirst.org.


Wednesday Jun 10, 2009

FIRST @ JavaOne Wrap Up, videos, photos, and links...

I've finally caught my breath after JavaOne - we had a busy week. We were able to bring FIRST to a lot of technical people that had never heard of FIRST, and let people know that Java was coming.

JavaOne Pavilion... Technical Session and BOF...

James Gosling's Toy Show Keynote

Brad Miller and James Gosling talked about FIRST and Java in front of a live audience of thousands and webcast to many more. I helped with a demo along with Scott and Austin.

Duke's Choice Award... Thanks... More Information...  (Full Blog Entry)

[Read More]

Wednesday Jun 03, 2009

WPI Wins Duke's Choice Award for Java for FIRST Robotics Competition

Worcester Polytechnic Institute (WPI) won the 2009 Duke's Choice Award in the Category: Java Technology in Education for it's work bringing Java to the FIRST Robotics Competition.

This was worked started by WPI students Brian O'Keefe, Marouane Afiri, and Albedith Diaz for their "Major Qualifying Project". They ported the open source Squawk JVM to the compactRIO robot control system, and ported WPILib, the C++ robotics library used in the FIRST Robotics competition, to Java. They did a great job in in a very short time - they did the first port of Squawk to VxWorks (it was actually only the second port of Squawk to run "natively" on an OS), and were part of the initial proposal to the FIRST organization. I was very happy to be the team's "industry" advisor - this became my introduction into the world of FIRST robotics!

This work has been continued by the WPI Robotics Resource Center, assisted by the Squawk and Sun SPOT teams at Sun Microsystems Laboratories and other volunteers.

It's great to see WPI get recognized for the efforts to bring Java to the thousands of students developing robots for the FRC. Be on the lookout for robots in James Gosling's Toy Show keynote, and for the award presentation to Brad Miller of WPI!


Friday May 29, 2009

FIRST @ JavaOne

FIRST and the FIRST Robotics Competition will be part of several events at the JavaOne conference June1-5 at the Moscone Center in San Francisco. Many sessions are FREE to all, or FREE to students (registration required)

CommunityOne
Monday, June 1 - S311736: "Lightning Talks, Part 4/FRC-FIRST Robotic Competition" 2:40 PM - 3:30 PM Esplanade 303

CommunityOne Registration
CommunityOne events are free to all. Register at http://www.cplan.com/communityone2009/w ... gistration

JavaOne
Pavilion - Java Playground
Will have representatives from FIRST, WPI, and several FRC teams. Robots will be demoed in the robot arena. Learn about FIRST, the FIRST Robotics Competition, and Java for FRC. Find out how to get involved!
Monday (June 1) 3:00 pm - 7:00 pm,
Tuesday 11:30 am - 7:30 pm
Wednesday 10:00 am - 4:30 pm
Thursday 10:00 am - 2:00 pm

Thursday, June 4 - TS-4945: FRC-FIRST Robotic Competition 2:50 PM - 3:50 PM Esplanade 305

1.The Java™ platform is an interesting vehicle for teaching kids about programming.
2. FIRST is an organization whose mission is to inspire young people to be science and technology leaders by engaging them in exciting mentor-based programs that build science, engineering, and technology skills; inspire innovation; and foster well-rounded life abilities such as self-confidence, communication, and leadership.
3. Robots are cool; robotic competitions are even cooler.
What happens when you mix these three things? You come up with a winning combination that lets kids and "adults" have a lot of fun.

Thursday, June 4 - BOF-4953 (Birds-Of-a-Feather) FRC-FIRST Robotic Competition 6:30 PM - 7:20 PM North Hall 124
What do robots and FIRST have to do with Java™ technology? Come to this session and see firsthand what Java technology is enabling kids to do today with some cool hardware. Get to play with big competition robots and their teams.

Friday, June 5 - James Gosling's Toy Show (general session) 8:30 am - 10:30 am

JavaOne Registration
The JavaOne Pavilion Pass, which includes General Sessions (and James Gosling's Toy Show) is free to all. Register at http://java.sun.com/javaone/2009/regist ... ilion_pass.

All sessions at JavaOne are free to students (under 18 requires chaperon). Register at http://java.sun.com/javaone/2009/regist ... d_students

Tuesday May 26, 2009

FIRST Atlanta Championship - Now With More Java!

I attended the 2009 FIRST Championship April 16-18 at the Georgia Dome in Atlanta, GA as part of the Java for FRC announcement. We demoed Java running on several robots, over-the-air debugging, and multi-platform development (Windows, Linux, Mac (and we kept getting asked about Solaris)). We gave a couple of talks with James Gosling about Java for FRC.

IMG_4198 IMG_4108 IMG_4136 IMG_4176

This was my first time at a FIRST Championship and it was pretty overwhelming.

  • 20,000 people
  • Hundreds of FRC, FTC, and FLL teams (and robots)
  • Four simultaneous competitions in the Georgia Dome
  • The World Congress Center filled with pits, practice fields, presentations, and people

But what was really impressive were the teams. It was really clear that FIRST was succeeding at its mission of inspiring students in science and technology. Students didn't just learn that science was cool - they knew that they were cool. These are kids that are not worried about being called geeks, or anything else for that matter:

IMG_1705 IMG_4155

Slideshow

As always, check out FIRST Robotics @ Sun for information on getting involved with FIRST.

FIRST Show-and-Tell at Burlington, MA campus

Last Friday we had three teams, five robots, WPI and FIRST come to visit Sun's Burlington, MA campus. The teams talked about their robots and experiences with FIRST, and mentors explained what mentoring for FIRST was all about.

Two of the robots were Java-powered - team 1519's little "Speed Racer" (look for the Duke on top), and WPI's demo robot ("demo" may stand for demonstration or demolition). Steve Heller arranged a demonstration of torque:

IMG_4563

Check out FIRST Robotics @ Sun for future FIRST show-and-tells on campus, and more information about FIRST.

Next stop - JavaOne!

IMG_4566
IMG_4555 IMG_4554 IMG_4552

Wednesday May 20, 2009

Upcoming FIRST events - JavaOne & Burlington Campus visits

Here are some upcoming events where you can learn more about FIRST, the FIRST Robotics Competition, Java + FIRST, and FIRST @ Sun.

This Friday, for Sun employees, we will have one or two FRC teams visiting the Burlington, MA campus. They will show off their robots  - and you can learn about what FRC means to them, and about mentoring and volunteer opportunities that exist. I'll also be here to talk about Java on the FRC robots, and should have a robot to demo.

Sun has given FIRST a big platform at JavaOne to show off what FIRST is about. It's also a chance to announce that along with Java being available for the robotics competition next year comes a need for experienced Java developers to mentor teams all across the United States and internationally.

There will be live robot demos in the Pavillion, where you can also talk to teams, mentors, and volunteers about FIRST. There will be a Tech Session describing Java for FRC - both how it was ported and how it can be used (TS-4945), a Birds-Of-a-Feather session for existing FIRST participants as well as though interested in learning more (BOF-4953), and perhaps a comment from James Gosling at his closing keynote!

Date

Time

Event
Venue Location
May 22

Noon

FIRST Teams "show-and-tell"
Sun Cafeteria\*\*\* Burlington, MA
Jun 1-4
daily

FIRST booth and Robot Arena
Java Playground - Pavilion JavaOne
Jun 4
2:50pm

Tech Session 4945: FRC-FIRST Robotic Competition
Esplanade 305 JavaOne
Jun 4

6:30pm

BOF-4953: FRC-FIRST Robotic Competition
North Hall 124 JavaOne

Keep in mind that the JavaOne Pavilion access is FREE. Students can get access to all JavaOne events FREE

\*\*\* The event at the Sun campus in Burlington, MA is open to emplyees only.

Monday May 18, 2009

Java for the FIRST Robotics Competition!

On April 16th we announced that Java would be available for the FIRST Robotics Competition. This is joint work between Sun and WPI to port Squawk (an open-source Java virtual machine) to the compactRIO robot control system, as well as the WPILib robotics library from C++ to Java.

We expect this to be a great addition for FRC teams that have some Java programming experience, and will bring not only the combination of power and safety inherent in Java to robotics programming, but also the ecosystem of Java tools, libraries and learning resources.

The exact flavor of Java that will be available is Java ME (Micro Edition), configured with the CLDC and IMP libraries. This is essentially the same flavor of Java that is installed in millions of cell phones (but without the graphic user interface libraries - LCDUI).

In addition the system is based on the libraries and SDK of the Sun SPOT project. It includes over-the-air debugger support as part of integration with the NetBeans and Eclipse IDEs and also includes ant-based command line tools.


The Java system will be in closed alpha and beta releases over the Summer and Fall, and will be ship in the "kit of parts" for the 2010 season (if not earlier).  We have also developed a software-only robot emulator that allows you to learn how to develop robotic software in Java using the Sun SPOT APIs (but doesn't yet include the WPILib APIs).

I'll be blogging more about this, including technical details, the Atlanta Championship, and Java + FIRST @ Java One, but here are some pointers to more information:

Friday Feb 06, 2009

GC debugging + surfing + nutrition?

      A year ago I was tracking down a garbage collector bug in Squawk over many days. Like most debugging, you start with a theory of what might be going wrong, figure out what data would prove or disprove the theory, and try to reproduce the bug while getting this critical data.
recycle logo
But now life starts getting interesting. We can't use a debugger on device when the system is this broken. And the system is built on an abstraction of objects (almost everything in Squawk is written in Java), but when memory overwrites can blow away metadata like object lengths and class pointers, you realize that you can't trust everything you see.

This isn't the profound, but ultimately simple, betrayal of the ground during an earthquake. Garbage collection can effect every object in the heap, so garbage collection bugs are more like betrayal in a bad Kung Foo movie:

Sensei-you've-raised-me-from-childhood-but-are-really-the-re-incarnation-of-my-father's-evil-half-twin-(and
killer)---Is-nothing-you've-taught-me-true?!!!


I had spent a few days and several dives down into the system, only to rise to the surface with theories disproved or becoming deeply disoriented. So one morning, I started with a new theory and tools, took a deep breath, and dove into the system again. Suddenly I was struck with a flashback of body surfing as a kid at Hendry's Beach and getting slammed by waves, tumbling around until I didn't know which way was up. cc

After reminiscing for a few minutes, I realized how amazing it was that my metaphoric dives and confusion could invoke such as strong memory. I could feel the oily tar residue of the ocean in my mouth. I could taste the seaweed that always reminded me of ice cream and of the kelp harvesters on the horizon.




I started thinking about how high-level metaphors could trigger such low-level sensory memories, when a sudden small burp reminded me of the fish oil pills and smelly vitamins that I had washed down that morning with a cup of hot coffee. Lesson learned :-)


ps. There was still a GC bug to fix. It turned out that we were removing the stack object (yes, it's an object) for a dying thread from the set of GC roots while the thread was executing the last few steps of thread shutdown. Yikes!

Monday Dec 15, 2008

Class Literals in Java ME

Background

Last week I learned that there was more to Java class literals than I expected - and not in a good way. If you're working in Java SE you can skip reading now, but in Java ME this might be of interest...

Class literals were added to the Java language in 1.1 days - they allow you to get a reference to a Class object as if any class had a static field called "class". So you can get the Class object for the String class by using the expression String.class instead of calling Class.forName and dealing with exceptions.

This is a great convenience - not for avoiding some try-catches (you could use a helper method for that) -  because the class name is checked at compile-time instead of run-time. If you change the name of a class everywhere but in the string passed to Class.forName, javac won't be any help.

Issue

In Java 1.5 the JVM Spec was updated to include direct support for class literals (extending the ldc bytecode). But how did class literals worked in Java 1.1 through 1.4? And how do they work in Java ME CLDC now?

It turns out that javac just keeps generating code until it works :-) There are a couple of variations in what it does depending on the Java target version used, but I'll describe what I've seen for -target 1.2 or 1.3 (which includes most (all?) Java ME CLDC applications).

Consider this trivial class using a Class Literal:

public class ClassTest {
    static Class c2 = String.class;
}
Javac will generate code roughly like this:
public class ClassTest {
    static Class c2;

    static Class class$java$lang$String; // cache (would make sense with a different example)

    static {
        if (class$java$lang$String == null) {
            class$java$lang$String = class$("java.lang.String");
        }
        c2 = class$java$lang$String;
    }

    static Class class$(String name) {
        try {
            return Class.forName(name);
        } catch (ClassNotFoundException ex) {
            Exception newex = new NoClassDefFoundError(ex.getMessage());
        }
    }
}

Bigger Issue

OK, so this is getting a little messy - the simple expression String.class is generating about 33 bytes of bytecode plus overhead for an anonymous field and method. But what happens when the class literal is referenced from an interface instead of a class? Note that interfaces can't have static methods, so javac generates an anonymous class to hold the anonymous method!
public interface InterfaceTest {
    static Class c2 = String.class;
}
Javac will generate code roughly like this:
public interface InterfaceTest {
    static Class c2;

    static {
        if (InterfaceTest$1.class$java$lang$String == null) {
            (InterfaceTest$1.class$java$lang$String = class$("java.lang.String");
        }
        c2 = (InterfaceTest$1.class$java$lang$String;
    }
}

public class InterfaceTest$1 {
    static Class class$java$lang$String;

    static Class class$(String name) {
        try {
            return Class.forName(name);
        } catch (ClassNotFoundException ex) {
            Exception newex = new NoClassDefFoundError(ex.getMessage());
        }
    }
}
This results in the same amount of bytecode overhead, but now we have extra class overhead. The class file for the anonymous class InterfaceTest$1 is about 587 bytes. Now multiply this by every interface that references a class literal.

Java Native Access

So why would anyone have interfaces that references a class literals? Check out the Java Native Access (JNA) project. JNA is an interesting system that lets you declare native functions you'd like to call from Java, and JNA takes care of generating a callout, without generating any JNI code. I'll be blogging about JNA in the future.

The typical JNA usage pattern is to declare an interface that contains the functions you want to call (as interface methods), and JNA creates an implementation that will actually do the call. To match the interface and implementation to a dynamic library containing the native code, the interface should declare a static variable such as:

    public interface CLibrary extends Library {
        CLibrary INSTANCE = (CLibrary)
            Native.loadLibrary((Platform.isWindows() ? "msvcrt" : "c"),
                               CLibrary.class);
    
        void printf(String format, Object... args);
    }

So What? And Where's the Squawk Connection?

OK, to recap, in Java 1.5 and later, this doesn't happen because the JVM can handle class literals. But in a Java ME system with tight memory constraints, such as what Squawk is designed for, this could add up.

But the Squawk VM handles class literals just fine, it's just that javac doesn't know that. In the process of converting normal Java bytecodes into Squawk bytecodes, we can do a lot of cleanup. The simplest trick that comes to mind is to pattern match in the static initializer "clinit", looking for the initialization of the anonymous field with a call to the anonymous method.

If we simply replace the call to class$("java.lang.String") with a load of the class literal, then the anonymous method will not be called, and the dead method elimination (DME) phase will delete the method.

Getting rid of the anonymous class is trickier than I first thought, because the cache variable ("class$java$lang$String") gets declared in the anonymous class. In theory we can handle this by constant propagation - the cache field is final, and is really initialized by a constant value, so we can replace references to the cache with the load of the constant class litereal. If we implemented dead field elimination there would be no references to any fields or methods of the anonymous class and dead class elimination (DCE) could do it's job!

I've got to get dead class elimination checked in one of these days, but in the meantime I now know where all of these anonymous classes are coming from.

ps. I'd like to thank openjdk.java.net for having the sources for everything, in particular Lower.java.

About

Out of the fog... of bits, bytes, and really small Java Virtual Machines, by Derek White. The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today