EvolvedAwesome
commented
5 years ago Kia Ora,
So I wrote this some years back now as the first stage framework for a programme that I eventually adapted into a robot web server. The idea was, that I could control my robot from any point in the school as long as the area had wifi (so, basically everywhere) - and I could stream live data such as sensor readings, a camera and motor information at any point by expanding the basic featureset documented in commands.c.
This project was never competed, basically because it was impossible for me to get ahold of a cortex and robot at any point for a long enough period to test and work on this, without impacting our teams competitive robotics. However, on a technical level I completed all the code needed and tested individual components successfully. I never choose to upload it because a) it was never tested/finished as a whole and b) it was a very implementation specific adaption of the library.
Furthermore, when I wrote this I was in approx. 8th grade and I was still figuring out exactly what all the device components did. It could do with some code reformatting and file structure changes at a minimum.
This obviously was also only written for V4 Cortex, not for the V5 system. The V5 system IIRC comes with a programming interface of sorts that would allow you to actually download programme binaries to the V5 via the usb port (from a RasPi).
For what you are trying to do, you have a few options. I have never played around with micro:bit, but I would imagine you intend to leverage code written for it, parse it and then send commands to the cortex based on what is in the code? This places the computational difficulty of parsing and interpreting it on the RasPi side (which is a good thing) and also means that you never have to actually change the code running on the cortex - as it would always be interpreting what is sent to in an RTOS fashion. I have never tested the latency or dropped packets using the UART port for this purpose, however I don't imagine you will have any particular issues there. The only issue there is that you are not really programming the cortex, you are simply telling it what to do from a serial interface.
If you wanted to programme the cortex, there is a couple of options. You could explore some of the projects to decompose the vex wireless programming interface and write your own binaries directly to the cortex, though this carries some risks of breaking things and is more a solution I would be happy with if you knew the exact contents of the compiled binaries before uploading them. You could also upload the entire programs actions as a simplified bytecode and then save them to the flash of the robot. This would allow you to persistently 'program' the cortex between cortex reboots, although again you would not be actually changing the program onboard (hopefully!).
Best of luck, and feel free to ask any questions if they arise. I remember this project quite well and I have been meaning to finish it for some time.
Hi John,
I am looking at your VEX Serial implementation, and thinking of adapting it.
I want students to be able to program a vex robot (with sensor readings) in python via an onboard raspberry pi. They will be programming other robots with Python on Micro:Bits and raspberry pis. So, this implementation would simply be another progression possibility.
Seeing as you haven't put anymore work on github, I can only assume you abandoned the project. Was there any specific reason for this?
Thanks for any guidance you can provide.