Category Archives: Bioloid project

Tweaking PIDs

Leave a reply

Following from my previous post on PID control, I have integrated my old test PID code into a more usable form in the GUI. I will quickly describe what the old test balancer did, and then the recent updates:

I started with the notes from this useful article as a baseline, but then built a very simple C++ class around it. I have also included some fairly standard modifications to the “vanilla” (ideal form) PID controller:

  • Calculating the derivative of the process variable, rather than of the error, to avoid large and sudden outputs in response to a large increase in error.
  • Prevention of integral windup by constraining the integral term and controller output between a minimum and maximum value.

I then started adding additional features built around the controller, which are:

  • Derived class which works on the standard form of the PID controller
  • Qt “widget” class, which displays a number of spin boxes and sliders for controlling the three gains and the output limits of the PID (as well as the min/max limits of the user controls)
  • A graph to trace the set point (SP) and process variable (PV) against time
  • A procedure which starts/stops the PID loop for balancing, in a separate thread (more on this below)

The aim is to control the forward/backward balance of the robot on a slanting surface. The balancing works by adjusting the ankle motors to match the pitch of the IMU link (see older posts here and here). For example, if the robot is on a board which lowered downwards by 5 degrees, the ankles will also point downwards by 5 degrees. The motor’s position is directly controlled by the IMU pitch, and the PID is actually controlling the moving speed with which the motors will reach that position. Unfortunately it’s not possible to do torque or direct speed control with the AX-12 motors.

With only some limited manual tuning, the initial results are fairly good for small and slow movements of a slopes surface, but it will need some tuning to stop the robot from oscillating at higher speeds and falling over. I will continue improving this method, possibly by using more PIDs to control the knee and hip motors at the same time. For now, here is an image of what it looks like running in the GUI:

Screenshot from 2016-07-20 23-37-37

Some useful links on the basics of PID control

Balancing ideas

Leave a reply

I had briefly tried in the past a simple balancing function using a PID controller, which aims to balance the Bioloid using the ankle motors, by trying to keep the IMU (accelerometer/gyro) vertical. The result was mixed success, but was only an early test. I am considering revisiting this balancing test, but this time using a number of PID controllers to control multiple groups of leg motors(e.g. hips, knees and ankles), while also using the GUI to make testing faster and easier.

 

On another note, I recently came across the Nengo Neural Simulator, which is a framework for creating neural networks of leaky integrate-and-fire (LIF) neurons for creating complex computational models. It has been used to create Spaun, the world’s largest functional brain model which is able to perform a number of functions such as vision, memory, counting, as well as drawing what is sees by controlling a simple arm.

What stands out is how easy it is to use the Nengo GUI to build neural networks. The interface runs in the browser and visualisations of neuron spiking activity and other metrics are easily shown for each graphical object. There is also support for scripting in Python. Installing it and trying it out for yourself is pretty simple, just follow the Getting Started guide here.

Nengo Interactive Plots.
Obstacle avoidance.

 

It would be really interesting to see if some form of PID controller could be built using Nengo, and then used to control the Bioloid’s balancing!

Qt Style Sheets and C++

Leave a reply

This is a quick post to show some more updates to the styling of the GUI.

I have been experimenting with customising the look-and-feel of my GUI using Qt Style Sheets (QSS) which are closely related to HTML Cascading Style Sheets (CSS).

Customised widgets

I have so far customised most of the widgets which appear in the GUI, as shown in the following examples. I have chosen a blue/grey theme throughout, with some exceptions for specialised widgets and items.

Code

Initially the style sheets were embedded in QStrings inside the code, but they were dotted around various classes which meant a lot of code was duplicated as I kept adding content. I then moved the style sheets (QSS) for each widget to a separate text file, and set them via each class individually. Finally I found a way of greatly simplifying this by putting all the code into one single file. This is applied through the program’s main window (QMainWindow). Exception widgets use custom QSS Selector ID, which is set with setObjectName(). This is a nice way of applying specialised styles to specific widgets, such as e.g. a button that needs to stand out.

Here are two QSS examples of the standard and special button shown earlier:

