So with the ~10000:1 software:hardware post ratio lately, I thought it would be nice to get some programming here… So what do you guys think the hardest bit of programming you will do this season? Mine is the inertial navigation that I almost got to last season (this season I would use it for better autonomous and auto aiming maybe) and the pi loop for a scissor/reverse xbar/x bar lift
Mine will be creating over 20 autons’ and having a way to switch between them.
Right now im working on a robot control interface on android using an HC-05, soon ill be able to choose/create autons, read sensors, battery, etc from a phone
Why do you need so many? The most I can think of is 8… One for each square and one for hanging in each square
This would be super cool
Hardest challenge for coding…
Making an auton that has collision avoidance for other stars being shot a my robot, shoots lasers, and hangs!
My VEXU team GOAT probably did about 2 hours of software time for every hour of hardware time. We chose to do all of the programming in ROBOTC for the cortex and never ran out of stuff to implement to increase our robots performance.
I was really close to finishing the transport protocol and then my HC-05 broke
heres the protocol if anyone is interested:
the main goal of this protocol is reliability
4 byte magic header ] 4 byte checksum ] 2 byte chunk length ] 4 byte packet ID ] 1 byte chunk number ] chunk data ] 4 bytes of zeroes ]
the magic header is just static sync bytes \x65\x96\xBE\xB8
checksum is a simple xorshift hash of everything besides the header and trailing zeroes, i diddnt want to waste my flash space with a huge crc32 table
packets can be split into chunks up to 65,535 bytes large, with a max of 256 chunks per packet so 16,776,960 bytes max for a packet (for comparison, the cortex has 64k of memory and 384k of flash)
the zeroes on the end are just encase some bytes get skipped so it has less of a chance to put it out of sync with the next packet
the chunk numbers are reversed so that 0 is the last packet, for example with a 3 chunk packet you would go from 2 to 1 to 0. once chunk 0 is received the packet is assumed to be finalized and gets processed
i was also thinking of using parity on the chunk length so if it gets corrupted it wont clobber the next 65536 bytes or so
Well, if I were to explain, I would reveal our robot… So here’s a brief explaination: We have 2 interchangeable parts, so 10 autons per part. So 10 autons depending on who our opponent, or ally is.
AH I’m scared of trying to read that again good luck! Anywho I thought of another project: making a drive assist program, the robot sees the driver is going after a star or cube and then it goes into autonomous mode to shoot the star with maximum efficiency, disengaged at the secondary drivers command…
In NbN i had a test robot that would automatically aim when you pressed a button using the robot’s
position and angle.
Position tracking will be slightly easier due to less robot interaction
but there is an issue with line tracking, in this game you only get 2 lines on the same axis so drift on the other axis cant be corrected with line sensors
we will have to figure out a way to correct that perhaps with ultrasonic sensors
link to my position tracking thread if you havent seen it before: https://vexforum.com/t/robot-position-calculation/29551/1
soon ill be updating it with the line sensor stuff i did a few months ago
now that i think of it, it might be possible to use line sensors on starting tiles to correct drift on the other axis
i dont have a field so if anyone can provide line sensor data on colored tiles / gray tiles / lines in different conditions it would help a lot
@PixelToast how would you transmit data in and out of the cortex? Piggybacking off of the key? IIRC, the cortex doesn’t have data transmit abilities (that can be controlled with ROBOTC, at least)
Chip is like 8$ on amazon.
Why don’t you just use a switch statement and use the LCD to select a number that would correspond to one of the auto cases in the switch statement beforehand?
@PixelToast But only usable during practice, of course, due to VEX’s (rather lame) rules about transmitting data off of the robot during competition.
well obviously you would pull it off before the match xD
It would be nice if the robot could broadcast info but not receive, but even if it did recieve, it wouldn’t give the robot that much advantage right?
@OverlyOptimisticProgramer I see the point in banning transmitting data into the robot, but banning transmitting data out seems like it’s preventing some innovation (even though it would likely give some teams a unfair advantage, and they might not want to open that can if worms)
I’m pretty sure that rule is in place because anything operating near 2.4 GHz wirelessly, which includes most Wi-Fi networks and Bluetooth, can disrupt the communication between VexNet keys, which operate at 2.4GHz.
My summer software projects will include:
- VexNet 2.0 support for PROS
- jinX: The ultimate PROS robot debugger (More details to come on that later. Though some of you who spoke with us at worlds know some details from PROS team teasers ;))