Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scale in sonar widget not correct #17

Open
alcantara09 opened this issue Jun 10, 2016 · 13 comments
Open

Scale in sonar widget not correct #17

alcantara09 opened this issue Jun 10, 2016 · 13 comments

Comments

@alcantara09
Copy link
Contributor

Comparing the data from the sonar samples and the visualization in the sonar widget, it is possible to notice that the visualization is not correct. I would say that is 10 times smaller.

@romulogcerqueira
Copy link
Contributor

@alcantara09 , could you give us more details?

@alcantara09
Copy link
Contributor Author

@romulogcerqueira ,
the error is in the sonar widget. In fact, I think the range is not being applied to the visualization. No matter which range you choose in the widget, the readings from the sonar remains at the same scale.
range_bellow_1m
range_60m

and the script to that produces the error is just running the sonar simulation component and the sonar widget as this one

`require 'rock/bundles'
require 'vizkit'
require 'rock/gazebo'

include Orocos
Bundles.initialize

model_path = File.join(Dir.pwd, 'models','sdf')
world_path = File.join(Dir.pwd, 'scenes','uw_structures', 'uw_structures.world')

Execute the task

Bundles.run 'imaging_sonar_simulation::ScanningSonarTask' => 'sonar_sim' do

## Get the specific task context ##
sonar_sim = Bundles.get 'sonar_sim'
#set an array with model paths
sonar_sim.model_paths = [model_path]
#path to world file
sonar_sim.world_file_path = world_path
## Configure the tasks ##
sonar_sim.configure

sonar_gui = Vizkit.default_loader.SonarWidget
sonar_sim.sonar_samples.connect_to sonar_gui 

## Start the tasks ##
sonar_sim.start

#input with at the origin with 0 velocities
rbs = Types::Base::Samples::RigidBodyState.new
rbs.position = Eigen::Vector3.new(0,0,0)
rbs.orientation = Eigen::Quaternion.new(0,0,0,1)

sim_pose_writer = sonar_sim.sonar_pose_cmd.writer
timer = Qt::Timer.new
timer.connect(SIGNAL('timeout()')) do
    sim_pose_writer.write(rbs)
end

# start the timer with a timeout of 10 ms
timer.start(10)
sonar_gui.show
Vizkit.exec 

end`

@romulogcerqueira
Copy link
Contributor

Hi @alcantara09,

I had a look at your script code and apparently it is not a problem in sonar widget and/or sonar simulation. You need to connect the task properties with the sonar widget sliders. Please perform the following steps:

  • Insert these lines after sonar_sim.sonar_samples.connect_to sonar_gui :
  ## Set the signals ##
  sonar_gui.connect(SIGNAL('rangeChanged(int)')) do |value|
    sonar_sim.range = value
  end
  
  sonar_gui.connect(SIGNAL('gainChanged(int)')) do |value|
    sonar_sim.gain = value * 1.0 / 100.0
  end
  • If the problem is still happenning, open rock-display and try to change the properties range and gain manually.

Please let me know your attempts.

@doudou
Copy link
Member

doudou commented Dec 1, 2016

You need to connect the task properties with the sonar widget sliders. Please perform the following steps:

You are not computing the ranges from the sonar data ?

@romulogcerqueira
Copy link
Contributor

You are not computing the ranges from the sonar data ?

Sorry @doudou, I didn't understand your question. range is a property of imaging_sonar_simulation. If we wish to change its value runtime using script and sonar widget, we need to set the signals of sonar widget gui.

@doudou
Copy link
Member

doudou commented Dec 2, 2016

The max range is in effect embedded in the sonar data structure (bin_duration * bin_count * speed_of_sound). IMO visualization should match what's there. The max_range control should really only be that, a control.

@doudou
Copy link
Member

doudou commented Dec 2, 2016

The problem here is that the sonar widget is completely broken when used in e.g. rock-display, which is still the primary use case, and due to vizkit limitations there's no way to automatically plug the range to the sonar component when opening a sonar display.

@romulogcerqueira
Copy link
Contributor

romulogcerqueira commented Dec 3, 2016

The max range is in effect embedded in the sonar data structure (bin_duration * bin_count * speed_of_sound).

I agree with you. This makes sense in the most sonar devices (like Tritech DST Micron), however Tritech Gemini and Teledyne Blueview sonars have a range compression which limits the bin_count between 750 -1500 bins, and its value is not proportional to range one (e.g. we can have 1350 bins at 20m and 900 bins at 25m).

@romulogcerqueira
Copy link
Contributor

IMO visualization should match what's there. The max_range control should really only be that, a control.

In this case, when the range value is changed, the bin_count will also be changed, right? Currently in sonar simulation the bin_count is not dependent of range value. I can fix it now we have a dynamic shader image.

@doudou
Copy link
Member

doudou commented Dec 5, 2016

Range is controlled by two parameters, the bin_count and the time-per-bin. The latter is usually what's used to control, since one likely uses the max. bin count of the sonar (to get the best resolution)

@doudou
Copy link
Member

doudou commented Dec 5, 2016

(I'm not even sure that one can change the bin count in practice .... I don't see any benefit in doing so)

@romulogcerqueira
Copy link
Contributor

Range is controlled by two parameters, the bin_count and the time-per-bin. The latter is usually what's used to control, since one likely uses the max. bin count of the sonar (to get the best resolution)
(I'm not even sure that one can change the bin count in practice .... I don't see any benefit in doing so)

My mistake, sorry! As you said, we already have this relationship in the sonar simulation here to define bin_duration. It is not needed to change the bin_count when the range is changed.

@romulogcerqueira
Copy link
Contributor

@doudou , I'm in vacations in this month, however I will try to keep tracking here as soon as possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants