I’m going to push out a slightly simplified version of my lift PID controller in the next couple of days. In the meantime, here is a short link showing how I stream debug values and use them in a live graph to evaluate how the PID loop is performing.
1 Like
This looks really cool. Will it be available only via ConVex or is this something that could work with RobotC, etc. also?
1 Like
The PID and motion profile code is only being released for ConVEX, however, it’s pretty vanilla C code so should be possible to port to ROBOTC. I use a pretty fast loop time (5mS), ROBOTC may not be able to do all the math fast enough at that speed. A port to PROS would be trivial. I’m pushing the code out so others can get some idea of what’s involved in implementing PID a little beyond what we have shown before.
I’m not planning on releasing the GUI that I use for tuning and analysis, that will be part of the discussion on the best way to find the PID constants.
1 Like
I like it, very crisp and easily understood!
I am curious though, are you directly tethered to the Cortex when receiving that data? Ever since VEXNet 2.0 released we’ve noticed some sudden drops when shipping out large amounts over the debug stream.
1 Like
Like what I said about BNS library, PID constant library!!!
I think a convenient way would be writing a powerful robotc program that writes debug stream in CSV format neatly. But I look forward to real time graphic features being added to robotc.
The video is awesome. Looks very neat. The PID loop is extremely well tuned… man I want one for my lift…
1 Like
Yes, USB A-A cable between cortex and joystick. Programming kit used between joystick and PC.
When Vexnet 2.0 was first released I did some benchmarking to check performance. I need to repeat the tests sometime but the original test suggested that Vexnet 2.0 was significantly slower to transfer data from cortex to PC and slightly faster when going from PC to cortex.
V1.0
Upload (cortex->PC) 2557 bytes/sec
download (PC->cortex) 2549 bytes/sec
V2.0
Upload (cortex->PC) 1091 bytes/sec
download (PC->cortex) 3097 bytes/sec
(these were measured using firmware transfer software, ie. uploading and downloading programs to the cortex flash).
The firmware has changed since then and performance may have improved, however, the slower upload speed really affects the ability to debug reliably. With software that uses the debug serial port to send information in the way I am in the video, sending too much data from the cortex will actually crash the joystick.
1 Like
This looks very cool. I’m actually in the process of developing a system that will have some similar capabilities. It will use the joystick serial port to relay information between the cortex and a PC/Mac application (GUI application written using Java and JavaFX). I’m aiming for the application to have a lot of commonly needed functionality, such as competition control, realtime PID controller graphing (using custom C++ PID libraries I’ve written), motor control (similar to the EasyC online window without having to download firmware), ChibiOS thread monitoring, sensor value monitoring, etc.
One issue I’m running into is the shear quantity of data that all of this entails. Obviously, interoperability is paramount here. Endianness and floating-point formats make it difficult to transfer raw data. Because of this, I’ve started looking at data serialization formats.
Do you have any suggestions on how to manage the amount of data I’m going to be transferring while maintaining an easily readable format? Also, I haven’t had the joystick crash before. Are there any software warning signs that could prevent this from happening?
1 Like
I will give you a more comprehensive answer over the weekend, however, ChibiOS thread monitoring? Does that mean you are using ConVEX?
1 Like
Yep! Sorry, I should have made that clear. By thread monitoring I mean an automatically updating view with information similar to that provided by the “threads” command in the ConVEX shell.
Thanks!
I just tried the USB A-A cable and joystick programming trick.
Where have you been all my life?! :o
I am very frustrated by the constant failure reading brick status messages in robot C debugging as well as garbled debug stream data. The USB-USB cable worked like magic!
I will have to post some pictures and buy some longer USB male to male cables to have for testing when the robot actually moves a distance.
I assume you have read the posts in the ConVEX thread from the Dec 2013 timeframe, a student was working on a similar application as you are now and had several questions. One post in particular is worth reading.
https://vexforum.com/showpost.php?p=341337&postcount=108
In terms of endianess, pick one and translate as necessary. Data on, for example, ethernet uses big endian, we have to often use small functions ntohs and htons (network to host short, and host to network short)etc. to translate between the internal data format and the network byte order. Floats should be compatible, only byte order is important.
You can update different types of data at different rates, motor values perhaps quickly, task status more slowly.
I really would turn the model around and have you java application request data from the cortex rather than just constantly pushing it out, it gives much more flexibility, only ask for data when it is being displayed and at a rate that’s appropriate for the GUI.
1 Like
I’m surprised you didn’t know this. I nearly always use the USB A-A cable when programming, it also powers the joystick as an added bonus.
Yea, the ROBOTC guys had to increase timeouts and reduce data rate just to make it work. I need to dig into this some more now the firmware has stabilized, I really hope we don’t have another April firmware update scramble this year.
1 Like
The only reason I’ve started using the A-A cable is because large arrays don’t play nicely with the wireless downloading 
I just ordered a 15’ USB A to A cable. See how that goes for tangled up robots before I get one for each team. 3-4 teams on the field with each one tethered may not be a good sight. I had one team seem to get the brick status 80% of the time from their old ancient laptop. Ours was at least usable.
[OPRAH_VOICE]
You get a cable!
You get a cable!
Everybody gets a new USB cable!
[/OPRAH_VOICE]
1 Like
Thanks for sharing @jpearman, I’m interested in knowing how you linked the data from the Cortex to the PC to make a graph of realtime data. Do you just read read the info sent from the cortex through the serial port of the PC with the programming hardware kit and make a GUI that reads this info from the serial port and what specific parameters do you have to set to read it? (Baud rate, parity,etc).
1 Like
The cortex sends the relevant data 40 times/second through the programming kit connected to the joystick. The PC reads that data, parses it and draws the graph. The serial port speed is 115.2k bits/second. Occasionally a message is dropped but that doesn’t really matter in this application.
1 Like
Since you are using Convex, would the Writedebugstream routine in RobotC send the info directly to the PC Serial port (I know it does, but do you know if the data is encoded in some format so RobotC can read it or is directly parsed to the debugstream window in RobotC), because my intention is to read the data from the serial port and graph it in an easy way through Labview.
writedebugstream buffers the information in the cortex. The ROBOTC debugger has to send a special message to be able to read the data, however, perhaps the trick I described in this post would work for you.
https://vexforum.com/showpost.php?p=319321&postcount=125
Create a way to turn that on and off (use a jumper or similar) otherwise you may loose control and have to re-download the robotc firmware.
1 Like
Alright thanks a lot for the very useful information!