User interface: Difference between revisions

From Rsewiki
(120 intermediate revisions by the same user not shown)
Line 1: Line 1:


==Screen dumps==
Back to [[regbot | Regbot]] main page


The user interface can configure and run the robot, as well as inspecting almost all values on the robot. Written in python using Qt GUI library.
==Overview==
 
Connection is either using USB or network if the robot has wifi.
 
On Windows USB is com3, com4 or any higher, see the device-list in the control panel.
 
On Linux USB is /dev/ttyACM0 or /dev/ttyACM1 if /dev/ttyACM0 is used for other devices.
 
 
The user interface can configure and run the robot, as well as inspect almost all values on the robot. Written in python using Qt GUI library.


The interface looks like on figures below.
The interface looks like on figures below.


[[File:regbot_gui_robot.png | 800px]]
In general:
* Yellow fields are read-only (updates from the robot when connected).
* White fields are editable
* Editable fields require (in general) that an "edit" button be pressed first and a "save" button after the edit.
* Many check-boxes get implemented as they are checked/unchecked, but not all.
* Data is updated from the robot at a relatively low update rate; if data is to be used for documentation, then use the onboard log function.
 
 
[[File:Gui_robot.png | 800px]]


Figure 1. The general settings for the robot. The left panel is the general connection status and space for some messages from the robot. The central tab is mostly for configuration of the robot and some sensor and calculated values like pose and tilt. To the right is a fast graph of the last mission.
Figure 1. The general settings for the robot. The left panel is the general connection status and space for some messages from the robot. The central tab is primarily for the configuration of the robot and some sensors and calculated values like pose and tilt. To the right is a fast graph of the last mission.
NB! The data rate is low, so to get an overview, use the log function for more details.


[[File:Gui_rev0.png]]
=== Data logger ===


Figure 2. The data logging options. A number of sensor values and interface points in the robot software can be logged. The window text window shows loaded data from a mission. The log format is designed to be directly compatible with the 'load' function in MATLAB.
[[File:Gui_rev0.png | 800px]]


The GUI allows to make step responses for velocity and turn (and most of the other controllers). The step response is recorded in a buffer on the robot and is fetched in a MATLAB style file (as shown).
Figure 2. The data logging options. A number of sensor values and interface points in the robot software can be logged. The text window shows loaded data from a mission. The log format is designed to be directly compatible with the 'load' function in MATLAB.
Interface points that are recorded can be switched on and off to better utilize the limited buffer size on the robot (35kBytes).


[[File:Gui_ctrl_rev_1.png]]
====Log interval====


Figure 3. This is a page to make a step response and insert controller values for velocity control. The same controller is used for both wheels.
The sample interval is set in the mission and is visible here after a mission.


[[File:regbot_gui_show_menu.png]]
==== Log data ====


Figure 4. Other tab pages are available from the "show" menu.
Once the log is fetched, it can be saved to a file. The format is intended for MATLAB.


==Mission==
Use a script like this in MATLAB


Mission specification consist of mission lines, each line consist of two (lower case) parts divided by ':'  
clear
close all
%  1    time 0.9460 sec, from Ella (8)
%  2  3  4  5  (mission 0), state 9, entered (thread 1, line 3), events 0x0 (bit-flags)
%  6  7 Motor velocity ref left, right: 0.0000 0.0000
%  8  9 Motor voltage [V] left, right: 0.03 -0.03
% 10 11 Motor current left, right [A]: -0.010 0.011
% 12 13 Encoder left, right: -420 414
% 14 17 Wheel velocity [m/s] left, right: -0.0031 0.0030 delay 0.1000 0.1000 (sec)
% 18 19 20 21 Pose x,y,h,tilt [m,m,rad,rad]: 0.169143 -0.00276473 -0.0162272 -0.250711
% 22    Battery voltage [V]
%%
data = '''load('log_position-liv36_b.txt')''';
%% plot motor voltage and velocity
figure(100)
hold off
plot(data(:,1), data(:,8), 'linewidth', 2)
hold on
plot(data(:,1), data(:,14), ':', 'linewidth', 2)
grid on
legend('left voltage [V]', 'left vel [m s^{-1}]', 'location','northwest');
xlabel('Time [sec]')


