Just wondering when the Raptor base code is likely to be available? Can't wait to start playing with it (assuming I qualify to enter the Raptor Class :-) ).
Raptor class code - still needs more time in the oven
I am not sure, it is not quite ready yet, a bit too unstable still :)
The good news is that it will be fairly similar to the Monster class base code for this season. This means that while the telemetry will be accessible to the code it will still be largely dependant on the camera. Hopefully this will make the transition to the Raptor class a bit less of a jump, but still allow lots of room for teams to make use of the technology as they see fit.
The bad news is that it is unlikely we will have a simulator for the Raptor class ready in time. This has proven much more of a task than expected, our first attempt does not match the robots well enough to be useful and is still lacking any of the telemetry feedback for testing with. As such the simulator would likely be more of a hindrance than a help.
We might upload the prototype code as it stands next week so that the teams can see what is different so far, but if we do expect a fair number of changes before testing begins ;)
I think we will put the telemetry calls into the RaceCodeFunctions.py script, but at the moment we are directly talking to the Raptor library to read them.
The Rator robots are fairly easy to crash, flipping is a bit harder but can be done against the walls at speed. As you say once flipped there is nothing you can do to get the robot going again. If you do just collide with the wall it should be possible to reverse a short distance and drive away again.
Having said that you can see much more of the track, so robot detection should be easier:
These are the functions that are in the library at the moment:
ResetEncoder()
Set the encoder position back to zero
position = GetEncoderPosition()
Gets the current encoder position in counts
This can be converted to an easier to understand value with constants for a
distance or number of rotations, e.g.
metersTravelled = GetEncoderPosition() / float(countsPerMeter)
rotations = GetEncoderPosition() / float(countsPerRotation)
degrees = (GetEncoderPosition() * 360.0) / float(countsPerRotation)
We have not calculated those conversions yet.
velocity = GetEncoderVelocity()
Gets the current encoder velocity in counts per second
The velocity is sampled five times per second, so a minimum rate of five counts per second is needed to register
The maximum rate is just above 160 KHz, beyond this the velocity will register as overflowed
This can be converted to an easier to understand value with constants for a
speed or number of rotations per second, e.g.
metersTravelledPerSecond = GetEncoderVelocity() / float(countsPerMeter)
rotationsPerSecond = GetEncoderVelocity() / float(countsPerRotation)
degreesPerSecond = (GetEncoderVelocity() * 360.0) / float(countsPerRotation)
The latest running code is at about 500 Hz. Again we have not calculated those conversions yet.
x, y, z = GetPozyxLocation()
Gets the current location reported by the Pozyx board in mm.
This is relative to the board's assigned locations for the anchors.
In our race code case z is unused / fixed, x, y of 0, 0 will be to the far left of the track diagram. This means they should be positive values at any position on the track.
The starting position for the center lane is approximately 5870, 1265.
heading, roll, pitch = GetPozyxOrientation()
Gets the current orientation in heading (yaw), pitch, and roll reported by the Pozyx board in degrees.
From our testing so far the heading value does seem to drift, but roll and pitch are fairly stable.
x, y, z = GetPozyxLinearAcceleration()
Gets the current acceleration in the X, Y, and Z directions reported by the Pozyx board in mg.
This is based on all of the available sensors in the board and removes the gravity component.
Is there just a single encoder? Which wheel(s) are they on?
Am I right in assuming front wheels steer with a servo control and rear wheel drive via a differential or is it a fixed drive axle?
I am not sure, it is not quite ready yet, a bit too unstable still :)
The good news is that it will be fairly similar to the Monster class base code for this season. This means that while the telemetry will be accessible to the code it will still be largely dependant on the camera. Hopefully this will make the transition to the Raptor class a bit less of a jump, but still allow lots of room for teams to make use of the technology as they see fit.
The bad news is that it is unlikely we will have a simulator for the Raptor class ready in time. This has proven much more of a task than expected, our first attempt does not match the robots well enough to be useful and is still lacking any of the telemetry feedback for testing with. As such the simulator would likely be more of a hindrance than a help.
We might upload the prototype code as it stands next week so that the teams can see what is different so far, but if we do expect a fair number of changes before testing begins ;)
Cheers Arron, it would be good to see the format of the telemetry data. Its going to be a chaos filled season I think!
How easy are the Raptors to flip if crashed - I assume they can't be self-righted once flipped!
I think we will put the telemetry calls into the
RaceCodeFunctions.py
script, but at the moment we are directly talking to the Raptor library to read them.The Rator robots are fairly easy to crash, flipping is a bit harder but can be done against the walls at speed. As you say once flipped there is nothing you can do to get the robot going again. If you do just collide with the wall it should be possible to reverse a short distance and drive away again.
Having said that you can see much more of the track, so robot detection should be easier:
These are the functions that are in the library at the moment:
We have not calculated those conversions yet.
The latest running code is at about 500 Hz. Again we have not calculated those conversions yet.
In our race code case
z
is unused / fixed,x, y
of0, 0
will be to the far left of the track diagram. This means they should be positive values at any position on the track.The starting position for the center lane is approximately
5870, 1265
.From our testing so far the heading value does seem to drift, but roll and pitch are fairly stable.
Thanks Arron,
Just to confirm, the (0,0) position is the bottom left corner of the track layouts here: https://www.formulapi.com/track-1/layout
What would the top right corner co-ordinates be?
Thanks
Yes, the 0,0 point is in the bottom left, a bit past the extremes of the track wall in both dimensions.
The top right extreme is at 10580, 7030, which is also a bit past the extremes of the track wall in both dimensions.
We have six Pozyx anchors for triangulation mounted to the larger white walls outside the track at these locations:
Is there just a single encoder? Which wheel(s) are they on?
Am I right in assuming front wheels steer with a servo control and rear wheel drive via a differential or is it a fixed drive axle?
Thanks
It is a single encoder attached to the drive shaft, so it is essentially measuring motor speed.
The front wheels are steered by a servo, all four wheels are driven with front and rear differentials.
Add new comment