I did build a Holonomic drive train and now I’m trying to put a sensor on each corner so when it reach about 4 inch from the walls it decrease the power from 0.5 to 0.2. I do have 2 Rev 2 meter distance sensors and 3 Rev color sensors V3. I did put 2 V3 in one side and 2 , 2 meter distance sensors on the other. I did get this thing to work out but I’m having a problem with the Rev color sensors as from the 3 Color V3 sensors I got 2 of them are making the motors work not in constant speed but playing in 0.5 and 0.2 of power . Could it be the sensors are broken ? or there is something I can make to fix this. The other V3 Sensor works perfect . I attached a screenshot of the Blocks OpMode as well,
I can’t remember if the differences between the v2 and the v3 are obvious but I’d inspect them as best I could to make sure you have all 3 of the same version.
But that probably doesn’t matter as you have to use what you have. So I’d graph the raw outputs as the sensors approach the wall. That could give you good insight into what the sensors are doing and what you can do about it to accommodate them.
You didn’t mention if they don’t work at 4 inches but are okay at 1 or 2 inches. Since the whole point of the sensors is to detect light, you can get better or worse detection depending on the ambient lighting. On our robot we had to add another bright LED to illuminate the target area well enough to get the range we needed.
The LEDs that were used to illuminate are sensitive to the supply voltage and we noticed the LEDs were significantly dimmer with more motors, speed, acceleration, weight of the robot, etc. We had to write algorithms that tolerated a wide variation in absolute raw output of the sensor.
You can get more stable illumination using a voltage regulator.
I did checked the 3 sensors and they are all labelled Colour Sensor V3. They all do reduce the motors power to 0.2 when they reach the target of 4 inch ,but when you leave it in constant power in 0.5 for let say more than 30 seconds without the sensor enabled you can hear and see that the motors are not giving the same amount of power ,it’s like the power is playing
Do you mean the sensor is more than 4 inches away from the wall so it’s not supposed to be activating but seems to be activating? I’d log what the sensor is doing and the motors are doing to correlate precisely the sensor and motors relationship.
If you are getting spikes in the sensor signals you can filter them. WPILib Debouncer might work as a spike filter or something like this that I found on the Internet. Adjust parameters for the lag that you can tolerate.
package frc.robot.Sensors;
// Predicts current value from window of history and requested rejection criteria.
/*
https://gregstanleyandassociates.com/whitepapers/FaultDiagnosis/Filtering/Spike-Filter/spike-filter.htm
Overview of spike filtering
The purpose of a spike filter is to suppress extreme changes in measured variable values, since they probably
don’t reflect actual changes in the monitored process. Small input changes are passed through without
modification. For example, given existing pump capacity, it may be physically impossible for a drum level to
increase or decrease more than a few percent in one time interval, unless there is a rupture in the drum or
piping. Or even if it is physically possible, a flow might not normally change more than 10% within one data
sampling interval. However, in case the extreme change remains in place n times in a row, then the change
must be accepted as real. For example, there may have been a large change in setpoint, or loss of flow due to
pump failure. Or even if the change is physically impossible, there may have been an instrument
recalibration or sudden change in sensor bias that persists.
When using a spike filter, it should be placed first in the signal path, ahead of any other filter. That way,
it can be tuned independently of the other filters. Other filters would dampen the spike to an extent
dependent on their tuning. In normal conditions, operation of the other filters remains unaffected because
the spike filter passes through routine small variations without modification.
A simple spike filter has two parameters, M and n. M is a maximum change parameter. M is set so that in
normal operations, the input does not change by as much as M from one time step to the next. The parameter n
is the number of extreme changes in a row that will be rejected before finally accepting a large change, with
possible values n=0,1,2,…
In this form, the filter stores its previous output and a counter c for the number of times in a row an input
rate of change has been violated. The filter would be initialized to c = 0 and the input matching the output.
An example implementation of a spike filter
FilterFor a "pseudocode" implementation example, we use the filter notation already introduced:
IF ( | (x(k) – y(k-1) ) > M | AND c < n ) {
// recent big change: hold previous safe value
c = c+1
y(k) = y(k-1)
} ELSE {
// normal operation, or else the recent big change must be real after all
c = 0
y(k) = x(k)
}
where
x(k) is the raw input at time step k
y(k) is the spike-filtered output at time step k
c counts how many times in a row the input values have been outside the legal range
Since extreme changes may result from failures, or result from sudden setpoint changes made during plant upsets
(and sample intervals may be fairly slow), n will not typically be greater than 1 or 2, or diagnosis could be
significantly delayed. The n= 0 case is included so that spike filtering may be easily turned off.
Copyright 2010 - 2020, Greg Stanley
*/
class SpikeFilter {
private double Mabsolute; // max absolute difference between 2 values
private double Mratio; // max absolute ratio of difference between 2 values / previous value
private int n; // 0 is off; suggest 1 or maybe rarely 2
private int c;
private double prevInput;
private boolean firstTime = true;
/**
*
* @param Mabsolute difference to suppress
* @param Mratio difference to suppress
* @param n count periods, 0 is off; suggest 1 or maybe rarely 2
*/
public SpikeFilter(double Mabsolute, double Mratio, int n){
this.Mabsolute = Mabsolute;
this.Mratio = Mratio;
this.n = n;
this.c = 0;
}
public double calculate(double rawInput) {
if(firstTime)
{
firstTime = false;
prevInput = rawInput;
}
if((Math.abs(rawInput - prevInput) > Mabsolute ||
Math.abs((rawInput - prevInput)) > Math.abs(Mratio*prevInput))
&&
c < n)
{ // large change; use previous good value
c++; // count number of times large change
return prevInput;
}
else { // normal input or large change is holding
c = 0;
prevInput = rawInput;
return rawInput;
}
}
public void setLimit(double Mabsolute, double Mratio) {
this.Mabsolute = Mabsolute;
this.Mratio = Mratio;
this.c = 0;
}
}
It’s hard to diagnose a slightly bad sensor but it’s easy to tug and wiggle wires to find poor connections. That’s the cause of many troubles.
No the sensor will work when its 4 inch range it will put the power to 0.2. The problem is that when you drive the 4 motors you can see that the motors are not having all the time the same amount of power it fluctuate between 0.2 to 0.5 but only when i set these two sensors of the 3 color sensors .With one of the it keeps the power constant.
If this is for an FTC competition bot keep in mind the competition field walls are transparent. As a rookie coach we were a low resource team and had a cardboard field. We made an autonomous that used distance sensors….worked great in practice. In competition it failed because of the glass. We would get random readings from the sensors.
Super frustrating for 10-11 year olds.
Fun fact: I used this experience to get funding to get ALL Detroit FTC teams full fields. So there was a great outcome from our pain.
It’s not for FTC neither for any competitions,I just build for myself to learn in my spare time,I guess both the sensors are damaged as they keep on doing the same no matter what I do in the code.
I’m not sure exactly your sequence of events for testing and that does matter for troubleshooting. For example, if you have no problem with 1 sensor and then you connect the 2nd and 3rd, that could indicate you didn’t change the I2C address of the 2nd and 3rd sensor if they are on the same bus which is the typical case (even if they appear to be separate ports). You can prove that by running a “failed” sensor as the first and only one connected and see if it works. Do that for the other “failed” sensor and test that one alone, too.
The chances of failed hardware are very slim compared to bad code or misapplication. You haven’t considered all the possibilities yet (at least you haven’t shared them with us).
I did tried to plug the 3 sensors in the same port running the same opmode and restarting it. But only one of them works as the opmode . I did tried as to reduce the distance of the senser from 12 to 5 cm and it stops the problem. Will try to create a new opmode and see how it goes.