drive values : continue conditions (conditions are OR'ed)
The top lines of the log file are copied into the MATLAB script to identify data columns.


e.g.:
==== Log options ====
 
Only tagged data items are logged (to save memory). See description below.
 
====ACC and gyro====
 
Acceleration logs the acceleration values in m/s^2 on all 3 axes (x (forward if in balance),y (left), z (up if in balance))
 
Gyro is rotation velocity around the same 3-axis. Unit is degrees per second (after calibration offset).
 
====Encoder====
 
Encoder values for wheel rotation (left, right) 48 values per rotation, increases on forward.
 
====Motor voltage====
 
Is the motor voltage - before conversion to PWM, compensated for changes in battery voltage.
 
====Motor current====
 
Filtered current sensor values. zero current is calibrated just before the start of a mission - this calibration sometimes makes a mistake, resulting in a wrong offset of the logged current. Value is in Amps. The value is filtered to match the log interval if the interval is > 2ms.
 
====Wheel velocity====
 
Based on the time between encoder tics. If more tics are within 1 ms, then the interval time is averaged. When there is a long time between tics (>50ms), then the time since the last tick is used to calculate velocity, i.e. velocity goes towards zero with time if no encoder pulses arrive.
 
==== Turn rate ====
 
The turn rate is based on encoder tics (not the gyro), the unit is radian/sec
 
==== Robot pose ====
 
The robot pose is position since the start of the mission (odometry coordinates), x,y,h,t where h is heading in radians (positive counterclockwise), and t is a tilt in radians (zero is in balance, positive is forward).
 
==== Line sensor ====
 
All values related to the line sensor, including AD value from each sensor.


vel=-0.2, acc=3.0 : dist=1, time=12
==== IR sensor ====


Drive backwards at a speed of 0.2m/s, accelerate with 3m/s2 for 1 meter (or max 12 seconds)  
Is distance converted to meters for each sensor (default is sensor 1 to the right and sensor 2 is forward).
==== Battery ====


=== Drive values ===
Battery voltage in Volts.


* VEL is velocity in m/s - positive is forward, 0=stop. uses last value if omitted.
==== Extra ====


* ACC is acceleration limit in m/s2. Uses last value if omitted.
Debug feature for log of extra values.


* TR is turnradius in metre - positive, 0 is turn on the spot. straight if omitted
==== Mission ====


* LOG is log interval in milliseconds. Once started it continues until buffer is full.
State, Thread, Line, Event. Where State is mission state (should always be 2 or 8 when stopping), thread number and line number in that thread, for the latest line activated (if more than one is activated in the same log interval, then the latest is logged. An event is a 32-bit integer where each bit corresponds to an event number, and events are accumulated over the logging period.


* BAL is balancing, uses last value if omitted.
==== Motor ref ====


* LABEL is a label number that can be used by GOTO.
Is the desired motor velocity (input to velocity controller) - in m/s


* GOTO is a jump to the label number given. This can be limited to COUNT use of goto, the count is then reset after the first skip. The goto can also be skipped if any other conditions are true when this line is reached. A line with a goto will never wait.
==== Stop logging when buffer is full ====


====Line-sensor====
If this is unchecked, then the log buffer is overwritten until the mission is stopped.
This is useful when a later part of the mission is more interesting.


If a line sensor is installed, then the following should work too:
==== Control time ====


* EDGER is following Right edge of line at -2..2 (in cm), positive is right
Is the time taken to handle sensor data, calculate control values and advance in mission lines. All should be finished within the sample time. Value is in microseconds, so it should be below 1000 to ensure valid control calculations.


* EDGEL is following Left edge of line at -2..2 (in cm), positive is right
==== Control details ====


* WHITE set to 1 if follow-line tape is white, else 0
Value order: r, m, m2, uf, r2, ep, up, ui, u1, u


====Distance sensor====
The control details give details at data points connected to or inside the general PID controller design used for all control settings. These control data points are illustrated in the figure below.


If IR distance sensors are installed, then these should work:
===Controller configuration===


* IRSENSOR is IR-sensor to use (1 is distance to a wall, and 2 is distance in front).
All controllers can be configured from the "control" tab. See the [[Control]] page for more control details.


* IRDist is IR-distance to hold.
[[File:Gui_control.png | 800px]]


====Threads====
Figure 4b. All control values are set from this page; click on the relevant controller and enter the relevant values in the dialogue window shown below.


A command sequence may be divided into threads. The default thread has number 1.
[[File:Gui_control_dialog.png | 500px]]


* THREAD=3 means that this and all following lines is handled by one thread (with number 3). All threads are activated at time 0.
Figure 5. This dialogue configures the wheel velocity controller - shown as a PI-Lead-controller with feed-forward and an output limit at (+/-) 9V. All other options are disabled. The blue frame boxes indicate a traditional PID controller with lead in forward (and)/or in the feedback branch.


Example
When "enable controller" is disabled, then the control is disabled.  
thread=2
    edgel=0.0, white=1, log=20.0: time=4.5
    : time=3.5
thread=8
    vel=0.4: time=1.0
    vel=0.2: time=1.0
    vel=0.0: time=1.0
    vel=0.3: time=1.0
thread=9
    bal=1: time=3.5
    bal=0   


Here the first thread controls drive method, first 3.5 seconds follow a line edge, then go straight for 3.5 seconds.
To use feed-forward only (i.e. set output directly from ref), enable controller, but set Kp=0, and enable feed-forward with some value for Kf (when Kf = 1, then ref is used directly as output).
The second thread (with number 8) controls the velocity over the first 4 seconds.
The last thread (with number 9) controls when to use balance.


The mission is finished when all threads has ended.
NB! As velocity measurements are rather noisy, the filter in the feedback path (Lead/Lag feedback) could be implemented as a low-pass filter with tau_zero = 0 and tau_pole = 0.005 (recommended).


Two threads may controls the same setting (the last one is in effect), however this should not be attempted with drive mode (i.e. follow edge or follow wall or turn, this can give unpredicted results).
=== IMU===


The thread number is pt. not used to determine the execution order of the threads (uses script order).
The IMU page displays IMU data. The balance controller uses the tilt measurement.


===Continue conditions===
[[File:Gui_IMU.png | 800px]]


':' is separation of parameters and continue condition.
Figure 5.1 IMU data. The graph shows calibrated values, and the gyro is calibrated by keeping the robot stable and pressing the "calibrate" button. (Remember to save the result in the robot flash.) The gyros drift slightly; repeat as needed.


* DIST is driven distance in this mission line - positive meters
The IMU board orientation needs to be configured so that its tilt is zero when balanced.
* TURN is angle turned in this mission line - degrees, positive is Left (CCW if forward speed)
For most robots, the tilt angle (about the Y-axis) should be slightly less than 180 degrees.
* TIME is max time in this mission line - positive seconds
* COUNT is used with GOTO and GOTO will be ignored, if this line is executed more than this count


The equal (=) sign can for some values (dist, turn, xb, xw and tilt) be replaced by '<' or '>', for most values (except xb and xw) an equal sign means equal or greater. NB! '>=', '==', '<=' and '!=' are not valid.
Hold the robot at the balance point, and see the tilt angle. This should be zero (or within +/- 1-2 degrees), if not adjust the y angle in the IMU board box (Edit, change, Apply and then "save to flash").


Example: Drive 0.2m then turn 30 deg to the right (turn radius=0, but will be more with acceleration being only 1m/s2) then drive another 1 second at a higher speed (or maximum 0.4m).
=== Menu ===


vel=0.2,acc=1 : dist=0.2
tr=0 : turn = -30
vel=0.5 : dist=0.4,time=1


Example Zig-zag sideways: drive 0.2m backwards and then turn 45 deg left, 45 deg right and a bit forward, repeated 2 times more with a goto (to label=6).


vel=-0.2, acc=2.0: dist=0.2
[[File:regbot_gui_show_menu.png | 600px]]
label=6:
tr=0.15: turn=45.0
tr=0.15: turn=-45.0
vel=0.2:dist=0.18
vel=-0.2,goto=6: count=2


==== Line sensor ====
Figure 6. Other tab pages are available from the "show" menu.


This section is valid if a line sensor is installed and calibrated. Use "Edge" tab for calibration (put edge sensor "ON" and on a dark background and press "Calibrate no reflection" and then on a bright background and press "Calibrate white reflection", then "save on robot").
Some of the available data tabs are for debug and maintenance.


* XB, XW is test for crossing black/white line, value is 0..20, 0 is true on no crossing, 1..20 is confidence in crossing (20 is highest)
===Mission===
* LV is test for valid line 0=true for no valid line, 1=true for valid line. NB! A wooden (or dirty) floor is likely to give a valid line at times.


Example: Drive until a crossing black line is found or 2.5m is driven, then continue until the crossing line is gone (reached other side of line) and stop
Missions are entered through the mission tab:


vel=0.2, log=5, acc=2: xb>16, dist=2.5
[[File:Gui_mission.png | 700px]]
:xb < 4,dist=0.2
vel=0:time=0.1


Example find white line and follow edge: Drive until (white) line is found - as before - then turn to the right and follow line for 0.5 m.
Figure 7. Missions are entered in the left (white) area, and can be syntax tested with the button above.
The result of the check is shown in the yellow area (right).
The mission of the robot can be fetched to the right area.
Missions (the left area) can be saved and loaded from text files with the buttons below.


vel=0.2, log=5, acc=2: xw>16, dist=2.5
If you copy-paste from another application, so make sure not to include any formatting; 7-bit ASCII characters are allowed only.
:xw < 4,dist=0.2
vel=0:time=0.3
tr=0,vel=0.2:turn=-90
edgel=0, white=1: dist=0.5


==== Distance sensor====
Missions are not saved to the robot before you press "save to robot".


IR1, IR2 is test for distance measured by IR sensor.
The mission is lost for the robot after a power cycle unless you save the configuration to robot flash - using the "save to robot flash" in the left pane.


@todo Distance sensor is not tested much, and is therefore assumed not to work properly.
==== Mission lines ====


==== Tilt balance angle ====
Mission specification consists of mission lines; each line consists of two (lower case) parts divided by ':'


TILT is test for tilt angle (0 is balance point)
drive parameter: continue condition


Example:
continue conditions are OR'ed.
@todo


===Examples===
e.g.:


Example drive-turn-drive-turn at 20cm/s:  
vel=-0.2, acc=3.0 : dist=1, time=12


vel=0.2, acc=1.5 : dist = 0.5, time=5
Drive backwards at a speed of 0.2m/s, and accelerate with 3m/s2 to this speed until a distance of 1 meter is driven or 12 seconds have passed.
tr=0.15 : turn=90
: dist = 0.5
tr=0.15 : turn=90
vel=0 : time=1


Example wait 5 seconds:
See [[Mission]] for more details.


vel=0 : time=5
=== Motor test ===


Example balance and follow line: Go on balance and follow left edge of white line for 0.5m, then follow line for another 0.5m without balance.
There is a motor test option.


vel=0.2,edgel=0,white=1,bal=1: dist>0.5
[[file: gui-motortest-2025.png | 700px]]
bal=0,edgel=0,white=1:dist=0.5


NB! Most examples - and especially balance - requires valid controller parameters and calibrated sensors (tilt offset for balance).
The test runs each motor in two steps and writes a log file during execution.


===Save ===
The log file is analysed to determine the time required for the motor current to increase before the motor velocity changes. This is used to estimate the time constant for the motor inductance. The peak current is used to estimate the motor driver and motor coil resistance.
Transfer the mission to the robot RAM by pressing "Save" (top right), the mission will be lost by a reboot or power off, unless saved on robot!


Save the mission on the robot flash memory (EE-prom) by pressing "save on Robot" (left panel). NB! The space is limited (about 100 lines)!
The motor constant and dynamic friction are estimated from the steady state values of velocity and current.


The mission can also be saved in a text-file using the bottom right save button
There may be cases where the estimate fails; in these cases, the motor resistance typically shows 200 Ω. Try again. Also, try to run a mission before the motortest. There must be some data-handling issues that are not adequately addressed; this issue is not fixed yet (Dec 2025).

Revision as of 19:57, 30 December 2025

Back to Regbot main page

Overview

Connection is either using USB or network if the robot has wifi.

On Windows USB is com3, com4 or any higher, see the device-list in the control panel.

On Linux USB is /dev/ttyACM0 or /dev/ttyACM1 if /dev/ttyACM0 is used for other devices.


The user interface can configure and run the robot, as well as inspect almost all values on the robot. Written in python using Qt GUI library.

The interface looks like on figures below.

In general:

  • Yellow fields are read-only (updates from the robot when connected).
  • White fields are editable
  • Editable fields require (in general) that an "edit" button be pressed first and a "save" button after the edit.
  • Many check-boxes get implemented as they are checked/unchecked, but not all.
  • Data is updated from the robot at a relatively low update rate; if data is to be used for documentation, then use the onboard log function.


Figure 1. The general settings for the robot. The left panel is the general connection status and space for some messages from the robot. The central tab is primarily for the configuration of the robot and some sensors and calculated values like pose and tilt. To the right is a fast graph of the last mission. NB! The data rate is low, so to get an overview, use the log function for more details.

Data logger

Figure 2. The data logging options. A number of sensor values and interface points in the robot software can be logged. The text window shows loaded data from a mission. The log format is designed to be directly compatible with the 'load' function in MATLAB.

Log interval

The sample interval is set in the mission and is visible here after a mission.

Log data

Once the log is fetched, it can be saved to a file. The format is intended for MATLAB.

Use a script like this in MATLAB 

clear
close all
%  1    time 0.9460 sec, from Ella (8)
%  2  3  4  5   (mission 0), state 9, entered (thread 1, line 3), events 0x0 (bit-flags)
%  6  7 Motor velocity ref left, right: 0.0000 0.0000
%  8  9 Motor voltage [V] left, right: 0.03 -0.03
% 10 11 Motor current left, right [A]: -0.010 0.011
% 12 13 Encoder left, right: -420 414
% 14 17 Wheel velocity [m/s] left, right: -0.0031 0.0030 delay 0.1000 0.1000 (sec)
% 18 19 20 21 Pose x,y,h,tilt [m,m,rad,rad]: 0.169143 -0.00276473 -0.0162272 -0.250711
% 22    Battery voltage [V]
%%
data = load('log_position-liv36_b.txt');
%% plot motor voltage and velocity
figure(100)
hold off
plot(data(:,1), data(:,8), 'linewidth', 2)
hold on
plot(data(:,1), data(:,14), ':', 'linewidth', 2)
grid on
legend('left voltage [V]', 'left vel [m s^{-1}]', 'location','northwest');
xlabel('Time [sec]')

The top lines of the log file are copied into the MATLAB script to identify data columns.

Log options

Only tagged data items are logged (to save memory). See description below.

ACC and gyro

Acceleration logs the acceleration values in m/s^2 on all 3 axes (x (forward if in balance),y (left), z (up if in balance))

Gyro is rotation velocity around the same 3-axis. Unit is degrees per second (after calibration offset).

Encoder

Encoder values for wheel rotation (left, right) 48 values per rotation, increases on forward.

Motor voltage

Is the motor voltage - before conversion to PWM, compensated for changes in battery voltage.

Motor current

Filtered current sensor values. zero current is calibrated just before the start of a mission - this calibration sometimes makes a mistake, resulting in a wrong offset of the logged current. Value is in Amps. The value is filtered to match the log interval if the interval is > 2ms.

Wheel velocity

Based on the time between encoder tics. If more tics are within 1 ms, then the interval time is averaged. When there is a long time between tics (>50ms), then the time since the last tick is used to calculate velocity, i.e. velocity goes towards zero with time if no encoder pulses arrive.

Turn rate

The turn rate is based on encoder tics (not the gyro), the unit is radian/sec

Robot pose

The robot pose is position since the start of the mission (odometry coordinates), x,y,h,t where h is heading in radians (positive counterclockwise), and t is a tilt in radians (zero is in balance, positive is forward).

Line sensor

All values related to the line sensor, including AD value from each sensor.

IR sensor

Is distance converted to meters for each sensor (default is sensor 1 to the right and sensor 2 is forward).

Battery

Battery voltage in Volts.

Extra

Debug feature for log of extra values.

Mission

State, Thread, Line, Event. Where State is mission state (should always be 2 or 8 when stopping), thread number and line number in that thread, for the latest line activated (if more than one is activated in the same log interval, then the latest is logged. An event is a 32-bit integer where each bit corresponds to an event number, and events are accumulated over the logging period.

Motor ref

Is the desired motor velocity (input to velocity controller) - in m/s

Stop logging when buffer is full

If this is unchecked, then the log buffer is overwritten until the mission is stopped. This is useful when a later part of the mission is more interesting.

Control time

Is the time taken to handle sensor data, calculate control values and advance in mission lines. All should be finished within the sample time. Value is in microseconds, so it should be below 1000 to ensure valid control calculations.

Control details

Value order: r, m, m2, uf, r2, ep, up, ui, u1, u

The control details give details at data points connected to or inside the general PID controller design used for all control settings. These control data points are illustrated in the figure below.

Controller configuration

All controllers can be configured from the "control" tab. See the Control page for more control details.

Figure 4b. All control values are set from this page; click on the relevant controller and enter the relevant values in the dialogue window shown below.

Figure 5. This dialogue configures the wheel velocity controller - shown as a PI-Lead-controller with feed-forward and an output limit at (+/-) 9V. All other options are disabled. The blue frame boxes indicate a traditional PID controller with lead in forward (and)/or in the feedback branch.

When "enable controller" is disabled, then the control is disabled.

To use feed-forward only (i.e. set output directly from ref), enable controller, but set Kp=0, and enable feed-forward with some value for Kf (when Kf = 1, then ref is used directly as output).

NB! As velocity measurements are rather noisy, the filter in the feedback path (Lead/Lag feedback) could be implemented as a low-pass filter with tau_zero = 0 and tau_pole = 0.005 (recommended).

IMU

The IMU page displays IMU data. The balance controller uses the tilt measurement.

Figure 5.1 IMU data. The graph shows calibrated values, and the gyro is calibrated by keeping the robot stable and pressing the "calibrate" button. (Remember to save the result in the robot flash.) The gyros drift slightly; repeat as needed.

The IMU board orientation needs to be configured so that its tilt is zero when balanced. For most robots, the tilt angle (about the Y-axis) should be slightly less than 180 degrees.

Hold the robot at the balance point, and see the tilt angle. This should be zero (or within +/- 1-2 degrees), if not adjust the y angle in the IMU board box (Edit, change, Apply and then "save to flash").

Menu

Figure 6. Other tab pages are available from the "show" menu.

Some of the available data tabs are for debug and maintenance.

Mission

Missions are entered through the mission tab:

Figure 7. Missions are entered in the left (white) area, and can be syntax tested with the button above. The result of the check is shown in the yellow area (right). The mission of the robot can be fetched to the right area. Missions (the left area) can be saved and loaded from text files with the buttons below.

If you copy-paste from another application, so make sure not to include any formatting; 7-bit ASCII characters are allowed only.

Missions are not saved to the robot before you press "save to robot".

The mission is lost for the robot after a power cycle unless you save the configuration to robot flash - using the "save to robot flash" in the left pane.

Mission lines

Mission specification consists of mission lines; each line consists of two (lower case) parts divided by ':' 

drive parameter: continue condition

continue conditions are OR'ed.

e.g.: 

vel=-0.2, acc=3.0 : dist=1, time=12

Drive backwards at a speed of 0.2m/s, and accelerate with 3m/s2 to this speed until a distance of 1 meter is driven or 12 seconds have passed.

See Mission for more details.

Motor test

There is a motor test option.

The test runs each motor in two steps and writes a log file during execution.

The log file is analysed to determine the time required for the motor current to increase before the motor velocity changes. This is used to estimate the time constant for the motor inductance. The peak current is used to estimate the motor driver and motor coil resistance.

The motor constant and dynamic friction are estimated from the steady state values of velocity and current.

There may be cases where the estimate fails; in these cases, the motor resistance typically shows 200 Ω. Try again. Also, try to run a mission before the motortest. There must be some data-handling issues that are not adequately addressed; this issue is not fixed yet (Dec 2025).

Retrieved from "https://rsewiki.electro.dtu.dk/index.php?title=User_interface&oldid=8462"