Hello,
How much controll is it possible to get over the radio modem link? Is it possible to modify the code that constructs the packets? What about sending arbitrarary data through the link? Will that break the OI, or will it just ignore it?
EDIT: I just noticed that I can’t spell Control.
Interesting question.
I worked on a project that decoded packets last year.
You can decode the packets coming out of the OI using a guide available from either FIRST or IFI (I can find it if you need it.) I’m kind of confused about your question… Are you trying to push packets to the robot controller? And if that is the question, using what? According to the robot rules, a computer can not be used to provide input to the robot in any way, only to use the dashboard port to provide the driver with data.
I just need some more information about what you are trying to do, and I will do my best to help you. You can also PM me if you want to explain the whole project, and we can go back and forth easily about trivial things.
Might be of some help (doubtful),
Jacob
None. Consider the OI/modem/RC connection to be an inscrutable black box. You can eavesdrop on the actual packets going both ways, but you have no way to change how the link is established or what format the data is in. The communication with the modem is absolutely, completely proprietary. IFI does not provide a way to do anything other than what the system is designed by them to do. Anyone who does have the ability to figure out what’s going on should not try to subvert the system even if they could.
I’ve done some work on reverse engineering the system, not much, I basically determined unless you have a very well working knowledge of the systems involved, the safeties in the system are pretty impenetrable. You do have control over the dashboard packet, which is spit out of the OIs Dashboard port, but its for information return only.
Sorry. I guess I didn’t make myself clear. Basically, what we want to do is transmit arbitrary bytes from the robot, through the radio link, and out the dashboard port. However, we want to do it on an interrupt basis rather than a loop basis, or as close to an interrupt basis as possible (maybe from the fast user code?). Are the packets sent to the OI constructed by the master uP? Can we hack it to send our own byte stream? If we add stuff to the txdata typedef, tx_data_record, can we trick the master uP into sending it? Or would it just balk? What feilds of that structure are “safe” to set to send arbitrary data? If we made our own structure of the same size, what bytes could we use?
I’m pretty sure that just changing txdata wouldn’t do anything, and it’s not a good idea to do this for competition purposes anyway. There are a few “user bytes” whose values are sent to the dashboard, which you could use to communicate with it, or you could store values in unused pwm outputs, which are also sent to the dashboard.
How legal is dissassembling the firmware and patching in our own code? That might let us send a bytestream, but is that legal/possible?
Its possible to flash the master processor with your own data structure code however you will be disabled the entire match.
Why? Is it part of the rules, or is ti just because the code you flash in dosen’t enable the robot like the normal firmware does?
For use on a competition robot, messing with the master code is 100% absolutely not legal. It’s also not really possible without inside information.
If all you want to do is get back arbitrary bytes from the robot, the existing data stream gives you six “user bytes” for exactly that purpose. You’re still restricted to the predefined transmission rate of ~40 packets per second, which I believe is actually maintained by the OI software – which you have absolutely no control over.
You can use PWM outputs and OI LED outputs and user bytes to send stuff out of the dashboard port.
Take a look at the list of bytes that can be read from the Dashboard port, and see which ones you have control over.
Jacob