When using multiple motors together for additional power/torque, it was very straightforward to bind motors using the Cortex and RobotC. What is the recommended way to do the same with VCS/V5?
The main challenge with this is turning off or syncing the PIDs from within the smart motors. It does not seem obvious on how manage the internal PID
As @sazrocks noted (in some thread I don’t have handy right now), only PROS seems to publicize an API for managing smart motor PID. He found that VCS C++ appears to have a relevant function call, but it is not documented anywhere.
I found the function call for voltage control and managed to get it working in the beta build of VCS, but some changes were made for the release version that I haven’t figured out yet. I may or may not end up working it out, as jpearman said that he is planning on adding it properly to a incoming version of VCS. For now, if you absolutely need voltage control and are willing to use the beta version of VCS, PM me for instructions.
Next VCS will have updated SDK with spin method that will take voltage as units.
The functionality is there for all development solutions. VCS, PROS and everything else is written on top of the same underlying SDK with the only differences being how multi tasking and events work (PROS for example is FreeRTOS based, VCS uses a corporative scheduler). The beta version of VCS still included some private functionality we removed from the release version as it was still subject to change.
@jpearman what is the ETA for the new VCS release that supports this (and a bunch if other things as I understand it)? You have previously said October, so I was wondering if that holds. In addition to the direct motor control, one of my teams is looking for file management as they are sponsored by Axosoft, the maker of GitKraken.
If it is slipping longer, I need to cut the cord and move them to PROS or RobotMesh.
I doubt you will ever be able to use Git and GitKraken to anywhere near their fullest potential with anything but PROS.
I’m not directly involved with VCS UI development, but even if the VCS team has another release this month that includes multi-file capability, I’m not expecting it to play well with a version control system such as git. I’m also not sure that RobotMesh Studio, being primarily a cloud based environment, would work that well either, but perhaps @Rick TYler could comment more about that.
So if using GitKraken is a priority I would move over to PROS now as it’s going to be a better fit for you.
The direct motor control we could solve with an interim solution if necessary, the functionality is there but exists as a C API, if we had to implement something earlier than an official VCS release the best plan would be to sub class vex::motor and add the additional method that will be in the next release.
@jpearman if you can walk me through how to support with the current VCS, I would appreciate it. I’d like to keep all the teams on the same system as they have different levels of sophistication and not everyone is ready for PROS. Plus we have always found the real-time debugger to be invaluable and am looking forward to having that. My Axosoft sponsored team can focus on using the project management software instead of GitKraken, although I do think source code management/version control is a very important skill to teach at this level.
I actually really like GitKraken and recommend it all the time.
To the best of my knowledge (JPearman can correct me) even if they add multiple file support the very nature of making a zip file from the project folder will make version control futile. (it’s not actually a zip file just equivalent)
If you want to install the software notVcs someone released recently and make students always have to run notVcs before pushing or after pulling new code it could work. Cumbersome obviously but possible.
Really I would suggest switching to PROS and having those students join the Vex discord so they get immediate help and support as needed.
That’s one thing I’m teaching my students this year - PROS and I’m adding a gitserver to our internal scouting network so that we always have our code.