QPushButton {
    background-color: qlineargradient(x1: 0, y1: 0, x2: 0, y2: 1, stop: 0 lightsteelblue, stop: 1 steelblue);
    border-color: #8F8F91;
    border-style: outset;
    border-width: 4px;
    border-radius: 10px;
}
QPushButton:flat {
    border: none; /* no border for a flat push button */
}
QPushButton:default {
    border-color: royalblue; /* make the default button prominent */
}
QPushButton:pressed {
    background-color: qlineargradient(x1: 0, y1: 0, x2: 0, y2: 1, stop: 0 royalblue, stop: 1 dodgerblue);
    border-style: inset;
}

QPushButton#redPushButton {
    color: white;
    background-color: red;
    border: solid lightgrey;
    border-style: outset;
    border-width: 4px;
    border-radius: 4px;
}
QPushButton#redPushButton:flat {
    border: none;  /* no border for a flat push button */
}
QPushButton#redPushButton:default {
    border-color: grey;  /* make the default button prominent */
}
QPushButton#redPushButton:pressed {
    color: red;
    background-color: darkred;
    border: solid red;
    border-style: inset;
    border-width: 4px;
    border-radius: 4px;
}

As usual, the latest source code is available on GitHub if you want to have a look.

Motor dials updated

Leave a reply

I have made some updates to the motor dials which control the motor positions. They can now change mode and control motor speed and load. Also, the GUI is regularly updated with some important feedback from each motor: motor voltage and temperature, LED and torque on/off state, and feedback on all the alarm states.

The updated Motor Dials, controlling 18 AX-12 motors.
Close-up of single dial and feedback indicators.

At this point I’m starting to think that an internal model of all the motor control table data would be useful at this point! Rather than classes making direct requests to the motor controller to receive motor information, all the state data could be kept by the controller and updated regularly. Classes would then simply get the latest data from this model when needed. This is however partially the way the controller works already, as it has a model of the ROS-style joint states which hold present positions, present speeds and present torques (loads), as well as goal positions, moving speeds and torque limits. The joint states are published continuously by a ROS publisher. Present and goal positions are the most important data, as the AX-12 by default only performs position control. Moving speed is simply the speed that the motor will use to move between positions, so cannot be used for e.g. a velocity feedback loop. “Torque” is a bit of a misleading term here, as there is no torque sensing in the motors. Torque sensors are only available in much more expensive motors than these. The load values reported by the AX-12 are related to the motor current, but cannot be read while the motor is actually moving. Two notable sources which have more detailed information on this somewhat unclear measurement can be found here on the RoboSavvy forum and here.

 

I think I’m done with updating these graphical widgets for the time being, as it is detracting from the main goals of exploring MoveIt! and getting the robot walking.

Sensor grapher

1 Reply

A sensor plotting window has now been added to the GUI, which shows all data from the IMU and pressure sensors. The accelerometer, magnetometer, gyroscope, heading data and Force Sensing Resistors’ (FSRs) data are all published as ROS messages as shown in this post, so reading them in the Qt GUI is fairly straightforward, in a similar way to how the joint states are being read. The graphs are made using a third party library for Qt called QCustomPlot.

Each graphs show a scrolling 10 second window of buffered data, which can be paused/played. With QCustomPlot it’s easy to enable user interactions with graphs (drag axis ranges with mouse, zoom with mouse wheel, etc.), so I enabled this option whenever the graph is in a paused state.

The y-axis units are currently showing raw data, which I will probably update to show standard values.

Screenshot from 2016-04-03 19-46-07.png

A useful thing I found in Qt with QDockWidget, which is used to create dockable/floating sub-windows, is that these widgets can also be tabbed to save space on the screen. How can this be done in code you may ask? The useful functions I found were: setDockNestingEnabled() (or setDockOptions()), tabifyDockWidget() for QMainWindow, and raise() to select the default tabbed dock widget you want displayed.

That’s pretty much all there is to the sensor grapher. I might add more features to it in the future, but for now it does the basics!

List of ideas

Leave a reply

As I have many ideas floating about on what to work on next, I made a list to see try and see which ones are worth prioritising:

  • GUI updates
    • Graph for visualising sensor data
    • Improved motion editing
  • Static balancing
  • Implement MoveIt! trajectory following via GUI
  • Walking routines
  • Advanced movement: Trajectories generate from MoveIt!, combined with active balancing as the robot moves

This is just an initial list, which I hope to expand on in the future.

My immediate plans right now are to continue tidying up some GUI graphical details, implement a simple sensor data plotter (I know rqt_plot does a fairly good job of this already, but I’d like to have sensor data integrated in my GUI) and get back to trajectory generation tests using MoveIt!

