Rzborda, or How to Make an Internet-Controlled Typewriter
Over the past few years I have had the opportunity to make quite a few remote-controlled devices. Some were managed locally, from a regular PC or from a smartphone. Some are via the Internet. All devices are united by a common principle - a person controls them, guided by the picture from the video camera on board the device. And the management itself, as a result, comes down to issuing control signals to servos or motor controller (driver).
So, having gained experience in this case, I decided to try to more or less systematize various types of device management, so that when creating a new device, I did not have to rewrite a lot of things, and it was enough just to change some configuration parameters. As a result, the RCboard, or RCbord software package was born. Since I do all the controlled things with the controller Virt2real ( Virturilka ) as the main onboard brain, then the rebord was originally written just for her. So the whole bundle can be pathetically called "Software and hardware complex of the Retzbord".
In general, in the continuation of the topic, I will try to write a recipe about how to make a machine controlled via the Internet using Virtual Virtual Radio and RT-Board from a conventional radio-controlled machine (well, locally it will also be controlled). The communication channel will be the usual Wi-Fi (access to the Internet through a home router) or 4G connection through the Yota whistle.
')
Crawler BSD Racing 4WD RTR 2.4Ghz 1:10
I’ll just clarify - by the term “radio-controlled machine” I mean not cheap Chinese cars, in which all the electronics are implemented on one board, but more or less decent cars built according to a modular scheme - which have an engine speed control (collector, brushless) - and Servo to control the rotation of the front wheels.
I will give such a machine as a guinea pig only in this recipe, as it is easiest to repeat. With slight changes in the settings of the rebridgeboard and the addition of the engine speed regulator, the same can be done with any typewriter, the main thing is that the typewriter had wheels (yes even tracks) and had a motor.
But first, to demonstrate some use cases.
As I already wrote, we have already used a rebordboard in many places, but from the documented cases I found only these:
habrahabr.ru/company/virt2real/blog/223145
habrahabr.ru/company/virt2real/blog/223183
By the way, the snow blower itself is the development of the Perm guys http://omiplow.ru
Joint project with an open research center of promising technologies
The crawler for remote control is good because it has a very high maneuverability.
The crawler has four-wheel drive, permanent locking differentials (all wheels spin at the same time) and a constant "downshift." Those. He drives relatively slowly, but powerfully and passable.
Before you assemble the machine, you need to configure Virtuylka. First, consider the option to connect via Wi-Fi.
So, the points:
Usually, RC cars have two motors. One ordinary, collector - turns the wheels. The second - the servomotor turns the front wheels in the right direction. Those. it turns out that only two control channels are required - gas and a steering wheel. Initially (if the machine is purchased in assembled form) all channels are connected to a regular radio receiver with three-pin JR type connectors (standard servo connector). Black (or brown) wire - ground, red - power (5-6V), yellow (or white, or orange) - signal wire.
It is through the signal wire that we will control the motors, but first we need to power the servo, which drives the wheels. Here the general principle is - from the onboard battery the power supply with the voltage equal to the battery voltage goes through the thick wires to the powerful regulator of the collector (or brushless) motor. Inside this regulator there is a so-called BEC - voltage converter, making stable 5 volts (sometimes 6V, with a jumper on the regulator) required for powering the onboard servos, receiver and various other electronics from various battery voltages. This stabilized power supply is usually designed for a load of no more than 2-3A, although this also depends on the model of the regulator.
The BEC output voltage through the black and red wires of a thin three-core cable from the regulator is fed to the receiver. Here lies the main nuance, which not all immediately comprehend. I repeat - there is a cable with three conductors from the regulator. Of these, two cores are power supplied from the regulator, i.e. this is the way out. And the third wire (white, yellow or orange) is the control wire, i.e. entrance. It seems a trifle, but for some reason, many are confused.
The receiver has several groups of three-pin contacts. Their number depends on the number of channels for which the receiver is designed. The machines usually have 2 or 3 channels, so the groups are 3 or 4, respectively (one group to set the Pair jumper (signal for pairing receiver and transmitter). For these contact groups, all the power pins are closed between each other, i.e., ground and power comes from the regulator and is sent to all contact groups at once, but the signal pins are all independent, they receive a signal received by the receiver from the radio control equipment.
Since we will manage with the help of an independent controller, we don’t need a typewriter receiver, we remove it altogether. And the three-core cables from the regulator and from the servos we need to connect in a sly way - connect the black wire with the black, red with the red. And the remaining white (yellow or orange) two wiring must be connected to Virturilka, namely to the pin CON44 and CON43, see the diagram . What kind of wire to which pin does not really matter, since the channels can be configured later in the config file.
It should look like this connection
If there are servos at hand, it is convenient to make a connection with them. I have with them eternal tension, so I just cut off the wiring and twist-solder.
And yes, the most important thing is that we supply power to the Virturku directly from the battery contacts. She is not afraid of voltage up to 20V, so the higher the voltage, the better, the less current will consume. The efficiency of the power converter (SEPIC, installed on Virturilka itself) drops only after 15V, so the ideal power supply is from 12 to 15 V, while at full load (with Wifi), the Virtirlka will consume about 150-300 mA. Although it also depends on the whistle (Yota whistle is very gluttonous, it will be more with it).
I tried to capture the video of the assembly process of my crawler. I do not know how everything is clear there, but I think it will not be superfluous. Here's a video about the assembly:
All settings of the pcbord can be edited in a special control panel of the pcbord (not to be confused with the admin virtualka). This is how the control panel of the redboard looks now (the first version)
In the “General Settings” tab, you can set the device name (displayed when a device is detected in applications), specify whether to launch the rebordboard server automatically when the Virtualrika loads, set the type of configuration.
The configuration can be local (i.e., the configuration file resides in the directory of the redboards and is available for editing in the control panel), or it can be deleted when the configuration file is downloaded each time the launch of the redboards from the web server.
Server of remote configs, by default, http://rc.virt2real.ru/getconfig , create and edit configurations there are allowed only registered users of the forum.virt2real.ru
In the topic, I will tell only about the local configuration, you can try the remote configuration yourself if anyone is interested. By the way, when I rode on Shenzhen (the video at the end of the topic), I used the remote config so that I could change the settings. Changing the settings from the application is still in the form of sketches, it really does not work yet, but even when I finish it, the remote config is still useful.
So, we are most interested in the “Local Configuration” tab. In general, the default config already configures the RCBD to server mode, you can connect the machine and manage it locally (in the local network, from a Windows application, from an Android or from an iPhone / iPad). Is that you may need to swap channels. But for the P2P mode (peer-to-peer), to control via the Internet, the settings will have to be changed.
By default, the universal.so library is responsible for all management, for which the parameters are located at the end of the config, in the "[universal]" section.
The correspondence of control channels and PWM / PPM channels is specified by the axis parameter.
By default, 4 PPM channels are set up, which are on the pins CON43, CON44, CON19, CON42. These lines of config are responsible for this.
The channel setting format is:
chX = CON, TYPE, MIN, CENTER, MAX, NEUTRAL, NOAUTOCENTER
Where
X is the PWM / PPM channel number, from 0 to 3
CON - pin number (not GPIO, namely pin, see diagram )
TYPE - signal type, ppm or pwm. For the machine, you need ppm, for the pwm type, a different config string format.
MIN is the minimum position of the PPM signal, in milliseconds.
MAX - the maximum position of the PPM signal, in milliseconds.
CENTER is the center position of the PPM signal, in milliseconds.
NEUTRAL is the relative value of the neutral, i.e. neutral value of control commands. Normally = 127
NOAUTOCENTER - if = 0 - automatically return the signal to the center position, = 1 - do not return. For gas channels and a rudder, you need to specify 0, for servo channels, which are used to rotate the camera, you need to specify 1 (if there are any, of course)
If there are lights on the machine, you can turn them on and off, you will need to assemble a simple transistor amplifier (one field effect transistor, in fact). To get the control signal, use the “pins” parameter. It sets the pins that will be set to 0 or 1 when the button is pressed in Virt2real Player (on the on-screen buttons, on the keyboard, mouse, or on the gamepad).
The format is:
pins = CHANNEL, CON, DEFVALUE, SAVESTATE | ...
Where
CHANNEL - button channel (from 1 to 32)
CON - pin number to be set to 0 or 1 after the arrival of the control command from the buttons
DEFVALUE - the value in which this pin will be set when launching rebats
SAVESTATE - if = 0 - when pressing the button, set the pin to 1, when released - set to 0. If = 1 - when pressing the button, set the pin to 1, when releasing the button, do nothing. The next time you press the pin button to set to 0, when released - again do nothing. And so in the cycle.
Channels of buttons can be specified in a row, through the separator "|".
A brief conclusion from this vague information - if you have the gas and rudder channels confused - you can swap them by changing the axis parameter to axis = 1,0,2,3 :-)
If you need to limit the extreme position of the steering serva, change the MIN and MAX values ​​for the desired channel. If the machine goes forward or backward in neutral position - change the CENTER value for the desired channel.
In the “Additional modules” tab there is a list of active and inactive modules.
A module is a separate application (executable binary) that usually acts as a telemetry source. Active modules are those that are started automatically at the start of the redboard and terminate at the completion of its operation. In the control panel, you can move modules from one column to another by clicking on the orange arrow. When moving to the active column, the module starts up immediately, no matter if the rebord is running or not. When moving to inactive - the module automatically stops working.
The modules work simply - they read the required parameters and send via UDP to the local port (ext_telemetry) specified in the config. And there already rtsborda takes info and transmits via telemetry to the application Virt2real Player. At the same time, the same information is transferred to the user's device library (in our case, it is universal.so), so that the application can analyze the information and use it for its intended purpose. For example, I had a library of a device called autobot.so, a controlled trolley that, in addition to user management, could also autonomously drive, guided by a signal from an ultrasonic rangefinder.
From the main modules - statuswifi delivers information on the status of the Wi-Fi link to the radioboard. Airosstatus.php (yes, the module can also be written on pohapa) - reads the link status from the Ubiquity equipment, gps - reads the GPS receiver. The imu module processes the information from inertial sensors (Euler angles, azimuth and compass), although it still works with only one type of sensor, so it is not suitable for universal use. Nfc - reads NFC tags, but also works with only one type of reader. rc.in - reads PPM signals from an RC receiver, i.e. You can also control the machine with a normal app, it has priority over control commands via Wi-Fi. rfid - read RFID tags. statusyota - reads the status of the 4G modem Yota link. usrange - reads ultrasound rangefinder readings. voltage - determines the voltage of the onboard power supply, a simple voltage divider (2 resistors) is required to be connected to the ADC0. In general, there are a lot of interesting modules, for each there is a detailed description to be done, so for now we believe that I mentioned them for seed :-)
For our managed machine recipe, the statuswifi module is relevant - if we are setting up a connection via Wi-Fi or statusyota - if we connect the Virturika through the Yota whistle.
In Android and ipad-iphone applications, the settings are simple, only in the choice of control channels. In Android, there is also a channel button selection (by default, the channel is not set, the buttons are not displayed). But in the Windows application, I have wound so many features that I myself come to a state of light panic with the knowledge that all this must be documented. While I can only give a reference to the description of the previous version of the application
http://wiki.virt2real.ru/wiki/How_to do_controlled_trolley_2
http://wiki.virt2real.ru/wiki/RCboard
The control protocol has since changed noticeably, but the configuration of the Windows application has changed slightly, so it can help with picking. I will try to write a detailed description of the current version next year :-)
By the way, in the earliest version, I used the MAVLINK protocol to transmit telemetry, but as I got fouled with features, it was not enough, so I switched to my own protocol. I am thinking of adding MAVLINK as a parallel telemetry channel, but this is already in the next version of the application.
I can only say one thing - it is best to control the machine with a USB steering wheel and pedals connected to the computer. Well, or at least with RC appy, connected by a coaching connector to a computer. A finger across the screen of a smartphone can be cool, but it's not convenient without tactile sensations.
Since both the control channel and the video channel use UDP, I wanted to make a full P2P (Peer-to-peer) link so as not to drive the video from the board to the server and back to the client. Well, if I wanted to, I took it and did it :-) In fact, it turned out to be a simple and easy analogue of Adobovsky RTMFP (not to be confused with RTMP). Only now the transfer of sound to add any hands do not reach, so that rtsbord until dumb and deaf.
With UDP, the main problem is overcoming NAT. Since there is always a NAT at one end of the link (on the sending side or on the receiving side) - simply specifying the address and port of the server (or client) will not work - NAT will interfere. In the Windows Virt2real Player, it is possible to do a port forwarding using UPnP, but this is not exactly what I wanted. And what I wanted - it turned out only after thoughtful smoking of UDP Hole Punching technology. In the end, everything turned out as it should - no matter what the router, no matter where the client or server. The main thing that was Internet access. Although lying, there is only one type of NAT, which has not yet been broken through. All the time I forget how correctly it is called, seemingly symmetric NAT.
And yes, the usual TURN and STUN servers are not used in the board, only its own implementation. As I usually say: if you want to study technology, do it your way, and then compare with generally accepted solutions. Bicycle lovers will understand me. However, it often turns out that the bike is not so bad and performs its tasks better than conventional solutions.
This is so easy offtop was. We continue about NAT. P2P support is currently only in the Virt2real Player Windows application, has not yet been added to the android and iPhone / iPad. I checked the work with the connection through the Yota whistle, through the Beeline 4G whistle, through the access point on the smartphone, which also went out to the Internet through Beeline 4G. In all these cases, everything works, but noticed that it is ideal only through Yota. Through Beeline (in any of the tested types) also works, but the connection takes longer. Why is this happening - not yet understood. From the sad one - until we managed to get the link to work (both commands and video) when both the client and the server are connected via 4G whistles. Perhaps this is just symmetrical NAT and crept up.
Wi-Fi whistle is connected to Virturilka on board the machine (i.e. as it has been done so far according to the instructions from this topic). Only first we managed the machine locally, and now we can give someone to steer from Ineta.
To enable p2p mode, go to the web-control panel of the rebordboard, section “Local Settings”. There we set the parameter
Now you need to set the parameters p2p_uid and p2p_hash. This is a kind of login-password analogue, but there is no full authorization yet (but it will be necessary), so we use just such a bunch. p2p_uid is better to take from your account on rc.virt2real.ru/remoteconfig there it is called the “user ID”, then the mechanism of the invites will work (more on that below). And p2p_hash should be thought up independently. Any character set, maximum length 40 characters.
Everything, on it setup of a p2p of the rtsbord mode is finished. You need to make sure that Virturilka has access to the Internet and you can run Virt2real Player Windows. If you run it on a local network, in the same place where the redboard is installed, the player will detect the local redboard (it does not matter that it is in p2p mode) and you can connect directly. But if the player runs on a different network, you need to configure it for p2p mode.
We right-click on the player window, go to the “Network” -> “Network Setup” menu. In the "Role" tab, select "P2P", in the "P2P" tab, specify the UID and DevID. The UID is the same p2p_uid, which was entered in the settings of the redboards, and the DevID is the same p2p_hash. Save, right click on the video window again, “Network” -> “Connect”. In the lower left corner of the player should appear the message "Request a video feast" and "Request a feast of commands." Everything, process of detection of a feast and pairing went.
Sometimes it happens that the messages do not appear, then it is better to just restart the player (my joint, I haven’t caught it yet), when it starts, it will immediately start to connect with the parameters that we set for it, i.e. in P2P mode.
From the observed nuances - if the player is launched on a computer that goes to the Internet via Yota - the connection is quickly established. Of course, if Yota has a normal signal. But if through a Yota router or 4G a whistle from Beeline, the first connection can last up to a minute. But then all the next ones will be almost instantly. I know about where I nakosyachil, but fix it until his hands did not reach.
We connect the Yota whistle (via the USB-OTG adapter, by itself) to the Virtual USB port of the Virtuerki onboard the machine. Whistles on sale at Yota
Otherwise, everything is similar to the previous paragraph. If it is good to remove statuswifi module from active scripts in the “Additional modules” section of the active scripts and vice versa, put the statusyota module into active scripts in order to see the Yota signal parameters in the player.
Unfortunately, at my home Yota barely fries, so you can’t fully ride. But the Beeline 4G works fine, the 3 megabit stream (both incoming and outgoing) prolazit without problems.
In all the experiments below, all the settings are the same, only the type of communication changes.
In order to make it easier for someone to pass on the parameters for connecting to our typewriter in P2P mode, invitations were created. What are invites - everyone knows. Convenient thing.So now I will try to tell how to use it. In the player, this is still in the test, raw, kind, but it seems to work.
So, open the Windows Virt2real Player, right-click on the window, select “Invite” -> “Create an invite”. An important nuance - the player must be configured for P2P mode, i.e. In the network settings, all the above parameters for connecting to the machine are indicated. Otherwise, an invite will be created, but there will be nothing to connect to. By the way, you should add a warning if the parameters are not filled.
In the field "Your user ID" enter all the same our p2p_uid.
In the “Your user-magic” field, enter the contents of the “Your user-magic” field from the same page rc.virt2real.ru/remoteconfig
In the "Invites Name" field, enter the name under which this invite will be displayed on the page rc.virt2real.ru/remoteconfig .
Now click the button "Create an invite". The two-logo should spin, after which a long line will appear in the lower field “Line invite”, starting with the characters INV.
Now, if you open the remote configuration page of rc.virt2real.ru/remoteconfig, we’ll see that there was an invite that we just created.
Well, then all you have to do is drop this line to the person you want to let go. And he, in turn, should go into the player in the menu “Invite” -> “I have an invite!” And enter this line. After that, all the necessary parameters will be filled by themselves, you will not have to configure anything for the connection, you can immediately ride.
As I said, the system is damp, but it works. The plans - to make a normal login authorization password, so as not to have to mess with users and other aydishnikami.
The main requirement for remote control is one thing - as little as possible from pressing a button or moving the joystick to a corresponding change in the image displayed from the device board in the video stream. When you publish something on the topic of remote control, usually the first question is “what is the delay?”.
After numerous tests, it turned out that the delay is a subjective thing and affects the comfort of the control in different ways. Of course, it all depends on the maximum speed of the driving device. For flying devices (airplanes / copters) the minimum delay is very important, but when controlling driving devices - not always. When I, at the next exhibition, Hobby-Expo cut through the hall on a converted radio-controlled buggy, after ten minutes of taxiing, I caught myself thinking that the delay (whatever it was) ceased to be felt, you start to control it “ahead of time. At almost half the speed (and my buggy up to 80 km / h can accelerate), I calmly drove around the hall, tacking between pavilions, chairs, people. So here, rather, the stability of the delay is important, and not its absolute value in milliseconds.The minimum delay achieved when connecting to a normal router via a normal Wi-Fi whistle was somewhere around 200 ms, and when connecting through a generally accepted standard - powerful Ubiquity routers, the minimum delay with a confident connection is about 100 ms. The power of a video stream playback device (PC, smartphone) also affects the delay; if it does not have time to decode a raw video stream (H264 codec), there will be no pleasant smooth video.
When I ran a fairly high-speed buggy in Shenzhen, sitting at home in Moscow, it was quite comfortable to steer, although only the network ping from me to the server of the Chinese 4G operator was about 300 ms. Plus, another 100 ms ours - a total of half a second runs up. However, a great ride :-)
After the wild drops when flying on an airplane, what was the problem? If the connection is via 4G, then the mtu parameter should be set to 1322 or less. Less is not necessary, set mtu = 1322 and do not steam. In the local network, I usually put 16,000 (the maximum size of Jumbo Frames), in LAN it works fine, but through the Internet there will already be problems with the passage of packets.
Since the text turned out over-than-dofiga, I will repeat the main links.
Firmware rcboard-0.01.002.zip for Virturilki
Distribution Virt2real Player for Windows .
The same, but not the installer, but simply an archive.
Under Win8 , it does not correctly detect the presence of DirectX, so you can simply unpack the archive. Requires .Net 4.5 and DirectX.
Description of the previous version of the RCboards and Virt2real Player.
More description of the boards, the old protocol.
Application for Android . Only local control.
Application for IOS , only local control, no detection of devices. Now there is an old version, a new one is running.
PS Ehh, sorry Wheelbarrow Bond did not live up to the appearance of the redboard :-(
So, having gained experience in this case, I decided to try to more or less systematize various types of device management, so that when creating a new device, I did not have to rewrite a lot of things, and it was enough just to change some configuration parameters. As a result, the RCboard, or RCbord software package was born. Since I do all the controlled things with the controller Virt2real ( Virturilka ) as the main onboard brain, then the rebord was originally written just for her. So the whole bundle can be pathetically called "Software and hardware complex of the Retzbord".
In general, in the continuation of the topic, I will try to write a recipe about how to make a machine controlled via the Internet using Virtual Virtual Radio and RT-Board from a conventional radio-controlled machine (well, locally it will also be controlled). The communication channel will be the usual Wi-Fi (access to the Internet through a home router) or 4G connection through the Yota whistle.
')
Crawler BSD Racing 4WD RTR 2.4Ghz 1:10
I’ll just clarify - by the term “radio-controlled machine” I mean not cheap Chinese cars, in which all the electronics are implemented on one board, but more or less decent cars built according to a modular scheme - which have an engine speed control (collector, brushless) - and Servo to control the rotation of the front wheels.
I will give such a machine as a guinea pig only in this recipe, as it is easiest to repeat. With slight changes in the settings of the rebridgeboard and the addition of the engine speed regulator, the same can be done with any typewriter, the main thing is that the typewriter had wheels (yes even tracks) and had a motor.
What you need to build
- The machine with a motor regulator, engine and servo
- Battery (any suitable for the regulator voltage)
- Virt2real controller with virtual camera, USB-OTG adapter, micro-SD flash drive
- Whistle Wi-Fi or Yota (you can use any other 4G modem)
- Hands of moderate linearity
But first, to demonstrate some use cases.
Where it was already used
As I already wrote, we have already used a rebordboard in many places, but from the documented cases I found only these:
Tests of rzbordy on buggy in Shenzhen, management from Moscow
Tests of RCsboards on a crawler in St. Petersburg, control from Moscow
habrahabr.ru/company/virt2real/blog/223145
Testing of the rebels on an airplane over St. Petersburg, control from Moscow
habrahabr.ru/company/virt2real/blog/223183
Cool snow blower running rzbordy
By the way, the snow blower itself is the development of the Perm guys http://omiplow.ru
The hardest device running the RCBord
Joint project with an open research center of promising technologies
So, guinea pig
The crawler for remote control is good because it has a very high maneuverability.
By the way, he even knows how to do it like this.
The crawler has four-wheel drive, permanent locking differentials (all wheels spin at the same time) and a constant "downshift." Those. He drives relatively slowly, but powerfully and passable.
Tuning Virtual
Before you assemble the machine, you need to configure Virtuylka. First, consider the option to connect via Wi-Fi.
So, the points:
- Download the latest firmware, especially for the pcb files.virt2real.ru/firmware/virt2real-board/1.1/rcboard-0.01.002.zip
- We connect micro-USB - USB cable to Virtuirka, we plug the other end into the PC. A new network interface, a subnet 192.168.3.0/24, will appear on the computer. For Windows, you may need to install a driver.
- Open the basic admin panel (Virtual Virtluk web management panel) at http://192.168.3.1/admin
- Go to the “Settings” -> “Network” section and set the ip for the wlan0 interface (or specify dhcp if you do not need a static ip)
- Go to the section “Settings” -> “Wi-Fi” -> “Wi-Fi setting” and set the parameters of the wireless network (change the ssid and psk fields) for the first network
- Go to the “Settings” -> “Autostart” section - move the S80dhcp-server script to inactive (if the initial setup via USB is no longer required)
- We go to the section "Administration" -> "Restart" and rebuild Virturilcu
- Disconnect the USB cable from Virtuurka, connect the whistle whistle to the micro USB. From the recommended I recommend ASUS N10, N13, TP-link TL-WM722N, but best of all are pyatigighertsovye, for example, ASUS N53 or Dlink DWA-160 rev.B2
Checking virtual network connection
- During the virtual boot process, the LEDs on it will light up. When the power is turned on, if the bootable USB flash drive is successfully read, the green LED will light up. Then, while the kernel is loading, a blue LED will light up. After a full download, if the connection to the Wi-Fi network is successful, the red LED will turn on. And when the rebordboard starts up (it is registered in the autorun), all the LEDs go out and the red LED starts blinking.
- Install the application to manage. It is called Virt2real Player and is for Windows ( distribution or zip-archive ), for Android , for IOS . The application for IOS in the appstore is still the old version, the new one passes appruv, so while putting it to no purpose - the management will work clumsily.
- We open Explorer (if on a Windows computer), if Virturile has successfully connected to the local network via WiFi - the “RCboard (Virt2real)” device should appear in the “Network” section. You can get to the admin panel by right-clicking on this device and selecting the “View device web page” menu item.
It looks like this
- We start Virt2real Player for Windows or for Android, the RCboard server should be found. Server discovery in an IOS application is not yet implemented.
Screenshot Virt2real Player for Windows
Screenshot Virt2real Player for Android
The general principle of connecting motor cars
Usually, RC cars have two motors. One ordinary, collector - turns the wheels. The second - the servomotor turns the front wheels in the right direction. Those. it turns out that only two control channels are required - gas and a steering wheel. Initially (if the machine is purchased in assembled form) all channels are connected to a regular radio receiver with three-pin JR type connectors (standard servo connector). Black (or brown) wire - ground, red - power (5-6V), yellow (or white, or orange) - signal wire.
It is through the signal wire that we will control the motors, but first we need to power the servo, which drives the wheels. Here the general principle is - from the onboard battery the power supply with the voltage equal to the battery voltage goes through the thick wires to the powerful regulator of the collector (or brushless) motor. Inside this regulator there is a so-called BEC - voltage converter, making stable 5 volts (sometimes 6V, with a jumper on the regulator) required for powering the onboard servos, receiver and various other electronics from various battery voltages. This stabilized power supply is usually designed for a load of no more than 2-3A, although this also depends on the model of the regulator.
The BEC output voltage through the black and red wires of a thin three-core cable from the regulator is fed to the receiver. Here lies the main nuance, which not all immediately comprehend. I repeat - there is a cable with three conductors from the regulator. Of these, two cores are power supplied from the regulator, i.e. this is the way out. And the third wire (white, yellow or orange) is the control wire, i.e. entrance. It seems a trifle, but for some reason, many are confused.
The receiver has several groups of three-pin contacts. Their number depends on the number of channels for which the receiver is designed. The machines usually have 2 or 3 channels, so the groups are 3 or 4, respectively (one group to set the Pair jumper (signal for pairing receiver and transmitter). For these contact groups, all the power pins are closed between each other, i.e., ground and power comes from the regulator and is sent to all contact groups at once, but the signal pins are all independent, they receive a signal received by the receiver from the radio control equipment.
Conventional wiring diagram with collector motor
Conventional wiring diagram with brushless motor
Since we will manage with the help of an independent controller, we don’t need a typewriter receiver, we remove it altogether. And the three-core cables from the regulator and from the servos we need to connect in a sly way - connect the black wire with the black, red with the red. And the remaining white (yellow or orange) two wiring must be connected to Virturilka, namely to the pin CON44 and CON43, see the diagram . What kind of wire to which pin does not really matter, since the channels can be configured later in the config file.
It should look like this connection
Wiring the Virtualka to the intestines of a typewriter
If there are servos at hand, it is convenient to make a connection with them. I have with them eternal tension, so I just cut off the wiring and twist-solder.
And yes, the most important thing is that we supply power to the Virturku directly from the battery contacts. She is not afraid of voltage up to 20V, so the higher the voltage, the better, the less current will consume. The efficiency of the power converter (SEPIC, installed on Virturilka itself) drops only after 15V, so the ideal power supply is from 12 to 15 V, while at full load (with Wifi), the Virtirlka will consume about 150-300 mA. Although it also depends on the whistle (Yota whistle is very gluttonous, it will be more with it).
Assembly machine
I tried to capture the video of the assembly process of my crawler. I do not know how everything is clear there, but I think it will not be superfluous. Here's a video about the assembly:
Setting up the server rzbordy
All settings of the pcbord can be edited in a special control panel of the pcbord (not to be confused with the admin virtualka). This is how the control panel of the redboard looks now (the first version)
In the “General Settings” tab, you can set the device name (displayed when a device is detected in applications), specify whether to launch the rebordboard server automatically when the Virtualrika loads, set the type of configuration.
The configuration can be local (i.e., the configuration file resides in the directory of the redboards and is available for editing in the control panel), or it can be deleted when the configuration file is downloaded each time the launch of the redboards from the web server.
Server of remote configs, by default, http://rc.virt2real.ru/getconfig , create and edit configurations there are allowed only registered users of the forum.virt2real.ru
In the topic, I will tell only about the local configuration, you can try the remote configuration yourself if anyone is interested. By the way, when I rode on Shenzhen (the video at the end of the topic), I used the remote config so that I could change the settings. Changing the settings from the application is still in the form of sketches, it really does not work yet, but even when I finish it, the remote config is still useful.
So, we are most interested in the “Local Configuration” tab. In general, the default config already configures the RCBD to server mode, you can connect the machine and manage it locally (in the local network, from a Windows application, from an Android or from an iPhone / iPad). Is that you may need to swap channels. But for the P2P mode (peer-to-peer), to control via the Internet, the settings will have to be changed.
By default, the universal.so library is responsible for all management, for which the parameters are located at the end of the config, in the "[universal]" section.
The correspondence of control channels and PWM / PPM channels is specified by the axis parameter.
axis = 0,1,2,3
By default, 4 PPM channels are set up, which are on the pins CON43, CON44, CON19, CON42. These lines of config are responsible for this.
ch0 = 43, ppm, 500,1500,2500,127.0
ch1 = 44, ppm, 500,1500,2500,127.0
ch2 = 19, ppm, 500,1500,2500,127,1
ch3 = 42, ppm, 500,1500,2500,127,1
The channel setting format is:
chX = CON, TYPE, MIN, CENTER, MAX, NEUTRAL, NOAUTOCENTER
Where
X is the PWM / PPM channel number, from 0 to 3
CON - pin number (not GPIO, namely pin, see diagram )
TYPE - signal type, ppm or pwm. For the machine, you need ppm, for the pwm type, a different config string format.
MIN is the minimum position of the PPM signal, in milliseconds.
MAX - the maximum position of the PPM signal, in milliseconds.
CENTER is the center position of the PPM signal, in milliseconds.
NEUTRAL is the relative value of the neutral, i.e. neutral value of control commands. Normally = 127
NOAUTOCENTER - if = 0 - automatically return the signal to the center position, = 1 - do not return. For gas channels and a rudder, you need to specify 0, for servo channels, which are used to rotate the camera, you need to specify 1 (if there are any, of course)
If there are lights on the machine, you can turn them on and off, you will need to assemble a simple transistor amplifier (one field effect transistor, in fact). To get the control signal, use the “pins” parameter. It sets the pins that will be set to 0 or 1 when the button is pressed in Virt2real Player (on the on-screen buttons, on the keyboard, mouse, or on the gamepad).
pins = 1.30.0.0 | 2.31.0.1
The format is:
pins = CHANNEL, CON, DEFVALUE, SAVESTATE | ...
Where
CHANNEL - button channel (from 1 to 32)
CON - pin number to be set to 0 or 1 after the arrival of the control command from the buttons
DEFVALUE - the value in which this pin will be set when launching rebats
SAVESTATE - if = 0 - when pressing the button, set the pin to 1, when released - set to 0. If = 1 - when pressing the button, set the pin to 1, when releasing the button, do nothing. The next time you press the pin button to set to 0, when released - again do nothing. And so in the cycle.
Channels of buttons can be specified in a row, through the separator "|".
A brief conclusion from this vague information - if you have the gas and rudder channels confused - you can swap them by changing the axis parameter to axis = 1,0,2,3 :-)
If you need to limit the extreme position of the steering serva, change the MIN and MAX values ​​for the desired channel. If the machine goes forward or backward in neutral position - change the CENTER value for the desired channel.
Additional modules
In the “Additional modules” tab there is a list of active and inactive modules.
A module is a separate application (executable binary) that usually acts as a telemetry source. Active modules are those that are started automatically at the start of the redboard and terminate at the completion of its operation. In the control panel, you can move modules from one column to another by clicking on the orange arrow. When moving to the active column, the module starts up immediately, no matter if the rebord is running or not. When moving to inactive - the module automatically stops working.
The modules work simply - they read the required parameters and send via UDP to the local port (ext_telemetry) specified in the config. And there already rtsborda takes info and transmits via telemetry to the application Virt2real Player. At the same time, the same information is transferred to the user's device library (in our case, it is universal.so), so that the application can analyze the information and use it for its intended purpose. For example, I had a library of a device called autobot.so, a controlled trolley that, in addition to user management, could also autonomously drive, guided by a signal from an ultrasonic rangefinder.
From the main modules - statuswifi delivers information on the status of the Wi-Fi link to the radioboard. Airosstatus.php (yes, the module can also be written on pohapa) - reads the link status from the Ubiquity equipment, gps - reads the GPS receiver. The imu module processes the information from inertial sensors (Euler angles, azimuth and compass), although it still works with only one type of sensor, so it is not suitable for universal use. Nfc - reads NFC tags, but also works with only one type of reader. rc.in - reads PPM signals from an RC receiver, i.e. You can also control the machine with a normal app, it has priority over control commands via Wi-Fi. rfid - read RFID tags. statusyota - reads the status of the 4G modem Yota link. usrange - reads ultrasound rangefinder readings. voltage - determines the voltage of the onboard power supply, a simple voltage divider (2 resistors) is required to be connected to the ADC0. In general, there are a lot of interesting modules, for each there is a detailed description to be done, so for now we believe that I mentioned them for seed :-)
For our managed machine recipe, the statuswifi module is relevant - if we are setting up a connection via Wi-Fi or statusyota - if we connect the Virturika through the Yota whistle.
Application setup
In Android and ipad-iphone applications, the settings are simple, only in the choice of control channels. In Android, there is also a channel button selection (by default, the channel is not set, the buttons are not displayed). But in the Windows application, I have wound so many features that I myself come to a state of light panic with the knowledge that all this must be documented. While I can only give a reference to the description of the previous version of the application
http://wiki.virt2real.ru/wiki/How_to do_controlled_trolley_2
http://wiki.virt2real.ru/wiki/RCboard
The control protocol has since changed noticeably, but the configuration of the Windows application has changed slightly, so it can help with picking. I will try to write a detailed description of the current version next year :-)
By the way, in the earliest version, I used the MAVLINK protocol to transmit telemetry, but as I got fouled with features, it was not enough, so I switched to my own protocol. I am thinking of adding MAVLINK as a parallel telemetry channel, but this is already in the next version of the application.
I can only say one thing - it is best to control the machine with a USB steering wheel and pedals connected to the computer. Well, or at least with RC appy, connected by a coaching connector to a computer. A finger across the screen of a smartphone can be cool, but it's not convenient without tactile sensations.
And now the most important thing is management via the Internet.
P2P mode introductory information
Since both the control channel and the video channel use UDP, I wanted to make a full P2P (Peer-to-peer) link so as not to drive the video from the board to the server and back to the client. Well, if I wanted to, I took it and did it :-) In fact, it turned out to be a simple and easy analogue of Adobovsky RTMFP (not to be confused with RTMP). Only now the transfer of sound to add any hands do not reach, so that rtsbord until dumb and deaf.
With UDP, the main problem is overcoming NAT. Since there is always a NAT at one end of the link (on the sending side or on the receiving side) - simply specifying the address and port of the server (or client) will not work - NAT will interfere. In the Windows Virt2real Player, it is possible to do a port forwarding using UPnP, but this is not exactly what I wanted. And what I wanted - it turned out only after thoughtful smoking of UDP Hole Punching technology. In the end, everything turned out as it should - no matter what the router, no matter where the client or server. The main thing that was Internet access. Although lying, there is only one type of NAT, which has not yet been broken through. All the time I forget how correctly it is called, seemingly symmetric NAT.
And yes, the usual TURN and STUN servers are not used in the board, only its own implementation. As I usually say: if you want to study technology, do it your way, and then compare with generally accepted solutions. Bicycle lovers will understand me. However, it often turns out that the bike is not so bad and performs its tasks better than conventional solutions.
This is so easy offtop was. We continue about NAT. P2P support is currently only in the Virt2real Player Windows application, has not yet been added to the android and iPhone / iPad. I checked the work with the connection through the Yota whistle, through the Beeline 4G whistle, through the access point on the smartphone, which also went out to the Internet through Beeline 4G. In all these cases, everything works, but noticed that it is ideal only through Yota. Through Beeline (in any of the tested types) also works, but the connection takes longer. Why is this happening - not yet understood. From the sad one - until we managed to get the link to work (both commands and video) when both the client and the server are connected via 4G whistles. Perhaps this is just symmetrical NAT and crept up.
P2P mode setup, Wi-Fi on board
Wi-Fi whistle is connected to Virturilka on board the machine (i.e. as it has been done so far according to the instructions from this topic). Only first we managed the machine locally, and now we can give someone to steer from Ineta.
To enable p2p mode, go to the web-control panel of the rebordboard, section “Local Settings”. There we set the parameter
role = p2p
Now you need to set the parameters p2p_uid and p2p_hash. This is a kind of login-password analogue, but there is no full authorization yet (but it will be necessary), so we use just such a bunch. p2p_uid is better to take from your account on rc.virt2real.ru/remoteconfig there it is called the “user ID”, then the mechanism of the invites will work (more on that below). And p2p_hash should be thought up independently. Any character set, maximum length 40 characters.
Everything, on it setup of a p2p of the rtsbord mode is finished. You need to make sure that Virturilka has access to the Internet and you can run Virt2real Player Windows. If you run it on a local network, in the same place where the redboard is installed, the player will detect the local redboard (it does not matter that it is in p2p mode) and you can connect directly. But if the player runs on a different network, you need to configure it for p2p mode.
We right-click on the player window, go to the “Network” -> “Network Setup” menu. In the "Role" tab, select "P2P", in the "P2P" tab, specify the UID and DevID. The UID is the same p2p_uid, which was entered in the settings of the redboards, and the DevID is the same p2p_hash. Save, right click on the video window again, “Network” -> “Connect”. In the lower left corner of the player should appear the message "Request a video feast" and "Request a feast of commands." Everything, process of detection of a feast and pairing went.
Sometimes it happens that the messages do not appear, then it is better to just restart the player (my joint, I haven’t caught it yet), when it starts, it will immediately start to connect with the parameters that we set for it, i.e. in P2P mode.
From the observed nuances - if the player is launched on a computer that goes to the Internet via Yota - the connection is quickly established. Of course, if Yota has a normal signal. But if through a Yota router or 4G a whistle from Beeline, the first connection can last up to a minute. But then all the next ones will be almost instantly. I know about where I nakosyachil, but fix it until his hands did not reach.
P2P mode setting, Yota is on board
We connect the Yota whistle (via the USB-OTG adapter, by itself) to the Virtual USB port of the Virtuerki onboard the machine. Whistles on sale at Yota
Otherwise, everything is similar to the previous paragraph. If it is good to remove statuswifi module from active scripts in the “Additional modules” section of the active scripts and vice versa, put the statusyota module into active scripts in order to see the Yota signal parameters in the player.
Illustrations of various types of connections
Unfortunately, at my home Yota barely fries, so you can’t fully ride. But the Beeline 4G works fine, the 3 megabit stream (both incoming and outgoing) prolazit without problems.
In all the experiments below, all the settings are the same, only the type of communication changes.
Wi-Fi whistle crawler, connecting from the Internet, via Yota
Crawler whistling Yota, connect from your home network. Yota signal is very bad :-(
Crawler whistle Wi-Fi, from a laptop that has access to the Internet via a smartphone (Beeline 4G)
Invites
In order to make it easier for someone to pass on the parameters for connecting to our typewriter in P2P mode, invitations were created. What are invites - everyone knows. Convenient thing.So now I will try to tell how to use it. In the player, this is still in the test, raw, kind, but it seems to work.
So, open the Windows Virt2real Player, right-click on the window, select “Invite” -> “Create an invite”. An important nuance - the player must be configured for P2P mode, i.e. In the network settings, all the above parameters for connecting to the machine are indicated. Otherwise, an invite will be created, but there will be nothing to connect to. By the way, you should add a warning if the parameters are not filled.
In the field "Your user ID" enter all the same our p2p_uid.
In the “Your user-magic” field, enter the contents of the “Your user-magic” field from the same page rc.virt2real.ru/remoteconfig
In the "Invites Name" field, enter the name under which this invite will be displayed on the page rc.virt2real.ru/remoteconfig .
Now click the button "Create an invite". The two-logo should spin, after which a long line will appear in the lower field “Line invite”, starting with the characters INV.
Now, if you open the remote configuration page of rc.virt2real.ru/remoteconfig, we’ll see that there was an invite that we just created.
Well, then all you have to do is drop this line to the person you want to let go. And he, in turn, should go into the player in the menu “Invite” -> “I have an invite!” And enter this line. After that, all the necessary parameters will be filled by themselves, you will not have to configure anything for the connection, you can immediately ride.
As I said, the system is damp, but it works. The plans - to make a normal login authorization password, so as not to have to mess with users and other aydishnikami.
A little about the delay
The main requirement for remote control is one thing - as little as possible from pressing a button or moving the joystick to a corresponding change in the image displayed from the device board in the video stream. When you publish something on the topic of remote control, usually the first question is “what is the delay?”.
After numerous tests, it turned out that the delay is a subjective thing and affects the comfort of the control in different ways. Of course, it all depends on the maximum speed of the driving device. For flying devices (airplanes / copters) the minimum delay is very important, but when controlling driving devices - not always. When I, at the next exhibition, Hobby-Expo cut through the hall on a converted radio-controlled buggy, after ten minutes of taxiing, I caught myself thinking that the delay (whatever it was) ceased to be felt, you start to control it “ahead of time. At almost half the speed (and my buggy up to 80 km / h can accelerate), I calmly drove around the hall, tacking between pavilions, chairs, people. So here, rather, the stability of the delay is important, and not its absolute value in milliseconds.The minimum delay achieved when connecting to a normal router via a normal Wi-Fi whistle was somewhere around 200 ms, and when connecting through a generally accepted standard - powerful Ubiquity routers, the minimum delay with a confident connection is about 100 ms. The power of a video stream playback device (PC, smartphone) also affects the delay; if it does not have time to decode a raw video stream (H264 codec), there will be no pleasant smooth video.
When I ran a fairly high-speed buggy in Shenzhen, sitting at home in Moscow, it was quite comfortable to steer, although only the network ping from me to the server of the Chinese 4G operator was about 300 ms. Plus, another 100 ms ours - a total of half a second runs up. However, a great ride :-)
Some nuances of 4G communication
After the wild drops when flying on an airplane, what was the problem? If the connection is via 4G, then the mtu parameter should be set to 1322 or less. Less is not necessary, set mtu = 1322 and do not steam. In the local network, I usually put 16,000 (the maximum size of Jumbo Frames), in LAN it works fine, but through the Internet there will already be problems with the passage of packets.
Links
Since the text turned out over-than-dofiga, I will repeat the main links.
Firmware rcboard-0.01.002.zip for Virturilki
Distribution Virt2real Player for Windows .
The same, but not the installer, but simply an archive.
Under Win8 , it does not correctly detect the presence of DirectX, so you can simply unpack the archive. Requires .Net 4.5 and DirectX.
Description of the previous version of the RCboards and Virt2real Player.
More description of the boards, the old protocol.
Application for Android . Only local control.
Application for IOS , only local control, no detection of devices. Now there is an old version, a new one is running.
PS Ehh, sorry Wheelbarrow Bond did not live up to the appearance of the redboard :-(
If anyone does not know
habrahabr.ru/company/virt2real/blog/172167
The latest tests, when from the TV channel Discovery came video to shoot
Sach she looks like this
Rear gear died, the bottom rusted and fell out. In general, kirdyk pupsiku :-(
The latest tests, when from the TV channel Discovery came video to shoot
Sach she looks like this
Rear gear died, the bottom rusted and fell out. In general, kirdyk pupsiku :-(
Source: https://habr.com/ru/post/246723/
All Articles