UltraBorg Filter

Forums:

Hello and a good day,

recently I discovered your UltraBorg board.

It seems clever and interesting to me.

In your documentation you broadly write about the
filtering for connected Ultrasound Sensors.

Could you describe a little bit what the filtering
algorithm tries to achieve?

Why can it be omitted easily in your examples?

Actually I thought the Ultrasonic sensors are
"programmed" to directly control the servos behaviour.

In your examples you do the ultrasonic reading and servo
writing "manually".

So is the 'standard' configuration of the UltraBorg sending
signals directly from the Ultrasonic Sensors to the Servos?

If not .. could this 'easily' be achieved
by reprogramming the "PIC source code"?

Would you mind to list a practical "PICKit 2" reference?

Can this PIC programming not be achieved directly from the
raspberry?

Thanks for some infromation.

Andreas

piborg's picture

The filtering in the UltraBorg is intended to give a more stable reading then you would typically get from the HC-SR04 sensors.
The reason we do this is because the HC-SR04 sensors are "noisy", in other words the reading you get from them can vary when nothing changes.

What the UltraBorg does is to look at several readings to decide what the actual value should be.
This reduces the amount of error on each reading, making the values more accurate.

The reason some of the examples do not use the filtering is that it is not always desirable.
This is because the filtered reading takes longer to change to a new value than the unfiltered reading.
The result is a fast-changing position tends to have a delay before the filtered value catches up.

The standard code on the UltraBorg is designed to allow another device to both set the servo positions and read the ultrasonic distances.
This can be almost any I2C capable device, such as a Raspberry Pi, Arduino, BeagleBone, or PIC.
It does not normally move any servos on its own, except for when it is turned on.

It should be reasonably easy to adapt the PIC source code on the UltraBorg to allow it to drive the servos on its own.
The code is all written in C, we would recommend this page as a good guide for learning if you do not know any C already:
http://www.learn-c.org/

We used MPLAB X IDE for creating the PIC source code, you can get it here:
https://www.microchip.com/pagehandler/en_us/family/mplabx/
There is a getting started guide from Microchip here:
http://microchip.wikidot.com/tls0101:start
Our standard PIC source code can be downloaded here:
http://www.piborg.org/downloads/ultraborg/UltraBorg.X.zip

Be very careful if you make changes to the PIC code, driving a servo outside of its operational range for too long can damage it!

I believe it is possible to re-program a PIC from a Raspberry Pi using the GPIO, but it requires making a circuit yourself.
See this page to get an idea of what I mean: http://holdenc.altervista.org/rpp/
MPLAB X IDE will build the HEX files you need for the rpp command.

Hello and
thank you very much for the fast and detailed answer.

I really appreciate your more in depth information.

It is good to read that with rpp and for example http://mujweb.cz/tlc/rpp/
free and self made PIC programmers are possible.

But because what I read fast(<3 sec) reprogramming seems not likely
and I am not that quick in soldering and circuit assembly I seek for affordable
supplements if possible.

It seems to me that the DIAMEX PIC-PROG Programming Tool or Diamex Pic-Prog Plus ICSP Programmer would just fit on the UltraBorg.

Do you think that is correct?

http://www.amazon.co.uk/Diamex-PicKit-Pic-Prog-Programming-Tool/dp/B00EZ...

Sincerely
Andreas

piborg's picture

It does look like the Diamex Pic-Prog should be compatible with the PIC fitted to the UltraBorg.

Alternatively either a PICkit 2 or PICkit 3 programmer should work, both used and new ones can be found on EBay at reasonable prices.

I am not sure how fast the reprogramming would be with any of the devices mentioned.
Is there a reason you need to reprogram the UltraBorg quickly?

Hello and thank you for the responses.

Actually there is not right now a reason but some 'vision'.

You demonstrate instant servo reaction to sensors is sometimes more desirable.
One way to allow more instantaneous reaction you show by omitting
the filter in between the sensor input and servo output.

Another way would possibly be to develop a new 'filter' or
sensor-servo-activation pattern and flash this to the Ultraborg pic.

And an even more advanced scenario would possibly have a set of
certain sensor-servo-activation patterns flashed dynamically and directly
from within the raspberry on certain 'external'-situations
of a servo-sensor system to be build.

This dynamic flashing would certainly have some time constrains.
And in general such a very speculative system would possibly be build
with other more advanced components.

As you see all this is very speculative and probably quite hard to achieve anyway.

Much more experience and development would be needed
so rather the question was a bit over my own 'borders' and capabilities.

Sincerely
Andreas

Subscribe to Comments for &quot;UltraBorg Filter&quot;