This article summarises the announced optimisation of data transfer between the RController and the RMaster, as well as a new method for calculating each wheel position for better manoeuvrability. The problems visible in the last demo reel should be solved by these improvements, which will be visible in our next video.
Problems with the old steering
The steering implementation during the last test drive has been really simple: the front wheels were aligned parallelly in the steering direction, while the rear wheels did the opposite. This approach worked fine during the initial test – problems with quick steering manoeuvres arose quickly though. Tight cornering was not possible, without one of the front and one of the rear wheels grinding over the ground. That limited passable curves to wide arcs, which crippled the critically important manoeuvrability considerably.
Fortunately, there are several methods, which can be applied to fully circumvent this problem - most prominently upfront the Ackerman steering or Ackerman geometry (named after its inventor Rudolph Ackerman). This approach puts all wheels on imaginary circular paths, which correspond to the desired steering angles in relation to the distance from the centre of the rover.
Realisation of the Ackerman Geometry
The implementation of this alternative steering approach is somewhat more demanding, yet manageable due to the architecture of the rover’s software. The additional complexity is restricted to the regulation kernel, which computes understandable servo commands for RBreakout, which runs on the Arduino, using short trigonometric formulas. The following graph is an example for calculated steering angles. The depiction is not entirely realistic, due to further internal adjustments to the steering commands. The x axis depicts the global steering angle of the incoming command, while the y axis represents the steering angle of every servo after the conversion by the regulation kernel.
The adjusted regulation kernel has been transferred onto the ODroid, in order for it to directly connect to RMaster during the boot sequence. A change in the global steering angle now results in actual steering angles that position the wheels precisely on the desired circular paths. The difference to the previous system is easily recognisable in the following picture.
Due to the improved steering, VERNER is now able to take narrow bends at higher speeds than before and, more importantly, stay exactly on track. That in turn improved the predictability of the rover and makes for a better driving experience. The translation of joystick movement to steering commands feels natural and direct, which means that the driver is able to utilise more of the abilities of the chassis. The new capabilities of the enhanced calculations can be seen in the next demo video.
Improvement of Data Transfer
The communication between the controlling PC (the RController software running on said PC) and the rover (the RMaster program) takes place via WLAN in the current configuration. The network stack provides several possibilities for data transfer, TCP streams and UDP data fragments above all. Earlier in the project, a TCP stream was used for the entire communication with the rover, which had substantial advantages in comparison to the rather fickle UDP protocol. It was impossible, for instance, that commands arrived in the wrong order or were dropped entirely, which is a quite common occurrence when using UDP.
However, those advantages mean little in the time sensitive project of VERNER, because the transmission time is not short enough for steering commands. When a message is lost, for instance, the rover waits until the end of timeout, before requesting said message a second time. If this message was a steering command that is needed to avoid the collision with a major obstacle, the timeout becomes a massive, dangerous problem.
The solution was a hybrid approach: the controlling PC now decides which messages get transferred with which protocol. In case Reliable is chosen, the PC uses TCP. Yet, when a swift arrival of the orders is of essence (like for instance commands for motor speed and steering angle), UDP is used. Messages that are sent via UDP sport an expanded header that encodes a message- and a client number, which are used by RMaster to identify possibly delayed fragments and immediately drop them to focus on the more important more recent messages.
Thanks to the improved transmission technology, controlling the rover is now a swift and dropout free matter, which transforms the rover into a pretty reliable vehicle. High – speed manoeuvring is no problem anymore and even poor connections, like for instance WLAN with plenty of interference, is no insurmountable problem anymore. A demonstration will follow in the upcoming video.