Kwatters asked me about the intention of Arduino Sensor attach.  I know it could be refactored, but its good to know the intention before doing so.

The general goal is quite simple :  Support as many sensors as possible with as little code !

So the idea I had was a generalized Sensor would exist in the MRLComm.c.  This struct is a union of all the sensors data we desired to support.  Not a C-union (because those can be even more tricky with memory issues), but just a simple struct.

Some sensors need state information - like Ultrasonic  Sensors.  Because they move through a set of states in order to provide useful information (like distance).  Other sensors have other requirements.

Super simple sensors are pins.  They come in 2 flavors Digital and Analog.

One thing which varies between sensors, is the "type" of data they return.  
Here's a short list.

Sensor   Return Type Range  Java-Land
Analog Pin 10 bit value  0-1024 int
Digital Pin 1 bit value 0-1 int (ya not byte nor bit)
Ultrasonic Sensor  32 bits 0-(2^32 - 1) long
IMU array[3] of 2 byte values   int array[3]
Other Stuff array[?]   array[] of stuff

So potentially there is a lot of "Other Stuff"

To keep things clean and simple and conver all these return types coming back - there should really only be one return type ..  an array of ints of "some" length, because all other types can be interpreted from it.

Again to keep things clean and simple all "interpretation" of the return type should be done in the appropriate Sensor Service.  For example, the interpretation & calculation of distance needs to be done in the UltrasonicSensor Service NOT in the Arduino.

What should happen is the following :
A sensor service should attach itself to arduino.  In the attach method it should specify the length of bytes it should receive back in an array.  The Arduino & MRLComm.c & the sensor struct should comply.

The Arduino Service itself should handle its own pin "sensors" in the same way .. attach its own Pins, request appropriate sized int arrays and re-interpret and publish the data.

How much of this is done, and in what (transitory) state the code is in I can't exactly say .. but that was the intent.

Hope this clears things up.

hairygael

7 years 10 months ago

I have been waiting for my finger sensors on InMoov to become active since a while and this seems to be the perfect match!

Yup.  reliable analog feedback is important.  I want to replace the hs805bb servos with just a potentiometer and a motor controller.  Getting this analog feedback working in a "rock solid" manor is going to be key to it. 

I've been adding a lot of additional capabilities to MRLComm so that we can more easily debug and hut down these issues.  I'm currently seeing some very odd behaviors in the Arduino / MRLComm code.  I'm hoping that with this latest round of refactoring and code cleanup, it will be easier for others to read the code and understand what is going on.

This journey is not done...  we're just getting warmed up.  :)

I'm trying now to make the Ads1115 Service to be able to publish Analog values using the same design pattern as the Arduino. So I guess that it should be a SensorDataPublisher in some way.

I also found the AnalogPinSensor class. How do they relate to each other ?

As a bit of background I'm trying to start building the software servo that kwatters has been talking about a bit before. The basic idea ( I think ) is that any motor and any analog input value should be possible to combine with a PID to form a software servo.

At first I was thinking that any servo and any motor should be possible to combine, but now I think it would be easier to just create a new motortype that represents a continous rotation servo without feedback.

That way the new software servo could simply attach to a MotorController, independant of what type of motor it is. I feel that it should implement  the ServoControl methods with some additional configuration methods.

The major difference between Servo and the new servo is that it also need an Analog input value.

Trying to take some more steps in the direction of Automatic Binding Bricks. ( That was the name that LEGO used in their early days )

I know that kwatters also want's the software implementation in MRLComm. I think that can be a possible solution if both the MotorController and SensorDataPublisher are in the same Service, but I think it is an exception to the more generic implementation and only needed if we get performance problems.

 

Grog answered me in the shoutbox, so I'm just writing down what he told me so that anyone interested can have the same information.

For the pins, analog or digital, an inteface PinArrayControl has been defined. It's used in Arduino and I'm currently implementing it in Ads1115 ( A 4-pin 16-bit A/D converter ) that you can connect to the i2c bus of either the Arduino or RasPi. 

The PinArrayControl has methods to publish sensor data either on a pin level or as an array of pins and values. 

 

GroG

7 years 10 months ago

Ahoy !

I'm gonna guess these are the Acks you put in Kwatters...  should we make be a full fledged method, with a generated codec entry ?

Hi

If you generate the codec, it will generate entries for 5 new methods.

3 will be used in the communication with MRLComm: i2cWrite, i2cRead, i2cWriteRead.

2 will only be used in the Arduino to keep track of the status of the diffrerent i2c devices:  createDevice and releaseDevice. Reading what I write now, perhaps I should rename them to i2cOpen and i2cClose ? 

In any case, the last two methods don't need any codec entry, since they won't be needed in MRLComm.

I also read thru the Arduino code and found a design pattern to use so that the i2c devices can use syncronous/blocking reads even if the Arduino / MRLComm is asyncronous. The getVersion design is a good template to use :-) 

/Mats

kwatters

7 years 10 months ago

Yup..  We'll make sure to carry that stuff forward.  We will eventually refactor it out for the whole auto-generated stuff, but reality is, I started peeling back the layers and discovered much stuff that should be cleaned up and straightened out.  

I will do my best to maintain as much backwards compatability as possible.  One of the biggest changes is really that the pin numbering is a bit odd for myrobotlab.  For example if you have an Uno plugged in, analog pin A0 is actually pin 14 in MyRobotLab.  This is a bit too confusing, especially when you change to a Mega, and now A0 is pin 53 ..  

Now the push, i believe, is to move towards using "Sensors" and publishing SensorData.  So now the Arduino calls publishSensorData with it's analog and digitial pin polling information.  This new approach is at odds with the older style of analog/digitial pin polling start/stop methods as the functinality completely overlaps.

So.. long story short, what I was hoping was going to be a small bug fix is turning into a much more full scale refactor...