Suggestion: Make Wireless Downloading Available NOW

VEX V5 General Discussion
1

Okay, okay, I know this was a little bit harsh to make a scary title, but I generally believe that wireless downloading really should be available by now. There is so many benefits with V5 having the capability to wirelessly download. First of all, you do not have to constantly reach down and move your hand through some pieces of metal to download code if you’re the unlucky one having to do such a thing. With wireless downloading, we don’t have to make our hands vulnerable to things we should not be in, as well as it means that we have the simplicity and convenience of wireless downloading from the controller. Another note is that many people have been breaking their micro USB ports on the V5 brain, in which they have to contact VEX support and VEX has to sends a new V5 brain and system. This definitely means that VEX would lose money, and is not good for both us having to wait for a new V5 brain as well as VEX for having to supply a new system that another consumer could’ve had. Because we all make mistakes, having such a vulnerable port be the only port to download code onto the Brain is very dangerous. If your robot automatically runs its code because of a download(such as with PROS and other programming languages) and because the motors are 2.5x powerful, the drivetrain could move and pull the plug, the lift could lower onto the plug, etc. and damage the programming port very easily. By having wireless downloading be available as soon as heavenly possible would mean there would be less damage, a backup programming port just in case, as well as the elegance and ease of simply plugging into the controller. Teams would damage the V5 system far less because there is no external moving parts that would damage the V5 joystick, as well as it is less of a hassle. I have realized that this mess with Micro USB ports breaking is getting very severe, and the fact that the promise of wireless downloading in December not being held is simply making the V5 crisis even worse.
Thank you all for spending your time reading, I hope to keep this discussion civil…

  • Connor, 1814D
2

I mean, obviously this should be a thing. but it isn’t likely that vex will prioritize this.

3

Can someone start a petition?

4

Vex doesn’t respond to petitions- a bunch of EPs and coaches would have to make a fuss before anything would happen. And even so, actually getting v5s shipped would take priority.

I’d love to have this feature ASAP but I doubt its coming at least before next season.

5

the work for this is already done in vexos, the initial implementation (it’s actually in 1.0.5) is with the partner development teams at RobotMesh, PROS and VCS. I would expect to see PROS and RobotMesh release soon, I will check in with them to see how they are progressing.

6

For the past few releases of PROS, the default behavior has been to show the run screen after uploading - not start the program automatically. I’m fairly certain all the programming environments do that for the reason you mentioned.

PROS will also have issues with wireless downloads as a current program sizes take too long to upload. I’ve been prioritizing making a reliable solution that consistently keeps upload times short (specifically pre-loading the PROS kernel and libraries such as okapilib once on the brain and just uploading code you write). That’s not really keeping wireless downloading from being released as a whole but I wanted to give some PROS insight to the situation.

7

to elaborate on this
a typical PROS program is 400k bytes. We support compressed binaries in the latest vexos and this should allow a PROS program to be compressed to perhaps 200k bytes.
Wireless download will be somewhere around 6k bytes per second (the cortex was about 3.2k) so it will be a 30 to 40 second download. This is addition to the time needed to switch to a download channel.

VCS programs are typically much smaller as we have much of the support library code embedded in vexos, most will be < 20k. However, VCS support for wireless will not happen until VCS is updated and, as I’ve said in other threads, that’s under control of the VCS team who currently have other priorities.

8

Is the VCS team doing a significant re-factor or re-design to address notable issues with the VCS Application? That’s the only thing I can highlight that would make sense to me as to why they’re taking forever with it.

9

almost certainly not

10

Probably a stupid question, but would it be possible to utilize bluetooth for its greater bandwidth to decrease download times? Since most programming is done outside of competition I don’t see why switching to bluetooth for pragramming would cause any problems, assuming that bluetooth works for that.

11

It’s Bluetooth Low energy.
wireless throughout via the controller when switched to BTLE is about 10% slower than VEXnet. That’s pretty typical according to the link below (and I have no idea of this analysis is accurate, just one of the first to come up when I searched)

12

Would a download over a wired connection from the brain to controller be faster? In case someone has their brain mounted in an inconvenient position to reach the usb port but a smart port is easily accessible.