More software updates

Leave a reply

With the new PC’s development tools up and running, I’ve made a number of updates to the GUI side of things, as well as the background joint controller node. Here are some of the most important from this month.

Joint controller updates

An issue I was having with the joint controller node – a main function of which is to act as a ROS wrapper class around the Dynamixel API – was that I seemed to be getting erroneous values when executing a simple one-off read from the motors. I suspected this was related to the fact that the node is also constantly reading the motors’ feedback values as fast as possible in its main loop. Even though the Dynamixel library seems to have checks for a busy comms bus, there was likely some issue with multiple threads trying to access the bus. This was easily fixed by using ros::spinOnce() in the main loop instead of using an AsyncSpinner which starts up a separate thread.

There is still some problem where positional values for some of the motors seem to be getting constantly corrupted, but only when all the torques are enabled and the motors are struggling to achieve all their goals positions (making the typical whining noise that servos have). I’ve yet to narrow down if this is a software issue or not.

Update to read/write services

The ROS read/write services have been simplified now, and two of the most useful commands are the ones that perform a sync read and write across a number of motors. As these are ROS services they can also be called from a terminal command line. For example, to receive the current position, current speed and current torque of motors 1, 3 and 5 all at once, you can run:

rosservice call /ReceiveSyncFromAX '[1, 3, 5]' 36 3

36 is the start address for the low byte of the present position, and 3 indicates the number of control table values, including the start address, to read for each motor. This is calling the sync_read function that the USB2AX offers, via a ROS service.

In a similar way you can write goal position (100), goal speed (300) and max torque (512) to motors 1, 3 and 5 all at once by running:

rosservice call /SendSyncToAX '[1, 3, 5]' 30 '[100, 300, 512, 100, 300, 512, 100, 300, 512]'

One restriction is that the sync read and write functions can only read/write consecutive control table addresses, as explained in the USB2AX link above, as well as here in the Robotis documentation.

New motor control table value editor

On the GUI side of things, I’ve made a new “motor address editor” as an improvement on the previous “motor value editor”. The new editor allows reading/writing of all control table addresses of the AX-12. You don’t have to worry about writing low/high bytes to the two-byte values, as that is handled by the editor; simply write any valid value to the parameter of interest.

I have kept the old editor as two useful features it has is let me easily write the same value to all motors, as well as send position/speed/torque in “standard” units (rad, rad/s and torque %) instead of raw values.

Old “motor value editor”
New “motor address editor”

Recording and executing poses

I added a new test function which moves the robot through a sequence of queued poses that are saved in the GUI. The robot pauses between each sequence based on each pose’s specified delay time.

Because the function’s execution has to pause and wait for the specified dwell time time, I added the code into a separate thread. Originally I did this by subclassing QThread, but then updated it and created a “worker object” which is moved to a thread using moveToThread(), as this seems to be the better way in Qt.

Although this is very simplistic motion editor functionality which has been done many times before by other tools, I thought it would be useful to add to my GUI, as it could prove useful in the future as a complement or even a replacement of the MoveIt! ideas if they don’t work out. This GUI is now essentially a one-stop shop for easily testing various ROS functionality and other ideas as I keep on developing along the way!

New development PC

Leave a reply

Progress has been slow as my laptop is having overheating problems, so running ROS for any extended periods was getting difficult. For this reason I have almost finished setting up a Linux development environment on my main PC which is more than capable of running ROS and all the graphical tools. I will keep using the laptop for less intensive tasks and for development away from home.

I am using Linux Mint 17.3 Rosa 64-bit on the PC vs Linux Mint 17 Qiana 32-bit on the laptop (laptop had Wi-Fi driver issues with 64-bit version), but still sticking with ROS Indigo instead of upgrading to the more recent Jade, to avoid any surprises.

Installation of ROS was straightforward as with the laptop, and follows the Ubuntu installation instructions, as Mint is built on Ubuntu. The only edit I had to make was change the repository name to use the Ubuntu Trusty codename instead of the Mint Qiana codename, so the repository name looks like this:

deb http://packages.ros.org/ros/ubuntu trusty main

I use Dropbox to keep everything in sync and share the same catkin workspace between the two machines. The only minor annoyance is having to delete the build and devel folders and rebuilding my packages when switching between machines, because of the 32-bit/64-bit difference.

