<link rel="self" type="application/atom+xml" hreflang="" href="gemini://benjaminja.com/tags/drone/feed.xml" />
<link rel="alternate" type="text/gemini" hreflang="" href="gemini://benjaminja.com/tags/drone/" /><id>/</id>
2018-02-23T01:37:32Z
Hugo 0.129.0
<title><![CDATA[rcProtocol update]]></title>
<link rel="alternate" type="text/gemini" hreflang="" href="gemini://benjaminja.com/log/2018/02/23-rcprotocol_update/" />
<id>gemini://benjaminja.com/log/2018/02/23-rcprotocol_update/</id>
<updated>2018-02-23T01:37:32Z</updated>
<summary type="gemini"><![CDATA[It has been far too long since the last update, near the end of October. Since then I have been able to make a bunch of improvements. When I last posted, the remote could only pair and connect, now constant communication works, telemetry works, the remote even reconnects after resets.
]]><![CDATA[It has been far too long since the last update, near the end of October. Since then I have been able to make a bunch of improvements. When I last posted, the remote could only pair and connect, now constant communication works, telemetry works, the remote even reconnects after resets.
I have also been able to fly my quad with the remote.
As the name implies, Constant communication allows for communications to be sent constantly. In order for CC to work, both the receiver and transmitter call an update function during its program loop. The transmitter is restricted to run update() at a certain interval designated by the receiver’s settings. While the receiver can run update() as often as it is called.
There are several transmission types, dictated by the first byte in the packet. For example, 0xA0-0xAF are reserved for channel packets, and 0xC0 is for disconnecting. The receiver processes all of the packets in its update(), while the transmitter will send certain packets from different functions, such as the disconnect packet.
Telemetry is sent by the receiver through ack-payloads. At the moment, Telemetry is sent every time a packet is received. I plan to make the frequency of telemetry packets set by the receiver settings.
I haven’t yet merged this to master yet, but telemetry has its own container class now. It manages all of the bytes in the telemetry object into the proper data. There are a bunch of things that can be sent through telemetry, and each needs its own implementation so the remote can enable/disable specific telemetry channels it uses. This allows for more efficient telemetry packets.
The telemetry class so far as only implemented, Battery Voltage, Current, Temperature, rpm, GPS, and alarms.
For a normal receiver, if the receiver were to reset for whatever reason, there wouldn’t be much of a problem, since the transmitter will not care if it disconnected for a bit, but with this system, if that were to happen, it would have to go into connect mode, and do its handshake to make sure they can connect. This is not good, so if the remote, or receiver is to reset while connected, it will immediately consider itself to be connected with that device, and check if the other device is listening.
I think that the library is very close to being finished, but there are still things yet to do. One of the things I want to do is create a container class for the channels similar to the telemetry class.
I want to have the channels be more standard so that the receiver can request certain channels, and the transmitter will know what to do. I think this can be done by recreating the Telemetry class. The remote would tell the Channels class which channels it can provide, and the receiver settings will contain information about which channels it needs. When the two pair, it will check if the transmitter has the channels the receiver asked for. If it works, then they will pair as normal, if they don’t match, a warning will be sent to the transmitter’s firmware, and it can decide whether they can pair and if they do, which channels to send instead.
I think this is one of the big things that need to be done before the library can be considered finished, but there are still a few small things that I would like to implement, like signal strength, and other things that I can’t think of right now.
=> 📭 Message me | 📝Or mention this post
]]>
<category term="wordpress" label="Wordpress" scheme="gemini://benjaminja.com/tags/wordpress/" />
<category term="drone" label="Drone" scheme="gemini://benjaminja.com/tags/drone/" />
<published>2018-02-23T01:37:32Z</published></entry>
<title><![CDATA[rcProtocol update]]></title>
<link rel="alternate" type="text/gemini" hreflang="" href="gemini://benjaminja.com/log/2018/02/22-rcprotocol_update/" />
<id>gemini://benjaminja.com/log/2018/02/22-rcprotocol_update/</id>
<updated>2018-02-23T01:37:32Z</updated>
<summary type="gemini"><![CDATA[It has been far too long since the last update, near the end of October. Since then I have been able to make a bunch of improvements. When I last posted, the remote could only pair and connect, now constant communication works, telemetry works, the remote even reconnects after resets.
]]><![CDATA[It has been far too long since the last update, near the end of October. Since then I have been able to make a bunch of improvements. When I last posted, the remote could only pair and connect, now constant communication works, telemetry works, the remote even reconnects after resets.
I have also been able to fly my quad with the remote.
There are several transmission types, dictated by the first byte in the packet. For example, 0xA0-0xAF are reserved for channel packets, and 0xC0 is for disconnecting. The receiver processes all of the packets in its update(), while the transmitter will send certain packets from different functions, such as the disconnect packet.
I haven’t yet merged this to master yet, but telemetry has its own container class now. It manages all of the bytes in the telemetry object into the proper data. There are a bunch of things that can be sent through telemetry, and each needs its own implementation so the remote can enable/disable specific telemetry channels it uses. This allows for more efficient telemetry packets.
The telemetry class so far as only implemented, Battery Voltage, Current, Temperature, rpm, GPS, and alarms.
I want to have the channels be more standard so that the receiver can request certain channels, and the transmitter will know what to do. I think this can be done by recreating the Telemetry class. The remote would tell the Channels class which channels it can provide, and the receiver settings will contain information about which channels it needs. When the two pair, it will check if the transmitter has the channels the receiver asked for. If it works, then they will pair as normal, if they don’t match, a warning will be sent to the transmitter’s firmware, and it can decide whether they can pair and if they do, which channels to send instead.
I think this is one of the big things that need to be done before the library can be considered finished, but there are still a few small things that I would like to implement, like signal strength, and other things that I can’t think of right now.
=> 📭 Message me | 📝Or mention this post
]]>
<category term="wordpress" label="Wordpress" scheme="gemini://benjaminja.com/tags/wordpress/" />
<category term="drone" label="Drone" scheme="gemini://benjaminja.com/tags/drone/" />
<published>2018-02-23T01:37:32Z</published></entry>
<title><![CDATA[rcProtocol]]></title>
<link rel="alternate" type="text/gemini" hreflang="" href="gemini://benjaminja.com/log/2018/02/03-rcprotocol/" />
<id>gemini://benjaminja.com/log/2018/02/03-rcprotocol/</id>
<updated>2018-02-04T04:29:25Z</updated>
<summary type="gemini"><![CDATA[🔡 Github Repository 📕 Library Documentation rcProtocol (working title) is a protocol for communications between transmitters and receivers. It is not for receivers communicating with flight controllers. I don’t intend this to become a standard, though that would be fun; I intend this to be a niche system for hobbyists who want to make their own remote system without going through the effort of creating their own communications protocol.
]]><![CDATA[=> https://github.com/ttocsneb/rcProtocol 🔡 Github Repository
rcProtocol (working title) is a protocol for communications between transmitters and receivers. It is not for receivers communicating with flight controllers. I don’t intend this to become a standard, though that would be fun; I intend this to be a niche system for hobbyists who want to make their own remote system without going through the effort of creating their own communications protocol.
There is only one dependency for the library, which is an [RF24L01(+)] chip with the [TMRh20 RF24] library.
=> RF24L01(+) | TMRh20 RF24
I have tried to keep my code system agnostic, so you could theoretically run rcProtocol anywhere RF24 can, but I can’t make any promises.
rcProtocol allows remotes to be paired with more than one receiver. Each receiver has its own settings that are sent to the remote when paired. There are only simple radio specific settings at the moment, but I plan to give the receiver control of which channels are sent. You can read all of the settings in the documentation [here].
=> here
There is a max of 15 channels that can be sent, this is with full 32-byte packets. I might add the ability to send up to 16 unique channel packets, upping the theoretical channel maximum to 240 channels, though I would not recommend that.
Telemetry is also possible, by populating ACK packets. At the time of writing (V0.3.0), You have to manually parse telemetry. I plan to have standard stuff: Battery, Current, Temperature, RPM, Location, Alarms, etc.
An emergency reconnect system is enabled, making it so that if a board gets reset, it will automatically reconnect to the last device it was connected to before it reset. This is useful because of the way the transmitter/receiver connect, doing its special handshake would not work in a power failure as it would take too much time.
The protocol has two main classes: DeviceProtocol (rcDeviceProtocol.h), and RemoteProtocol (rcRemoteProtocol.h). The two classes mirror each other in functionality as they are for the receiver, and transmitter respectively. They both have the same functions but are implemented slightly differently.
To pair with each other, both need to call pair(). The remote broadcasts its ID onto a pairing channel. The receiver will collect this, then start broadcasting its ID, as well as settings.
To connect, they both have to have paired with each other and call connect(). The receiver will broadcast its ID on the remote’s channel. The remote will then check if the ID is correct, then send a confirmation/denial response. They will both load the settings, and test if communication is still possible.
Once they are connected, the remote is free to send data to the receiver. Though currently, update() and disconnect() are the only communications the remote can send.
There are two other classes: RCGlobal; an internal class used by DeviceProtocol and RemoteProtocol, and RCSettings; a class that holds the settings for communications
=> 📭 Message me | 📝Or mention this post
]]>
<category term="wordpress" label="Wordpress" scheme="gemini://benjaminja.com/tags/wordpress/" />
<category term="drone" label="Drone" scheme="gemini://benjaminja.com/tags/drone/" />
<published>2018-02-04T04:29:25Z</published></entry>
<title><![CDATA[RC Remote API: Pairing/Connecting]]></title>
<link rel="alternate" type="text/gemini" hreflang="" href="gemini://benjaminja.com/log/2017/10/29-rc_remote_pairing/" />
<id>gemini://benjaminja.com/log/2017/10/29-rc_remote_pairing/</id>
<updated>2017-10-29T16:37:43Z</updated>
<summary type="gemini"><![CDATA[I was able to get progress on the api for my remote. It can now successfully pair, and connect. I still have yet to send a steady stream of data; That will be my next goal.
]]><![CDATA[I was able to get progress on the api for my remote. It can now successfully pair, and connect. I still have yet to send a steady stream of data; That will be my next goal.
In order to pair, both the receiver, and transmitter must call the pair function. The remote will start announcing its ID on the PAIR0 channel, the receiver will be listening on that channel for any data.
When data is received, the receiver will save the ID, switch to write mode on the received channel and send settings (currently that only consists of its ID). The transmitter will know that data was received, as auto-ack is turned on, and switch to receive mode, waiting for settings. When settings are received, it will pass them on to the remotes firmware to save.
When connecting, The receiver will go into write mode, announcing its ID on the remote ID channel saved from pairing. The transmitter will be listening on its channel. When it gets a transmission, it check if the ID sent was saved.
If any of the Saved IDs matches the sent ID, the transmitter will send back an OK, if not, it will send a FAIL, and will not connect to the receiver.
Right now, nothing happens after that. I will have both devices set a value that the device was connected, and which device it was connected to. This should allow the transmitter to know if it is okay to send data freely.
=> 📭 Message me | 📝Or mention this post
]]>
<category term="wordpress" label="Wordpress" scheme="gemini://benjaminja.com/tags/wordpress/" />
<category term="drone" label="Drone" scheme="gemini://benjaminja.com/tags/drone/" />
<published>2017-10-29T16:37:43Z</published></entry>
<title><![CDATA[RC Remote Software]]></title>
<link rel="alternate" type="text/gemini" hreflang="" href="gemini://benjaminja.com/log/2017/10/24-rc-remote-software/" />
<id>gemini://benjaminja.com/log/2017/10/24-rc-remote-software/</id>
<updated>2017-10-24T15:00:22Z</updated>
<summary type="gemini"><![CDATA[Over the course of the past year or so, I have torn apart an old RC Remote and put new electronics in. I think I have blogged about it before I rebuilt my website, and hope to restore those lost posts some day.
]]><![CDATA[Over the course of the past year or so, I have torn apart an old RC Remote and put new electronics in. I think I have blogged about it before I rebuilt my website, and hope to restore those lost posts some day. I have since stopped working on it until about a week ago.
I discovered [PlatformIO], a plugin for Visual Studio Code, that allows for development on just about any embedded computer. This allowed me to start developing the software for my remote in full.
=> PlatformIO
I have planned to write the software in two parts: The comms library, and the Remote software. The comms library is an API designed to work with nRF24L01 chips and is built for both the transmitter and receiver. The remote Software allows the comms library to work with the hardware of the remote.
The comms library also has two parts: The Receiver, and the Transmitter. The receiver is the class a device connecting to the remote would use, while the transmitter is the class the remote would use. They are built to work with each other, and so both can be explained simultaneously.
The library will allow a transmitter to pair with more than one device, along with device-specific settings that would be stored in the transmitter (The library doesn’t save the settings, but asks the remote to save/retrieve them). When the transmitter connects, it waits for the receiver to announce its ID on the transmitter’s channel, the transmitter will then load the settings for that device, and check if all the requirements are valid. If the requirements are not valid, the remote should warn the user, and ask what to do, while the device waits for further commands. If everything is good, the remote should alert the user that the connection was successful.
You should also be able to have add-ons: a device that can communicate with the receiver through the transmitter. An example of an add-on is a Gymbal remote; you would be able to control a gimbal mounted on a quadcopter from a second remote without having a second transmitter. The receiver can specify in the settings wither a specific add-on is required, and which channels from an add-on to send, or which telemetry channels to send to an add-on. The main transmitter is also considered to be an add-on (its ID is 0) so can have specific channels excluded from the transmission.
The software for the remote handles all of the specifics that the comms library can’t. It will control the display, EEPROM, and handle inputs. The screen will be controlled by a UI class that controls several subscreen objects.
The menu structure will be set up something like this
mainscreen
|---Settings
|---System Settings
|---Connect On startup
|---Channels Graph
|---Reverse Channels
|---Change ID
|---Forget All receivers
|---etc
|---Receiver Settings
|---Change Name
|---Change Background Image
|---Forget This Receiver
|---etcI have already gotten the basic structure for the UI setup, but I haven’t done much more than that. I plan to get a connection between the receiver and transmitter done next.
=> 📭 Message me | 📝Or mention this post
]]>
<category term="wordpress" label="Wordpress" scheme="gemini://benjaminja.com/tags/wordpress/" />
<category term="drone" label="Drone" scheme="gemini://benjaminja.com/tags/drone/" />
<published>2017-10-24T15:00:22Z</published></entry>
text/xmlThis content has been proxied by September (3851b).