From the ancients Pingdar rises again !

Kmcgerald new of the ancient Pingdar...  I rubbed a little dust off of it, and was pretty excited to see it work with the new services.

This is all virtual ! .. I'll test it tomorrow with real hardware (what could go wrong ?) :)
But I'm happy to say the virtual worked really well - this is using UltrasonicSensor Service as a peer & Servo.  Its also using the VirtualArduino running the emulated MrlComm using a  WOOHOO !

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
GroG's picture

I couldn't wait ... It only

I couldn't wait ...
It only takes a single line to flip from virtual to real hardware.
Virtual coding is so easy, I can do it anywhere. I don't need to hook up messy wires, or burn servos, or pesky uncooperative Arduinos with moving com ports.  I debug and can step all the way through the code ... them's goodtimes...

Below is the single line to switch from virtual to real hardware.

trigPin = 8
echoPin = 7
servoPin = 9

Runtime.start("gui", "GUIService")      
virtual = Runtime.start("virtual","VirtualArduino")

# virtual.connect("COM5")

pingdar = Runtime.start("pingdar", "Pingdar")
pingdar.attach("COM5", trigPin, echoPin, servoPin)
pingdar.sweep(70, 100)

And this is running real hardware !

Worky ! - there is a wall & monitor on my desk on the right side of pingdar - its in cm mode now ..and the wall is about ~25 inches / 66 cm away.  It looks curved when it should be straight.. probably a bug in my polar translation.  Anyhow, I still need to sort our the check-in .. got all the JMonkeyEngine stuff half-in.  I'm sure there are ways to make it more accurate, higher resolution, smoother lines, auto-scaling.. etc etc etc..
but its bedtime now...  I'll try pushing it tommorrow ...


Mats's picture


Wow. Really nice.

I will soon get this device that works very similar to the Ultrasonic sensor, and with very good resolution. 

It would be really nice to be able to use the Pingdar service together with other devices, other than the UltrasonicSensor and the Arduino.

The idea is to create a new service that will implement RangeListener and some yet to be defined DistanceSensorControl, or something similar.

I know that the RangeSensor interface doesn't exist yet and neither does the Time to flight Distance Sensor, so a good time to discuss how they should connect together.

I think I should create a DistanceSensor service, that can contain logic for several different hardwares. For example this sensor is very similar.

I'm not sure yet, but I think the DistanceSensor service should be similar to UltrasonicSensor.

What I see all the time when I implement new services is a problem with the Peer concept. Services that start other services at a lower level without using the interfaces.

Imho the users should have the freedom to connect services together freely. So I need to know how to override the Peers the correct way. 

For example the Pingdar starts an Arduino Peer, so it assumes that an Arduino exists and has a connect method. That doesen't necessarily exist in other services that implement the interfaces. I think you can start to see the problem with the Virtual Arduino. 

In the code snippet above, I don't understand how the Pingdar service knows that it should use the virtualArduino and not a real Arduino.

 And how should I write to use the Adfruit16CServoDriver to connect to the servo instead of an Arduino ?

kmcgerald's picture

I like it

Mats, I have the same lidar sensor but's version ( and I agreee we should have a range finder service that can abstract the various sensor types.  I'm currently using one of them on my Zumo, mini sumo robot so it can search for it's opponent.  I have a second one that I haven't installed on the other Zumo yet.

GroG's picture

Hi Mats,its great when you

Hi Mats,

its great when you just suggested several things I've implemented locally :D
It means were thinking along the same lines...

package org.myrobotlab.service.interfaces;
public interface RangingControl extends DeviceControl {
public void startRanging();   
public void stopRanging();   
public void setUnitCm();   
public void setUnitInches();
package org.myrobotlab.service.interfaces;
public interface RangeListener {     
public void onRange(Double range); 

package org.myrobotlab.service.interfaces;
public interface RangePublisher {   
Double publishRange(Double range); 

"Imho the users should have the freedom to connect services together freely."

I completely agree .. 

In fact this is related to the Attach post ( and the idea that there should be a default behavior, and the user should be able to attach one service to another with the minimal amount of complexity (without blocking the ability to access more complexity)

The peer utilities were a means to do this with 'configuration' vs code..   Because in many instances the user doesn't have access to code, but may have access to configuration.  I don't know if what I've done with peers & MRL DNA - (  / )   But, the general idea was to creat config which could change names & types "easily" for the user.   I don't think a lot of the users know that its there or understand it fully.

Each service is supposed to have a "default' config for itself and the peers it references.. This is the stuff you see in getMetaData..

meta.addPeer("torso", "InMoovTorso", "torso");

In complex services - there might be shared resources - and you use 'sharing' to basically create the same name at two points in the configuration

meta.sharePeer("head.arduino", "left", "Arduino", "shared left arduino");

And as you were referring to earlier - "type" - in the case "Arduino" is just a string value, so it could be changed to any type which satisfied the peer's interface.

I like to imagine the future where you could query MRL with a HTTP request - get a large DNA definition (I think this can be done now) .. modify it - and post it back, and the workflow could give you access and control over all peer defintions - both of names, sharing, and typed resources

GroG's picture

In the code snippet above, I

In the code snippet above, I don't understand how the Pingdar service knows that it should use the virtualArduino and not a real Arduino.

If I uncomment the 


The virtual arduino will hijack the COM5 port, and anything connecting to COM5 will really connect to the VirtualArduino regardless if the hardware port actually exists..

hence, commented out == connect to the real COM5
uncommented == connect to the virtual arduino


kmcgerald's picture


Grog the one man Quick Reaction Force.  I'll be ready to test tonight.  Got raspbian jessie installed on the Pi3 last night and updated all the packages.  java 1.8 is installed.