Fitting the foot force sensors

1 Reply

I finally got round to installing the force sensing resistors to the underside of the Bioloid’s feet. I am using the FSR 400 Short model, with male end connectors, which are small and flat and didn’t fit in the square female header pins which often come at the end of breadboard wires. I didn’t want to solder directly as I’ve damaged these sensors in the past, so I followed a suggestion on the Adafruit website and ended up using these PCB terminal blocks.

The force sensing element of the FSR fits nicely in the pre-existing cut-out on the underside of the Bioloid foot plate, and the pins are fed through a hole in the plate so they can be connected on the topside. However, in the standard Bioloid humanoid configuration, the foot plates are attached at an offset from the ankle angle brackets, which means there is not enough space between the footplate and the bracket to connect the pins. To fix this, I moved the footplates so that the ankle brackets sit along their centres. There is still some free space between the footplates when the Bioloid sits in its resting position, so hopefully the feet will not collide with each other after this change.

For completeness, I also made changes to the CAD model and also added FSR CAD models to the feet, although that is just a cosmetic addition to the model (on a related side-note, I also found a CAD model of the USB2AX which adds to the realism)! The robot’s URDF files and CAD models have been updated on GitHub.

Here are some pictures of the results:

Standard foot separation.
Symmetric foot separation.
CAD models of FSRs.
FSRs held on temporarily with sticky tape.
Close up.
Another close up.
PCB terminal blocks connecting the FSRs.
Wiring mess.
More wiring mess!
Zip ties used to tidy up the wiring as much as possible.
Another view of the foot.
And another view of the foot.
Everything but the battery wired up.
Front view.

Further integration with MoveIt!

Leave a reply

The integration of the Bioloid with MoveIt! has reached an important milestone, with the real robot now being able to respond to MoveIt! planned trajectories! There’s still a lot to do to improve performance, but the basic framework is ready. In the next few paragraphs I will try to describe the MoveIt! configuration process up to now.

In a previous post I mentioned how the SRDF file was created as the fist step to configuring the robot to use MoveIt! The joint_state_publisher was already set up to publish the values of the joint states, which it read from my AX-12+ motor controller, so RViz was able to display the current state of the robot’s joints live when connected to the robot. Commands could also be sent to move the robot servo’s (such as those sent by the control GUI), but this was done using my own custom ROS services. The link to closing the loop between MoveIt! and the robot was to make MoveIt! able to command motor movement.

The joint controllers

Some background reading quickly led to the tutorial page on controller configuration. In trying to figure out how to first make my AX-12+motor controller provide the required FollowJointTrajectory action, I first looked at the wiki of the actionlib stack and used a C++ SimpleActionServer. However this would mean having to then implement the trajectory following, something which is already by the ROS joint_trajectory_controller package. So instead I looked into how I could get the robot to use this controller, which to lead to reading about ros_control and a very good tutorial from Gazebo. It took some time to understand how all these packages work together, and finally found that I had to implement the hardware_interface for my AX-12+ motor controller. The biggest challenge was figuring out how to configure the controller YAML files and actually get the controller_manager to spawn the controllers correctly.

I have used various roslaunch files and configuration files that set up and run the joint controllers, which I will upload shortly onto my GitHub page, along with updates to the C++ ROS AX-12+ motor controller.

The connections between the various ROS nodes and topics have now grown quite a bit in complexity, compared to the initial ROS interconnections, and now look something like this (captured using rqt_graph):

rqt_graph_control_moveit_and_gui_2015-11-03

Useful links

I have put together a list of links, mostly from the ROS answers site, which were very helpful in getting the controllers to finally work:

Control GUI updates

Leave a reply

Progress is going well with my Qt control GUI. The main updates are:

  • New button to cut torque on all motors.
  • New motor value editor, used for writing to the servo control table addresses. The address of choice can be selected, and a value can be set to an individual servo or to all servos at once, using the broadcast ID (254). Also included are three custom functions which write position/speed or torque using more intuitive values: radians, rad/sec or % torque respectively.
  • New position dials for directly controlling the position of each motor.
  • In order to control and receive feedback from the motors, all these GUI functions interface with the ROS publish/subscribe mechanism or ROS services, which my custom usb2ax_controller ROS package is providing in its own separate ROS node.
  • I have been playing around with Qt style sheets to customise the GUI’s main elements such as background, buttons etc.. This was fairly time consuming but overall I think it improves the overall look and feel rather than just having standard grey boxes! I have also used QDockWidget to make various parts of the GUI easy to hide/show, pop out or dock and resize. This seems much more flexible than putting all widgets on one form, or using multiple standard windows or even tabbed windows.
