Ask Your Question
2

Laserscan subscription delay! rosjava on android

asked 2012-06-06 02:03:35 -0500

ch1bo gravatar image

updated 2012-06-06 02:05:42 -0500

Hello,

I am currently working on an android application for visualization of sensor data. During my first test projects I encountered a serious delay in messages caused by message deserialization of the LaserScan messages (at 40Hz).

The only way I could solve the delay issues was to inhert from the the private Receiver class in IncomingMessageQueue.java of rosjava and have the new class RateReceiver, ignore message when it falls below a rate threshold (code attached).

I am now searching for a way to augment rosjava / the android framework to use my code. After i researched the instantiation hierarchy of Receiver < IncomingMessageQueue < Subscriber < SubscriberFactory < DefaultNode I was wondering what is the best way to subclass and integrate my code? Currently the SubscriberFactory cannot be changed via the NodeConfiguration class (but there was a TODO in the code related to future configuration options? -> DefaultNode.java:89) Are there any plans regarding a custom Subscriber(Factory) class?

Or is there even a better way to solve that delay problem? (If i remember correctly I had also delays with receiving camera images)

(As for hardware: The code runs on a Asus Transformer Prime with Tegra3 1.4GHz quad and 1GB of ram, Android 4.0.3)

I hope someone can help me, and thank you in advance!

Regards, Sebastian

private final class RateReceiver extends Receiver {

    private int count;
    private double time;
    private double curRate;
    private double refRate;
    private double tolerance;
    private int window;

    public RateReceiver(double rate, double tolerance, int window) {
        this.refRate = rate;
        this.tolerance = tolerance;
        this.window = window;
    }

    @Override
    public void messageReceived(ChannelHandlerContext ctx, MessageEvent e)
            throws Exception {

        count++;
        if (count % window == 0) {
            // Reset measurement
            count = 0;
            time = System.currentTimeMillis() / 1000;
        } else {
            // Calculate rate
            curRate = count / (System.currentTimeMillis() / 1000 - time);
        }

        if (count % refRate == 0) { 
            System.err.println("receive rate " + curRate);
        }

        // Only process messages when inside tolerance
        if (curRate > refRate - tolerance) {
            super.messageReceived(ctx, e);
        }
    }
}
edit retag flag offensive close merge delete

Comments

I'm currently encountering a very similar ROSjava problem with rapid TF messages. Have you looked for "GC_CONCURRENT" messages in the Logcat output of your Andriod application? I've noticed that receiving certain messages in ROSjava triggers a garbage collection in the deserialization.

azimmerman gravatar imageazimmerman ( 2012-06-10 14:26:41 -0500 )edit

I have these "GC_CONCURRENT" messages too! The deserialization seems to be done with reflection by default, but I've found that there are different MessageDefinitionProvider classes for Message(De)Serialization in the rosjava framework (might use msg definition files)!?

ch1bo gravatar imagech1bo ( 2012-06-10 20:41:10 -0500 )edit

After some research, I found that rosjava extensively uses java.reflect and proxies for message instantiation. This leads to somewhat expensive access to message properties. I could reduce the GC_CONCURRENT msgs and delay a little bit by optimizing some String handling. But its still an issue!

ch1bo gravatar imagech1bo ( 2012-06-11 03:30:52 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2012-06-27 01:00:31 -0500

ch1bo gravatar image

The issue got resolved in the current rosjava revision.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

2 followers

Stats

Asked: 2012-06-06 02:03:35 -0500

Seen: 355 times

Last updated: Jun 27 '12