Commanding a Rocket Via Radio - Homemade Two-Way Datalink

hi everybody welcome back to lafette systems I make rockets with active control systems like this one that has a flight computer in its nose and four movable after control surfaces that steer it through the air I have a number of different size Rockets with different control layouts and guidance schemes and even a hot launch Silo three two 1 this video is about an important part of these Rockets as systems the radio data link now I have a whole build series on this rocket Diamond X Video One focused on its airframe and construction and the second video is all about avionics the third video is a deep dive into the flight computer and flight software this video is a supplement to those but this data link is used for all the rockets that I fly now this video is going to get a bit technical at times talking about bits and bites and payloads and check sums but I'll try to keep it as approachable as I can so what is a data link and why do we need one a data link like this actually has a pretty simple job let elements on this rocket Network talk to each other seamlessly I need to be able to push a button on the Ground Control software and the rocket has to do something we're going to break down this structure into a number of different layers to make it easier to understand what's going on for those of you with a computer science background the seven layer OSI model should look really familiar now my network is actually much simpler it uses a static Hub and spoke geometry and we don't need to negotiate permissions or anything so that lets us simplify the model a whole bunch down to just the three layers shown here first we're going to talk about what these layers do and then dive into each one and see how it works so the first is the interface layer this translates a user input on my Ground Control software into a command and then when the rocket receives that command it does something with it this is implemented On The Ground Control software and on the flight software next is what I'm going to call the transport protocol layer this takes all the information we're sending back and forth and puts them into concise little packets it also performs error checking so when we receive a packet we know that we've received it in its entirety and there's no errors in the message this uses a protocol that I made up that I call scalpel and last is the physical layer this is how we get those packets from one place to another this is either a wired connection using something like USB or rs422 or it is a wireless connection using an XP radio so first let's look at the interface layer this is basically like a rocket language uh you can't just scream at a rocket in English and have it do something so we need to invent a language that the rocket can speak and then make sure that your Ground Control software is speaking that same language to your rocket now the cool thing is that you can just make this language up it can be whatever you want now the language my rocket speak is called AVC or all vehicle Communications in practice this is a really big word document that lists what all the commands are and then what all the payload structures are so I can make sure those are standardized across all the different systems of the network if I want the rocket to do something like test its fins for example I send it a command from the ground station so in the word document I list what all these commands are and then I assigned each one of them a different number in the case of a finest that number is 101 decimal if the rocket receives command 101 it executes a series of processing functions which end with its control State being changed to control fin test then I have to make sure that when I push the appropriate button on the GCS it sends the command 101 over the radio as long as it don't mix up anything in that process the whole thing works out for your Rockets you can make up your own commands you can have your commands be as many bits long or short as you want and you can even do multi-b commands if you're interested now that all sounds pretty easy but in practice the data link gets a whole lot more complicated first if I have multiple Rockets or other things like launch silos out at the range I don't want all of them to start executing whatever they think command 101 does we need to be able to send a command to a individual device on the network we also need to tell the rocket to interpret 101 as a command not something else like a network ping or as Telemetry so ABC sentences what we call the payload always start with two special bites at the very front that avoid these Mix-Ups the first bite sent in every ABC payload specifies who is sending and who should be receiving the following information when the other Network's devices receive and parse a packet they check the receiver ID if the receiver isn't them then they can safely ignore the rest of the message these take the form of four bit addresses set in the compiled flight code so I can have up to 16 different devices on the network bite two is a payload descriptor bite and describes how the receiver should interpret the rest of the message if I want to send commands for example I make sure that this bite is decimal 20 when the rocket receives that it parses everything that follows add commands there are a number of other types of payloads which we'll send and we'll discuss these later in the video and they'll each get their own payload descriptor but now for a lot of reasons sometimes commands don't quite make it to the rocket especially if the physical layer relies on a radio connection because of this ABC also features a command acknowledgement function when the ground station sends a command it's also added to a big list of unacknowledged commands along with the time that it was sent when the rocket receives a list of commands they're echoed back to the sender as command acknowled when the ground station receives these back it removes them from the unacknowledged commands list if a command sits on that list for too long it's resent over and over and over again until it either times out or the rocket finally receives it this whole process helps us make certain that when we send a command the rocket receives it and I don't have to sit there mashing the fin test button until something finally happens so far we've only looked at half of the data links functionality though sending the rocket commands is great but the rocket also needs to be sending down Telemetry telling me what state it's in position velocity all sorts of stuff so let's switch gears and look at the second half of ABC which is the Telemetry functionality the rocket is sensing and recording a lot of different channels of data and he needs to send some of that data down to the ground station for display on the screen this generally takes the form of the rocket sending long list of numbers which we need to parse correctly on the ground we need to know if a number is a voltage a speed what format it's in whether it's an integer or a floating Point number and what to do with that number once we finally get it there's also too much data to reliably send a single massive list so we break up the data into shorter Telemetry payloads and send them one chunk at a time for Telemetry ABC specifies a number of different Telemetry structures all have a maximum length of 28 bytes and we'll get to this limit later for Diamond X there are six different Telemetry pads it sends down it sends these one at a time and when we get to Telemetry structure six we loop back and start with number one again each Telemetry has a different payload descriptor bite which lets the ground controlof or figure out what to do with any given string of numbers that it receives ABC then specifies what each B in each different payload means both the rocket flight code and GCS parsing code have to agree on the structure again where that word document comes in handy and like the commands list this structure is something you get to make up for your Rockets you get to decide what data to send and what its Precision is now I've got another video coming out on this channel very shortly and when it does I'll link it in the description that is a worked example of both ABC generating a Telemetry payload and then also the scalpel process by which we put that into a packet it gets pretty technical so I've put that in a separate video but if you want to make your own data link system I'm hoping that's a good resource to help so there's our first layer that's all vehicle Communications and it does the Telemetry and the commanding for the rocket again this is the rocket language that all the devices on this network speak so wrapped around these ABC payloads is something that I'll call the transport protocol layer this is four extra bytes and this extra information is responsible for ensuring that the payload is delivered in full without without any errors to the receiver now remember these payloads might be sent asynchronously with one bite coming in at a time they also might have variable message link we saw this in the commands commands might be sent you know one command at a time but the payloads for Telemetry might be up to 28 bytes long so the receiver has to know when one packet ends and when the next packet begins particularly if it's just receiving a stream of uninterrupted bites so the protocol that I came up with for this is called the scalpel or the systems Communications asynchronous protocol lightweight cuz remember if you ever want to work for the military industrial complex your most important skill is actually making acronyms and I'm putting those skills to the test a whole bunch in this video so first we got to tell when one scalpel packet stops and the next one starts so to do this we pick a very special bite you get to pick I picked decimal 170 this is AA in heximal or in binary it's one 1 0 1 0 1 0 we're going to put this start bite right at the beginning of every single packet that we send so when we're processing this data stream if we ever see decimal 170 as a bite we know that a new packet has started and we process it as such now next up is message length because we have these variable message links we need to include a payload length bite this tells us how long the incoming packet is and when we should stop with the second bite we can include the length of the payload and this will inform our processing function when to stop parsing this and when to start looking for the beginning of the next packet in between them there might be noise or something so we want to separate the stop processing one packet and the start processing the next one function now we're going to pause here here and jump back to the start bite discussion we chose the bite decimal 170 to indicate when a new packet has begun but some of you may have already noticed a problem if we're scanning that start bite to show up to start reading the next packet what happens when one of our payload bites happens to be that start bite right maybe we're sending 170 molts as an integer and so that bite would just be 170 if that happens then this whole protocol breaks down and we start reading one packet halfway through the previous one the world collapses so one method to solve this is called consistent overhead bite stuffing or cobs this is probably the most complicated part of the protocol so if it doesn't make sense on your F viewing that's totally okay I had to read a whole bunch of stuff on it to make it make sense there's plenty of resources out there that are going to describe it better than me and I'll link some of those in the video description so cobs solves the problem of our start bite showing up anywhere in the payload by just removing it if that ever happens and very cleverly replacing it with something else the short version of this is that this cobs bite by number three contains the index of the next B which happens to be the start bite we're then safe to replace that b in the payload with something else because we might have 170 appear multiple times a logical thing to replace this bite with is the index of the next time it happens and then replace that one with the index of the next time it happens if the start bite doesn't appear anywhere else in the payload then we can either replace this last one with the index of itself or the index of something that's longer than the length of the payload when you actually go to process a packet first we start at the cobs bite and we go to the bite to which it's indexing replacing that with 170 again this gets our completed payload to the destination without ever having to send that start bite anywhere inside of the payload itself now the last feature we have to look at is error checking we just have one extra bite at the end of the packet and this is going to be a check suum there's a whole bunch of different ways to check sum check suming basically involves taking the payload and then running it through a mathematical function and recording its output we then take the payload we receive run it through that same mathematical function and then our two check sums should match if the check sums don't match then that indicates that there is an error somewhere either in our payload or in the check sum itself there are similar systems that actually do error correction so they'll tell you not just that there's an error but where the error is and then it actually allows you to correct the packet I haven't implemented that but that's a great next step if you're trying to do a more sophisticated data link now order here is important this check sum can evaluate to any value between 0 and 255 including 170 which is our start bite for that reason the payload and the check sum need to be included in the cobs process because the check sum excludes our cobs and packet length bytes errors in either of those two won't get caught scalpel actually includes a method for detecting errors in those two bites but I'll go into detail on that in the worked example video it's a little too technical for this one so that's our transport protocol layer it gets the payload prepared into packets which can be sent asynchronously and with variable message length with a 28 byte payload and 32 by total packet we are at best 87.5% efficient at sending data and if we're only sending our single command it's not very efficient but that's okay now I'm not going to claim that the system is perfect or optimal it does work but I'm sure some of you guys have seen areas where it can be improved and I encourage you to include some of those improvements in any of your data links so the last layer is our physical layer we have to get these scalpel packets from the sender to the receiver it was important for me that this data link protocol work with different physical layers our primary physical layer is the XP Pro 900 HP radio this is a 900 mahz radio link and I might switch this to the rfd900 soon but they both function very similarly but importantly this data could be sent over any physical medium I mean your rocket could even have a huge speaker and then just scream bites to the microphone on your laptop if you really wanted to now I don't recommend this but in theory everything would function the same way because the upper layers don't actually care what the lower layer does to get the information from point A to point B as long as it gets there now when these packets are sent over something like an XP or an rfd900 they aren't really asynchronous the XP does its own extra error detection and probably correction and it also packe tizes everything into discret packets so this whole scalpel process is probably unnecessary if you aren't going to rely on multiple different physical layers and you're just going to do a radio you can probably NYX the entire transport protocol layer so that's it that's the whole data link we've gone through all three layers and talked about what each one does I'm hoping this video is a useful resource for you guys when you're making your own projects and please let me know if you've come up with any better systems that I might Implement in future iterations of this link so we've got more cool rocket launchers coming up and I'm also working on a modeling and simulation video as the next iteration in the diamond de build Series so thanks everybody for hanging out and I'll see you in the next one

Channel: Lafayette Systems

Views: 51,968

Keywords:

Id: 2o6qZ-UWxr8

Length: 13min 55sec (835 seconds)

Published: Sat May 11 2024