Disconnected
Connected
Motor value editor
Motor position dials

Now the foundations are laid, it’s time to delve deeper into MoveIt!

Robot control GUI first steps

Leave a reply

I have switched focus to software at the moment, and am writing a basic user interface that will let me interact with the servo controller and the ROS packages, specifically the MoveIt! Move Group Interface/C++ API.

The interface is written in Qt using the Qt Creator IDE. As this is very ROS focused, I am building the GUI as a ROS package using catkin_make, which was tricky to set up inside Qt Creator, but worked in the end!

Screenshot from 2015-09-22 23-45-47

Currently the GUI can start a ROS node and receive current and goal position/velocity for each servo. It also enables the creation of a list of joint poses from the current robot’s state, and the ability to add them to a second list, which will act as a queue for moving through sequences of poses later on. The lists can be manipulated and also saved/loaded to CSV text files. A group of slider widgets shows the robot’s current joint positions, with added markers to show ‘target’ positions.

A number of buttons are yet not implemented, but the idea is to make this a quick and easy interface to a number of motion plans using the MoveIt! API, as I found it cumbersome trying to test with just a simple test C++ file. Hopefully this is the first step to a GUI with many features to come!

All source code is available on GitHub if you want to have a look.

Backpack printed

Leave a reply

The backpack print from Shapeways has arrived!

Overall I am very pleased with the quality of the print. The walls are only 1.22 mm thick which makes the design somewhat delicate with the standard plastic material, so if I had to print it again I would thicken them. The dimensions perfectly match the screws, battery and back of robot chest, so the backpack fits in without any problems. I should have also added a few more holes around the sides, as the wiring is fairly cramped. The battery cabling is fairly awkward, maybe I should have gone with an even smaller one than originally planned!

Along with the battery, the backpack also houses the SMPS2Dynamixel servo power adaptor and a bunch of wiring. The power adaptor has a tricky shape with servo connectors at a right angle to the DC jack, but I was able to use a smaller plug with its plastic casing removed in order to fit it inside the limited space.

Hopefully the battery is close enough to the centre of mass, and not too high, so it remains to be seen if the servos are powerful enough to keep the robot standing and moving upright. Now it is back to software, to get the robot to finally do some interesting moves!

New Bioloid backpack

Leave a reply

Adding to the endless stream of distractions from the main programming, I decided that the current mess of wiring and components on the back of the Bioloid needed tidying up properly. So, I have made a 3D model for a backpack, and I’m waiting for it to be 3D printed at Shapeways. The dimensions are similar to those of the original case which held the CM-5. The two large holes on the sides are for slotting in the new 2200 mAh battery, as it was too big to fit within the backpack.

Robot VR model updates

Leave a reply

The robot model has got a small update to make it better resemble its real counterpart rather than the default Bioloid humanoid.

I have also had some success testing the Move Group Interface/C++ API with the robot, as well as managed to start a Qt widgets project using ROS’s CMake build system. This is in its very early stages right now, but will form the basis for further tests and advanced motions with the MoveIt! package.

Playing around with Gazebo

Leave a reply

I thought it would be interesting to see if I could get my current Bioloid URDF file into Gazebo and try out some simulations. It turned out not to be too difficult; in order to load the model in Gazebo, all I had to add to the URDF were inertial elements for each of the links.

I set up a couple of tables and beer cans in the scene, and dropped the poor Bioloid from a height!

If you already have a URDF description of your robot, Gazebo is fairly easy to set up and has great potential for any simulation-based project, however as I am focusing more on the physical robot, I probably won’t be using it much for the time being. That, plus the fact that my laptop can barely handle the program without overheating!

Git repo created

Leave a reply

I have just set up a GitHub account and added the ROS setup code I am currently working on. You can find it all at https://github.com/dxydas/ros-bioloid.

As I am a Git noob, here are some useful links which helped me along the way, and which may be of us to others:

Heads up!

Leave a reply

The Raspberry Pi has now been fitted to the Bioloid using some spare brackets and sponge padding.