And I know setting text wirelessly on the controller is slow, is there any chance for getting terminal data wirelessly someday so we can print to and read the console without being tethered to the brain? (Talking PROS here).

13

Such a range of emotions…

Yes! Emphatic.

Yay! Happy.

No! Sad.

14

@edjubuh, @jpearman did you consider using a library variant derived from rsync algorithm to reduce upload times?

I used one of such variants a long time ago to push large configuration updates over slow serial connection and it did magik to reduce transfer times. The trick to upload binary files is to have a variant that is aware of the word size for your address offsets .

For example, your libraries and a lot of the user code mostly stays the same between consecutive downloads, but a lot of offsets pointing from user code into the library code segment and into the shared data segment slightly shift. If your rsync algorithm is aware of this and encodes offsets in a separate channel then you could get tremendous time savings even before you apply any general purpose compression algorithm.

But this is, obviously, not something that could be quickly implemented and tested. It could be a long term strategy if VexNet speed limit is here to stay. If you want I could dig through my archives and see if I still have some of that code.

@[TVA]Connor, the short term strategy is still to use either Magnetic MicroUSB connector or USB extension pig tail as was discussed in these threads:

https://vexforum.com/t/micro-usb-port-broke/50635/1

https://vexforum.com/t/broken-v5-brain-coding-port/51232/1

I could get magnetic data cables for $2 shipped to my mailbox (although it takes few weeks). When I heard that V5 had micro usb ports, but no wireless downloads, the first thing I did was to order a bunch of those and then give to any of our teams that started programming V5 back in November.

It, probably, costs VEX no less than $200 and valuable human resource to RMA each V5 that has a broken micro usb port. Even if the failure rate is just 1 in 100 it is still cheaper to contract somebody to send a free magnetic connector to every team that bought V5. But I think that with middle schoolers plugging it in very hard to reach places multiple times a day, the failure rate will skyrocket as we get close to the end of the season, when everybody will try to get at least the basic autonomous to work.

If the inherent technical problem with slow VexNet download rate was known from the very beginning, and it was clear that making software workarounds and test them would take months, then why didn’t VEX Robotics issued an alert on Micro USB concerns similar to their Anti-Static notice?

That could not only save money for VEX, but would avoid a lot of student and mentor frustration as more and more V5 units start breaking close to the States. Seriously, regardless if wireless download will be available in the next couple of weeks or not, I think everyone should get one of those port saving solutions now, because micro usb port on the V5 controller is also fragile and not designed for the unlimited number of cable insertions.

15

The solution we’re moving forwards with is to create a “cold” image that contains all of the PROS, okapilib (and other libraries) and as much of libstdc++/libc that gets uploaded once. We’ll compile your code against this cold image and just upload the user code in most situations. The “cold” image is currently sitting at about 500 KB. When linked this way, the default user program that comes you get when you create a new PROS project is at 1KB and the okapilib clawbot demo was no more than 3KB. Uploading these “hot” images takes less than a second wirelessly at today’s speeds (not counting overhead to transfer to download channel).

Anyway, PROS takes a bit more work than other platforms since we have a much wider array of versions to be dealing with - there’s the PROS kernel version, okapilib version, GCC toolchain version, plus any additional libraries you may include. Other platforms have just one version to check against since they have more control: no libraries and a specifically bundled toolchain.

16

Yep, that could be considered a very special case of the rsync algorithm, with the hash value of the pre-existing chunk being the version number and type of your “cold” image. :slight_smile:

17

Thank you, James. Robot Mesh is working on our wireless download now, and will be done soon.

(In the software world, “soon” is anything from a couple of weeks to a year. Sorry I can’t be more specific, but, as I wrote above, the dev team is working on it now.)

1 Like
18

So did we find out by what date wireless downloading will be available on PROS?

19

maybe if they add something for wireless download I might be able to finally finish notvcs

20

We don’t have a fixed date, but we’re currently going through

(https://github.com/purduesigbots/pros/pull/89) [reviews](https://github.com/purduesigbots/pros-cli/pull/46) [for](https://github.com/purduesigbots/pros-cli/pull/47) [everything](https://github.com/purduesigbots/pros-cli/pull/48) we need for wireless upload.