Back in 2012 when I was a graduate student at the University of Toronto, I was evaluating the performance of a gait transition scheme for a quadruped robot. An artificial neural network created trajectories in real-time, responding to gait changes online, and the trajectories were forwarded to a simulation of the rover implemented via the Simscape Multibody™ toolbox in MATLAB®. Ideally I would have built a rover platform to validate the results, but it was not possible in the time frame and scope of my masters program. Fast forward to 2021, I’m still not resourced enough to build my own rover from scratch, but I now have access to Quanser’s Rotary Servo Base Unit, as well as our rapid control prototyping software QUARC™. The combination of the two allows me to quickly evaluate my gait transition scheme on hardware using the individual servos in the loop by sending real torque commands.
During a recent training session, my colleague and I leveraged QUARC in a similar fashion to deliver training customized to their need on a moments notice. Near the end of our training sessions, we had the staff driving a QBot 2e around by using two QUBE-Servo 2 units as the steering wheel and throttle pedals. QUARC’s ability to allow academics to focus on their experiment, without worrying about the interface to hardware, is what makes it a powerful tool for rapid research deployment and validation.
QUARC Isn’t Complicated but can be Quite Sophisticated
Simply put, QUARC does a lot of things. If I were to list them all, most would be appreciated by the advanced user. Personally, I like to categorize QUARC’s functionalities into three buckets.
Blocksets
The added blocksets/functions for MATLAB/Simulink makes application development using QUARC very convenient. Items such as the System Timebase block, which when added to a diagram, makes it simulate in real time. Or the To Host block, allowing you to record data locally on a machine running MATLAB/Simulink coming from external code running remotely on a totally different machine. Either right-click any QUARC block and hit the Help page for information, or check out the QUARC > Demos menu in Simulink for demos that show you how some of these blocks work together. Alternatively, type help quarc or qc_show_demos in the MATLAB Command window, respectively.
APIs
The second aspect includes 3 APIs – HIL (hardware in the loop), Stream and Media. Simply put, HIL allows you to talk to Quanser hardware, such as the QUBE-Servo 2, the QDrone, as well as a variety of popular third party DAQs and devices. As long as you are running your code on a target that has one of the devices listed in the HIL Initialize block, your code can perform a variety of I/O with that device. The Stream API allows different applications to talk to each other using most communication protocols, the Media API allows you to access video devices (2D cameras such as a webcam or 3D cameras like the RealSense line), and the Devices API allows you to access LIDARs (RPLidars, YDLidars, etc).
QUARC Target Manager
The third aspect is probably the most sophisticated of them all, the QUARC Target Manager. It allows the QUARC installation on any computing node on the same network to communicate with each other. When you build your Simulink model, the external code generated is downloaded, loaded and deployed on a remote target using QUARC Target Manager. It gives you consoles to monitor every step of this process, and even lets Simulink show you what that external code is doing straight up on the machine you are running MATLAB.
Checklist for Successfully Developing an Application with QUARC
My checklist for successfully developing an application with QUARC has two questions: (1) where is my application going to run? and (2) what is my application going to do? I’m going to answer these in the order that allowed us to architect the QBot 2e driving example I mentioned earlier in this blog.
Where is the application going to run?
The application consisted of two computing nodes, the first being the windows PC that was running MATLAB, and the second being the Raspberry PI 3 B+ as the computing brain of the QBot 2e. Both devices were connected to the same network. Our applications were setup to build external code for win64 and linux_pi_3, respectively, and the IP addresses of the two devices were setup accordingly. QUARC automatically builds code from the Simulink models for the corresponding type of target and downloads it there for you. You don’t have to worry about cross-compilation, or running the generated code manually. It’s done automatically when you hit a single button in Simulink.
What is the application going to do?
The application for the windows PC was to connect to two QUBE-Servo 2 units, one for the steering wheel, and the other for the throttle pedal. This required the HIL API’s HIL Read block to read the servo encoders as the user manipulated the position of the two discs. This application would then send this information to the QBot 2e application, which required the Stream API’s server block. The second application would receive this information and write the corresponding forward and angular velocity command to the QBot 2e’s motors, which required the Stream API’s client block, as well as the HIL API’s HIL Write block. In addition, the second application used the Media API’s Video3D Capture and Video Display blocks to show the user the first-person view from the QBot 2e’s Kinect camera, right on the screen of one of the monitors hooked up to the windows machine.
This being said, we had to develop the logic correctly of course, We knew the basic equations of a differential drive robot so as to implement the inverse differential kinematics correctly. We made sure all commands followed the expected positive convention. We followed the basic examples (QUARC > Demos in Simulink) to setup the APIs correctly. These steps aren’t difficult, they just require an immersion into documentation and examples, and an air of clarity at best. Within half an hour, our applications were deployed. Within another 10 minutes, we had the QBot 2e application checking to see if a server was connected at all, and if not, driving itself using an array of image processing blocks that QUARC offers, such as filtering, thresholding, connected-component-labelling, etc. (see below).
Closing Remarks
Along with this application, during our recent training session we had two arms being operated simultaneously using a joystick, and the QDrone/QBot 2e demonstrating a leader/follower mission, all deployed in a matter of days. One of the students told me, “QUARC is amazing… this was my thesis project… now we did it in 30 minutes…”. Always brings a smile to my face.
What project would you like to implement with QUARC? Comment below. See you next time.
