Sharing experience robot JAVA programming on Raspberry Pi

For those interested in robot control via JAVA programs on the Raspberry PI, I have posted an update on my experience with JAVA in my robot description here:

https://www.robotshop.com/letsmakerobots/search-and-rescue-robot

Even better, if you are able to offer any help or advice, that would be great. I am slowly running out of options......

Regards,

Willem

 

I’ve used Java to accurately
I’ve used Java to accurately control servos, but I was using an embedded Java board, either the JStick or the JStamp, at the time. This was over ten years ago.

On the Pi, I would use Java SE for overall control, and communicate with an Arduino and other peripherals via serial or USB. On the RasPi, Java is just one process out of many and it isn’t a realtime system.

I have shared a new update

I have shared a new update on my project for an autonomous “search and rescue” robot.

https://www.robotshop.com/letsmakerobots/search-and-rescue-robot

I managed to get all base components working in Java SE using the jdk.dio libraries from Java ME to do GPIO control. I am using PI4J/WinringPi for PWM for the motors, connected via a separate motor board to protect the Pi. Each motor is then controlled using two pins. The servos are controlled via servoblaster software. So still trying to do the maximum in software.

Next steps is to build the logic between motors and wheel encoders.

 

video added

First video posted of driving straight line, adjusting power to the motors based on reading of wheel encoders.

Maybe we could uses this thread
to talk about general experiences with Java on the RasPi rather than just use this to point back to your robot.

I’d rather talk about Java separately than robots. Also other people might join in if this were more than a pointer to your robot where they might feel inhibited about talking about their own experiences.

fine with me

Fine with me, as long as it is Java and robots related, but I can’t remember or see in which forum topic I posted this message. A discussion about Java should be in the programming forum I think.

I looked and couldn’t find
I looked and couldn’t find it in the forums, though it’s a forum posting.

I’ve been using Java since
I’ve been using Java since before Java 1.0. It impressed me because it was the first cross-platform system I’d seen that had real cross-platform networking. My last project for Penn State was a huge Java project made almost important by bad object design. It was designed by a grad student with no experience in OO programming while the project lead was off on a six month honeymoon walking across India.

I begged my manager to let me redesign the whole thing, because instead of decent objects, most of them were kitchen-sink objects which did lots of different things and had public variables which should have been private.

In robotics after I did my stint with PIC chips, I used the JStamp and JStick – Java microcontrollers.

Now I’m using Arduinee things and PCs to control robots.

Java Robots

For the most part, I like doing robotics in java on Android.  I follow the model DT just described, having an Android interface with a microcontroller through USB.  It helps if you have some kind of standardized messages that pass back and forth.  I haven’t tried interfacing directly with sensors (other than droid sensors) from anything running Java.

I finally ordered a Pi 2, so I’m curious about the prospect of running java on the Pi and getting a little closer to the sensors…perhaps.  I’m still clinging to my gut instinct to have a microcontroller on board.

I’m going to follow this thread to see what I can learn.

I’ve been using Java for 4

I’ve been using Java for 4 years now and i still feel i just scratched the surface of what can do. It’s more like a virtual OS. It runs surprisingly fast, usually just 2% slower than C (i have tests). I’ll sure try to control robots with it!

As for checking sensors,
As for checking sensors, couldn’t a Linux daemon be created to check certain sensors, just like servoblaster does for servos?

It might be more complex than servoblaster because of the many different ways sensors can be read. Or maybe different daemons for different classes of sensors: sonarreader, adcreader, and digital reader.

I’m just thinking out loud here.

why would you want to do that?

For reading sensors you either go and check the value on the spot, or you implement a pin listener which waits for a value change and triggers a method/function and changes a value, which you then can use in the rest of your program. Very short and easy code.

Here is for example the code for the wheel encoders, which increments a counter each time there is a change in value, i.e. each time field in front of the sensor changes between black and white. The code for the bump detectors is almost the same.

package robot.v3;

import java.io.IOException;
import jdk.dio.DeviceConfig;
import jdk.dio.DeviceManager;
import jdk.dio.DeviceNotFoundException;
import jdk.dio.gpio.GPIOPin;
import jdk.dio.gpio.GPIOPinConfig;
import jdk.dio.gpio.PinEvent;
import jdk.dio.gpio.PinListener;

public class IREncoder implements PinListener {

    private int encoderPinID;
    private int PortID = 0;
    private GPIOPin encoderPin;
    public int encoderCounter = 0;
    private boolean encoderValue = false;

    /constructor/
    public IREncoder(int GPIOnr) {
        encoderPinID = GPIOnr;
    }

    public void start() throws IOException, DeviceNotFoundException {
        System.out.println(“Start encoder listening at PIN nr:” + encoderPinID);
        GPIOPinConfig config1 = new GPIOPinConfig(PortID, encoderPinID, GPIOPinConfig.DIR_INPUT_ONLY,
                DeviceConfig.DEFAULT, GPIOPinConfig.TRIGGER_BOTH_EDGES, false);
        encoderPin = (GPIOPin) DeviceManager.open(config1);
        encoderPin.setInputListener(this);
    }

    public void reset() {
        encoderCounter = 0;
    }
   
    public int getCounter() {
        return encoderCounter;
    }

    public void close() throws IOException {
        if (encoderPin != null) {
            encoderPin.close();
        }
    }

    @Override
    public void valueChanged(PinEvent event) {
        GPIOPin pin = (GPIOPin) event.getDevice();
        if (pin == encoderPin) {
            if (event.getValue() != encoderValue) {
                encoderCounter++;
                encoderValue = !encoderValue;
                System.out.println("change detected at encoder " + encoderPinID + " value " + encoderCounter);
            }
        }
    }
}

Sonar
To use the common ultra sonic sensors, one needs to send a short pulse and then wait for the reply.

The trouble with any high level language is that the process might be switched out sometime during this period,which may mess up the timings. I agree that most other sensors are not as timing-specific.

I agree, with that sensor I

I agree, with that sensor I had some trouble (using the PI4J libraries and JAVA SE, see robot experience description), which I solved by switching to the jdk.dio libraries and the use of two pins. Apparently that works fast enough to catch the full return signal and calculate the distance, despite everything else going on in the operating system. I also tried a pin listener for the Ultrasonic similar to the example posted here of the IR wheel encoder. The pin listener also worked fine. Distance seems to be quite accurate with the occasional strange reading (maybe because of an interrupt). I need to get experience in practice and see whether one reading is good enough of whether I need to average out a number of readings or maybe throw out the ones which are deviating too much from the rest.

Pare down the OS
One thing that will improve the performance of Java on any platform is to remove any programs that you don’t need running.

Speaking for Linux, most robots don’t need a windowing system. I’m not saying remove this from the disk, because you might just want to play a game of nethack or read mail while your bot is offline. Just don’t have cruft running when the bot needs the time to read sensors and control motors.

I’ve also heard mixed reviews of a real-time Linux.

Frankly this will improve any sort of high-level OS such as Windows, MacOS, Android, and of course Linux.