Files
allwpilib/wpilibc/src/main/native/cpp/simulation/DriverStationSim.cpp

270 lines
8.4 KiB
C++
Raw Normal View History

// Copyright (c) FIRST and other WPILib contributors.
// Open Source Software; you can modify and/or share it under the terms of
// the WPILib BSD license file in the root directory of this project.
#include "frc/simulation/DriverStationSim.h"
#include <memory>
[hal, wpilib] New DS thread model and implementation (#3787) The current DS thread model has some pretty major issues. It makes it difficult to know if all data is from the same remote packet, and if the data changes while the robot loop is running. Additionally, the DS thread is used for a few other things (MotorSafety and State Tracking for EducationalRobot). This also makes sim difficult, as user code has to wait for the thread to know it has new data. This change completely rethinks how threading works in the driver station model. First, the DS HAL system receives a new data callback, either from Netcomm or DriverStationSim. Inside the context of this callback, all the low latency data is read and put into a cache. Doing some investigation on the robot side, this is perfectly safe to do, and also ensures a ds packet will not be parsed before we finish reading the current packet data. After all data is read, the cache is swapped with a 2nd buffer. This buffer just stores the data, none of the HAL DS calls read from this buffer. An event is then fired, stating there is new data ready to go. Robot code calls HAL_UpdateDSData(). This swaps the 2nd buffer with a 3rd buffer, which always contains the current data. This data will not be updated until HAL_UpdateDSData is called again. Which solves the state problem. The high level driver station classes have. an updateData() call, which calls HAL_UpdateDSData, and then update button state variables, then data log and update the NT FMS data table (Java also caches across the JNI boundary here, but that could trivially be removed). An extra event provider is provided, allowing other threads to know when this call has been completed. IterativeRobotBase calls DS.updateData() at the beginning of each loop, and only once per loop. This means all commands will always have the same state. All of this means there is no longer a DS thread. Everything happens synchronously. This means Sim and testing is easier, as you can just call DriverStationSim.NotifyNewData(), and then DriverStation.UpdateData(), and you can guarantee that all the DriverStation.*** data is up to date. As for Motor Safety and Educational Robot State Handling, those can all be handled by their own threads. The Educational Thread only needs to run under EducationalRobot, and MotorSafety will only be started if there is a motor safety object enabled.
2022-10-21 22:01:55 -07:00
#include <hal/DriverStation.h>
#include <hal/simulation/DriverStationData.h>
#include <hal/simulation/MockHooks.h>
#include "frc/DriverStation.h"
using namespace frc;
using namespace frc::sim;
std::unique_ptr<CallbackStore> DriverStationSim::RegisterEnabledCallback(
NotifyCallback callback, bool initialNotify) {
auto store = std::make_unique<CallbackStore>(
-1, callback, &HALSIM_CancelDriverStationEnabledCallback);
store->SetUid(HALSIM_RegisterDriverStationEnabledCallback(
&CallbackStoreThunk, store.get(), initialNotify));
return store;
}
bool DriverStationSim::GetEnabled() {
return HALSIM_GetDriverStationEnabled();
}
void DriverStationSim::SetEnabled(bool enabled) {
HALSIM_SetDriverStationEnabled(enabled);
}
std::unique_ptr<CallbackStore> DriverStationSim::RegisterAutonomousCallback(
NotifyCallback callback, bool initialNotify) {
auto store = std::make_unique<CallbackStore>(
-1, callback, &HALSIM_CancelDriverStationAutonomousCallback);
store->SetUid(HALSIM_RegisterDriverStationAutonomousCallback(
&CallbackStoreThunk, store.get(), initialNotify));
return store;
}
bool DriverStationSim::GetAutonomous() {
return HALSIM_GetDriverStationAutonomous();
}
void DriverStationSim::SetAutonomous(bool autonomous) {
HALSIM_SetDriverStationAutonomous(autonomous);
}
std::unique_ptr<CallbackStore> DriverStationSim::RegisterTestCallback(
NotifyCallback callback, bool initialNotify) {
auto store = std::make_unique<CallbackStore>(
-1, callback, &HALSIM_CancelDriverStationTestCallback);
store->SetUid(HALSIM_RegisterDriverStationTestCallback(
&CallbackStoreThunk, store.get(), initialNotify));
return store;
}
bool DriverStationSim::GetTest() {
return HALSIM_GetDriverStationTest();
}
void DriverStationSim::SetTest(bool test) {
HALSIM_SetDriverStationTest(test);
}
std::unique_ptr<CallbackStore> DriverStationSim::RegisterEStopCallback(
NotifyCallback callback, bool initialNotify) {
auto store = std::make_unique<CallbackStore>(
-1, callback, &HALSIM_CancelDriverStationEStopCallback);
store->SetUid(HALSIM_RegisterDriverStationEStopCallback(
&CallbackStoreThunk, store.get(), initialNotify));
return store;
}
bool DriverStationSim::GetEStop() {
return HALSIM_GetDriverStationEStop();
}
void DriverStationSim::SetEStop(bool eStop) {
HALSIM_SetDriverStationEStop(eStop);
}
std::unique_ptr<CallbackStore> DriverStationSim::RegisterFmsAttachedCallback(
NotifyCallback callback, bool initialNotify) {
auto store = std::make_unique<CallbackStore>(
-1, callback, &HALSIM_CancelDriverStationFmsAttachedCallback);
store->SetUid(HALSIM_RegisterDriverStationFmsAttachedCallback(
&CallbackStoreThunk, store.get(), initialNotify));
return store;
}
bool DriverStationSim::GetFmsAttached() {
return HALSIM_GetDriverStationFmsAttached();
}
void DriverStationSim::SetFmsAttached(bool fmsAttached) {
HALSIM_SetDriverStationFmsAttached(fmsAttached);
}
std::unique_ptr<CallbackStore> DriverStationSim::RegisterDsAttachedCallback(
NotifyCallback callback, bool initialNotify) {
auto store = std::make_unique<CallbackStore>(
-1, callback, &HALSIM_CancelDriverStationDsAttachedCallback);
store->SetUid(HALSIM_RegisterDriverStationDsAttachedCallback(
&CallbackStoreThunk, store.get(), initialNotify));
return store;
}
bool DriverStationSim::GetDsAttached() {
return HALSIM_GetDriverStationDsAttached();
}
void DriverStationSim::SetDsAttached(bool dsAttached) {
HALSIM_SetDriverStationDsAttached(dsAttached);
}
std::unique_ptr<CallbackStore>
DriverStationSim::RegisterAllianceStationIdCallback(NotifyCallback callback,
bool initialNotify) {
auto store = std::make_unique<CallbackStore>(
-1, callback, &HALSIM_CancelDriverStationAllianceStationIdCallback);
store->SetUid(HALSIM_RegisterDriverStationAllianceStationIdCallback(
&CallbackStoreThunk, store.get(), initialNotify));
return store;
}
HAL_AllianceStationID DriverStationSim::GetAllianceStationId() {
return HALSIM_GetDriverStationAllianceStationId();
}
void DriverStationSim::SetAllianceStationId(
HAL_AllianceStationID allianceStationId) {
HALSIM_SetDriverStationAllianceStationId(allianceStationId);
}
std::unique_ptr<CallbackStore> DriverStationSim::RegisterMatchTimeCallback(
NotifyCallback callback, bool initialNotify) {
auto store = std::make_unique<CallbackStore>(
-1, callback, &HALSIM_CancelDriverStationMatchTimeCallback);
store->SetUid(HALSIM_RegisterDriverStationMatchTimeCallback(
&CallbackStoreThunk, store.get(), initialNotify));
return store;
}
double DriverStationSim::GetMatchTime() {
return HALSIM_GetDriverStationMatchTime();
}
void DriverStationSim::SetMatchTime(double matchTime) {
HALSIM_SetDriverStationMatchTime(matchTime);
}
void DriverStationSim::NotifyNewData() {
[hal, wpilib] New DS thread model and implementation (#3787) The current DS thread model has some pretty major issues. It makes it difficult to know if all data is from the same remote packet, and if the data changes while the robot loop is running. Additionally, the DS thread is used for a few other things (MotorSafety and State Tracking for EducationalRobot). This also makes sim difficult, as user code has to wait for the thread to know it has new data. This change completely rethinks how threading works in the driver station model. First, the DS HAL system receives a new data callback, either from Netcomm or DriverStationSim. Inside the context of this callback, all the low latency data is read and put into a cache. Doing some investigation on the robot side, this is perfectly safe to do, and also ensures a ds packet will not be parsed before we finish reading the current packet data. After all data is read, the cache is swapped with a 2nd buffer. This buffer just stores the data, none of the HAL DS calls read from this buffer. An event is then fired, stating there is new data ready to go. Robot code calls HAL_UpdateDSData(). This swaps the 2nd buffer with a 3rd buffer, which always contains the current data. This data will not be updated until HAL_UpdateDSData is called again. Which solves the state problem. The high level driver station classes have. an updateData() call, which calls HAL_UpdateDSData, and then update button state variables, then data log and update the NT FMS data table (Java also caches across the JNI boundary here, but that could trivially be removed). An extra event provider is provided, allowing other threads to know when this call has been completed. IterativeRobotBase calls DS.updateData() at the beginning of each loop, and only once per loop. This means all commands will always have the same state. All of this means there is no longer a DS thread. Everything happens synchronously. This means Sim and testing is easier, as you can just call DriverStationSim.NotifyNewData(), and then DriverStation.UpdateData(), and you can guarantee that all the DriverStation.*** data is up to date. As for Motor Safety and Educational Robot State Handling, those can all be handled by their own threads. The Educational Thread only needs to run under EducationalRobot, and MotorSafety will only be started if there is a motor safety object enabled.
2022-10-21 22:01:55 -07:00
wpi::Event waitEvent{true};
HAL_ProvideNewDataEventHandle(waitEvent.GetHandle());
HALSIM_NotifyDriverStationNewData();
[hal, wpilib] New DS thread model and implementation (#3787) The current DS thread model has some pretty major issues. It makes it difficult to know if all data is from the same remote packet, and if the data changes while the robot loop is running. Additionally, the DS thread is used for a few other things (MotorSafety and State Tracking for EducationalRobot). This also makes sim difficult, as user code has to wait for the thread to know it has new data. This change completely rethinks how threading works in the driver station model. First, the DS HAL system receives a new data callback, either from Netcomm or DriverStationSim. Inside the context of this callback, all the low latency data is read and put into a cache. Doing some investigation on the robot side, this is perfectly safe to do, and also ensures a ds packet will not be parsed before we finish reading the current packet data. After all data is read, the cache is swapped with a 2nd buffer. This buffer just stores the data, none of the HAL DS calls read from this buffer. An event is then fired, stating there is new data ready to go. Robot code calls HAL_UpdateDSData(). This swaps the 2nd buffer with a 3rd buffer, which always contains the current data. This data will not be updated until HAL_UpdateDSData is called again. Which solves the state problem. The high level driver station classes have. an updateData() call, which calls HAL_UpdateDSData, and then update button state variables, then data log and update the NT FMS data table (Java also caches across the JNI boundary here, but that could trivially be removed). An extra event provider is provided, allowing other threads to know when this call has been completed. IterativeRobotBase calls DS.updateData() at the beginning of each loop, and only once per loop. This means all commands will always have the same state. All of this means there is no longer a DS thread. Everything happens synchronously. This means Sim and testing is easier, as you can just call DriverStationSim.NotifyNewData(), and then DriverStation.UpdateData(), and you can guarantee that all the DriverStation.*** data is up to date. As for Motor Safety and Educational Robot State Handling, those can all be handled by their own threads. The Educational Thread only needs to run under EducationalRobot, and MotorSafety will only be started if there is a motor safety object enabled.
2022-10-21 22:01:55 -07:00
wpi::WaitForObject(waitEvent.GetHandle());
HAL_RemoveNewDataEventHandle(waitEvent.GetHandle());
frc::DriverStation::RefreshData();
}
void DriverStationSim::SetSendError(bool shouldSend) {
if (shouldSend) {
HALSIM_SetSendError(nullptr);
} else {
HALSIM_SetSendError([](HAL_Bool isError, int32_t errorCode,
HAL_Bool isLVCode, const char* details,
const char* location, const char* callStack,
HAL_Bool printMsg) { return 0; });
}
}
void DriverStationSim::SetSendConsoleLine(bool shouldSend) {
if (shouldSend) {
HALSIM_SetSendConsoleLine(nullptr);
} else {
HALSIM_SetSendConsoleLine([](const char* line) { return 0; });
}
}
int64_t DriverStationSim::GetJoystickOutputs(int stick) {
int64_t outputs = 0;
int32_t leftRumble;
int32_t rightRumble;
HALSIM_GetJoystickOutputs(stick, &outputs, &leftRumble, &rightRumble);
return outputs;
}
int DriverStationSim::GetJoystickRumble(int stick, int rumbleNum) {
int64_t outputs;
int32_t leftRumble = 0;
int32_t rightRumble = 0;
HALSIM_GetJoystickOutputs(stick, &outputs, &leftRumble, &rightRumble);
return rumbleNum == 0 ? leftRumble : rightRumble;
}
void DriverStationSim::SetJoystickButton(int stick, int button, bool state) {
HALSIM_SetJoystickButton(stick, button, state);
}
void DriverStationSim::SetJoystickAxis(int stick, int axis, double value) {
HALSIM_SetJoystickAxis(stick, axis, value);
}
void DriverStationSim::SetJoystickPOV(int stick, int pov, int value) {
HALSIM_SetJoystickPOV(stick, pov, value);
}
void DriverStationSim::SetJoystickButtons(int stick, uint32_t buttons) {
HALSIM_SetJoystickButtonsValue(stick, buttons);
}
void DriverStationSim::SetJoystickAxisCount(int stick, int count) {
HALSIM_SetJoystickAxisCount(stick, count);
}
void DriverStationSim::SetJoystickPOVCount(int stick, int count) {
HALSIM_SetJoystickPOVCount(stick, count);
}
void DriverStationSim::SetJoystickButtonCount(int stick, int count) {
HALSIM_SetJoystickButtonCount(stick, count);
}
void DriverStationSim::SetJoystickIsXbox(int stick, bool isXbox) {
HALSIM_SetJoystickIsXbox(stick, isXbox);
}
void DriverStationSim::SetJoystickType(int stick, int type) {
HALSIM_SetJoystickType(stick, type);
}
void DriverStationSim::SetJoystickName(int stick, std::string_view name) {
Change C APIs to a unified string implementation (#6299) Currently in the entire C API of WPILib we have ~8 different ways of handling strings. The C API actually isn't built for pure C callers (We don't actually have any of those). Instead, they're built for interop between languages like LabVIEW and C# which can talk to C API's directly. For output parameters, the choice was fairly obvious. An output struct containing a const string pointer and a length makes the most sense. Its easy to use these from most other languages, and doesn't require special null termination handling. Freeing these is also easy, as if you ever receive one of these string structures, theres just a single function call to free it. Input parameters are a bit more complex. To be used from pure C, and from LabVIEW, a null terminated string is the best in most cases. However, null terminated strings in general have a lot of downsides. Additionally, from LabVIEW there are other considerations around encoding that having a wrapper struct helps make a bit easier. From a language like C#, a wrapper struct is by far the easiest, as custom marshalling can make it trivial to marshal both UTF8 and UTF16 strings down. The final consideration is its nice to have an identical concept for both input and output. It makes the rules fairly easy to understand. WPILib will not have any APIs that manipulate a string allocated externally. This means WPI_String can be const, as across the boundary it is always const. If a WPILib API takes a const WPI_String*, WPILib will not manipulate or attempt to free that string, and that string is treated as an input. It is up to the caller to handle that memory, WPILib will never hold onto that memory longer than the call. If a WPILib API takes a WPI_String*, that string is an output. WPILib will allocate that API with WPI_AllocateString(), fill in the string, and return to the caller. When the caller is done with the string, they must free it with WPI_FreeString(). If an output struct contains a WPI_String member, that member is considered read only, and should not be explicitly freed. The caller should call the free function for that struct. If an array of WPI_Strings are returned, each individual string is considered read only, and should not be explicitly freed. The free function for that array should be called by the caller. If an input struct containing a WPI_String, or an input array of WPI_Strings is passed to WPILib, the individual strings will not be manipulated or freed by WPILib, and the caller owns and should free that memory. Callbacks also follow these rules. The most common is a callback either getting passed a const WPI_String* or a struct containing a WPI_String. In both of these cases, the callback target should consider these strings read only, and not attempt to free them or manipulate them.
2024-05-13 05:35:14 -07:00
auto str = wpi::make_string(name);
HALSIM_SetJoystickName(stick, &str);
}
void DriverStationSim::SetJoystickAxisType(int stick, int axis, int type) {
HALSIM_SetJoystickAxisType(stick, axis, type);
}
void DriverStationSim::SetGameSpecificMessage(std::string_view message) {
Change C APIs to a unified string implementation (#6299) Currently in the entire C API of WPILib we have ~8 different ways of handling strings. The C API actually isn't built for pure C callers (We don't actually have any of those). Instead, they're built for interop between languages like LabVIEW and C# which can talk to C API's directly. For output parameters, the choice was fairly obvious. An output struct containing a const string pointer and a length makes the most sense. Its easy to use these from most other languages, and doesn't require special null termination handling. Freeing these is also easy, as if you ever receive one of these string structures, theres just a single function call to free it. Input parameters are a bit more complex. To be used from pure C, and from LabVIEW, a null terminated string is the best in most cases. However, null terminated strings in general have a lot of downsides. Additionally, from LabVIEW there are other considerations around encoding that having a wrapper struct helps make a bit easier. From a language like C#, a wrapper struct is by far the easiest, as custom marshalling can make it trivial to marshal both UTF8 and UTF16 strings down. The final consideration is its nice to have an identical concept for both input and output. It makes the rules fairly easy to understand. WPILib will not have any APIs that manipulate a string allocated externally. This means WPI_String can be const, as across the boundary it is always const. If a WPILib API takes a const WPI_String*, WPILib will not manipulate or attempt to free that string, and that string is treated as an input. It is up to the caller to handle that memory, WPILib will never hold onto that memory longer than the call. If a WPILib API takes a WPI_String*, that string is an output. WPILib will allocate that API with WPI_AllocateString(), fill in the string, and return to the caller. When the caller is done with the string, they must free it with WPI_FreeString(). If an output struct contains a WPI_String member, that member is considered read only, and should not be explicitly freed. The caller should call the free function for that struct. If an array of WPI_Strings are returned, each individual string is considered read only, and should not be explicitly freed. The free function for that array should be called by the caller. If an input struct containing a WPI_String, or an input array of WPI_Strings is passed to WPILib, the individual strings will not be manipulated or freed by WPILib, and the caller owns and should free that memory. Callbacks also follow these rules. The most common is a callback either getting passed a const WPI_String* or a struct containing a WPI_String. In both of these cases, the callback target should consider these strings read only, and not attempt to free them or manipulate them.
2024-05-13 05:35:14 -07:00
auto str = wpi::make_string(message);
HALSIM_SetGameSpecificMessage(&str);
}
void DriverStationSim::SetEventName(std::string_view name) {
Change C APIs to a unified string implementation (#6299) Currently in the entire C API of WPILib we have ~8 different ways of handling strings. The C API actually isn't built for pure C callers (We don't actually have any of those). Instead, they're built for interop between languages like LabVIEW and C# which can talk to C API's directly. For output parameters, the choice was fairly obvious. An output struct containing a const string pointer and a length makes the most sense. Its easy to use these from most other languages, and doesn't require special null termination handling. Freeing these is also easy, as if you ever receive one of these string structures, theres just a single function call to free it. Input parameters are a bit more complex. To be used from pure C, and from LabVIEW, a null terminated string is the best in most cases. However, null terminated strings in general have a lot of downsides. Additionally, from LabVIEW there are other considerations around encoding that having a wrapper struct helps make a bit easier. From a language like C#, a wrapper struct is by far the easiest, as custom marshalling can make it trivial to marshal both UTF8 and UTF16 strings down. The final consideration is its nice to have an identical concept for both input and output. It makes the rules fairly easy to understand. WPILib will not have any APIs that manipulate a string allocated externally. This means WPI_String can be const, as across the boundary it is always const. If a WPILib API takes a const WPI_String*, WPILib will not manipulate or attempt to free that string, and that string is treated as an input. It is up to the caller to handle that memory, WPILib will never hold onto that memory longer than the call. If a WPILib API takes a WPI_String*, that string is an output. WPILib will allocate that API with WPI_AllocateString(), fill in the string, and return to the caller. When the caller is done with the string, they must free it with WPI_FreeString(). If an output struct contains a WPI_String member, that member is considered read only, and should not be explicitly freed. The caller should call the free function for that struct. If an array of WPI_Strings are returned, each individual string is considered read only, and should not be explicitly freed. The free function for that array should be called by the caller. If an input struct containing a WPI_String, or an input array of WPI_Strings is passed to WPILib, the individual strings will not be manipulated or freed by WPILib, and the caller owns and should free that memory. Callbacks also follow these rules. The most common is a callback either getting passed a const WPI_String* or a struct containing a WPI_String. In both of these cases, the callback target should consider these strings read only, and not attempt to free them or manipulate them.
2024-05-13 05:35:14 -07:00
auto str = wpi::make_string(name);
HALSIM_SetEventName(&str);
}
void DriverStationSim::SetMatchType(DriverStation::MatchType type) {
HALSIM_SetMatchType(static_cast<HAL_MatchType>(static_cast<int>(type)));
}
void DriverStationSim::SetMatchNumber(int matchNumber) {
HALSIM_SetMatchNumber(matchNumber);
}
void DriverStationSim::SetReplayNumber(int replayNumber) {
HALSIM_SetReplayNumber(replayNumber);
}
void DriverStationSim::ResetData() {
HALSIM_ResetDriverStationData();
}