A GUI for the Pi’s screen has also been made using Python, Tkinter and the rospy library. This is actually my first Python program from scratch, so it’s far from perfect but it’s simple and does the job for now!

The program visualises the sensor data from the force sensors and IMU, which the Arduino is publishing on ROS topics. The slider values are unfiltered data, the same which is used by another ROS node to fuse the IMU data and provide a good estimate of the torso’s 3D orientation. The roll/pitch/yaw widgets are used to visualise a simple transformation of the accelerometer/magnetometer data, as was performed previously here. The force sensing resistor (FSR) widget is not active, as the resistors have not been wired in yet, but eventually each FSR’s value will be visualised with a coloured square box ranging from yellow (un-pressed) to red (fully pressed).

Custom Conky on the Raspberry Pi 2

6 Replies

I thought I’d share my Conky configuration currently running on my Pi for anyone interested, as it’s a great tool for displaying useful system information on the desktop. It’s designed for a 480×320 resolution screen, as it is running on this touchscreen, and it takes up all the available space on the Raspbian desktop, minus the menu bar (26 pixels high).

One problem that took me quite a while to solve was how to actually get Conky to launch at startup, as none of the usual methods seemed to work. In the end I found two ways of calling a startup script. First, create a simple Bash script, like this:

#!/bin/bash
sleep 10 && conky -c ~/Scripts/.conkyrc_raspberry-pi-2 -d

Save it e.g. as ~/Scripts/startConky.sh. Then, make the script execute at startup in one of the following two ways:

  1. Open the file /etc/xdg/lxsession/LXDE-pi/autostart as sudo, and add the following line to the end (solution found here): 
    @~/Scripts/startConky.sh
  2. Alternatively, create a file ~/.config/autostart/startConky.desktop, which contains the following lines (as explained here): 
    [Desktop Entry]
Name=conky
Type=application
Exec=/home/pi/Scripts/startConky.sh

Here are some screenshots of Conky in action. Feel free to use my config however you want!

My Conky config:


# Conky config file

# Avoid flicker
double_buffer yes

# Window
# Own window to run simultaneous 2 or more conkys
own_window yes
own_window_type normal
own_window_hints undecorated, below, sticky, skip_taskbar, skip_pager
#own_window_transparent yes

# Borders
draw_borders no

# Shades
draw_shades yes

# Position
gap_x 0
gap_y 34
alignment top_middle

# Behaviour
update_interval 2

# Font
#font arial
use_xft yes
#xftfont arial:size=8
xftfont Bitstream Vera Sans Mono:size=8
#xftfont Terminus:size=8
xftalpha 1 # Text alpha when using Xft

# Colours
#default_color d1d3c9
#default_shade_color 000000
own_window_colour 2B2B2B

# Prevent window from moving
use_spacer none

# Minimum size of window
minimum_size 464 280

# Maximum width of window
maximum_width 464


TEXT
${font Arial:size=12}${color #ddaa00}${time %I:%M %p}${font}            $alignc${color #9fb6cd}UpTime: ${color }$uptime $alignr${color #9fb6cd}Temp.: ${color ff0000}${execi 2 vcgencmd measure_temp | sed 's/[^0-9.]*//g'} °C
${color }${hr}
${color #9fb6cd}CPUs${color }
${color #9fb6cd}1: ${color }${cpugauge cpu1 30, 60}  ${cpugraph cpu1, 30, 125 ffff00 ff0000 -t} $alignr${color #9fb6cd}2: ${color }${cpugauge cpu2 30, 60}  ${cpugraph cpu2, 30, 125 ffff00 ff0000 -t}
${color #9fb6cd}3: ${color }${cpugauge cpu3 30, 60}  ${cpugraph cpu3, 30, 125 ffff00 ff0000 -t} $alignr${color #9fb6cd}4: ${color }${cpugauge cpu4 30, 60}  ${cpugraph cpu4, 30, 125 ffff00 ff0000 -t}
${color }${hr}
${color #9fb6cd}MEM
${color }${memgauge 30, 60}  $alignr${memgraph 30, 380 0000ff ffff00 -t}
${color }${hr}
${color #9fb6cd}UP $alignc${color #9fb6cd}IP: ${color }${addr wlan0} $alignr${color #9fb6cd}DOWN
${color }${upspeedgraph wlan0 30, 220 0000ff ff0000 -t} $alignr${downspeedgraph wlan0 30, 220 0000ff 00ff00 -t}