kipr / libwallaby Goto Github PK
View Code? Open in Web Editor NEWLibrary for interfacing with the Wombat firmware
License: GNU General Public License v3.0
Library for interfacing with the Wombat firmware
License: GNU General Public License v3.0
Doxygen doesn't generate documentation for all of the libwallaby functions.
We need to go through and make sure every function that is pulled by doxygen has a description and an example usage if applicable.
get_servo_enabled() currently returns 0 if enabled and 1 if disabled. This might be an issue in the Private C++ function.
This pull request was the first attempt at adding this functionality: #81
The commits made there are so far behind master at this point that I think it is likely to cause issues even if we resolved the merge conflicts.
Additionally, botball_c should just not be changed at all by the pull request as the modern version is much different.
The modern one also does not use graphics so the added #ifdef is not necessary (and is only necessary if that was added because of emscripten requirements).
For some reason the difference viewer did not show the correct version of the master's botball_c?
Probably due to the age of the branch and the evolution of that file.
I personally think it would be easier to just go through each commit made there, and reapply it with the context of the current master. However, someone with a better understanding of git or emscripten may be able to fix the old pull request.
It also seems to be bundled with other changes not relevant to emscripten, but I also don't know enough about emscripten to know that for sure. If the person solving this issue understands emscripten, take consideration when re-adding the changes.
Formatting is kinda inconsistent...
I suggest there be a standard ruleset. It could be explicitly put in the readme in a separate section marked 'formatting'.
Here is a PR for the first attempt at doing this: #73
The KIPR-Update repository is now configured to install a managed mode configurator file. I plan to eventually add the ability to interact with that function to the wifi screen so that the Wombat can connect to wifi sources.
If we do that, TCP (or UDP/other) functionality will be a necessity so that we can add functions such as:
It would also be nice if we could find a way to simplify the TCP connection process, similar to how the create_connect() handles complexity in the background.
Functions like:
TCP_connect(char* ip, char* port);
TCP_disconnect();
TCP_send(char* data);
Here is a link to the Unity Simulator:
https://github.com/Zacharyprime/RoboSim
Here is the TCP code for it:
https://github.com/Zacharyprime/RoboSim/blob/main/RoboSim/Assets/Scripts/Network.cs
(note: the sim is a unfinished, barely even started project as of writing this)
Eugene has already put work into this, it would be necessary to reach out to him, find his repo/branch, or have him comment on this issue to get the current progress of his work.
This discussion may be relevant, please take a look at Eugene's comments: kipr/botui#73
I'm not sure exactly how we should do this, but at some point we need a way for libwallaby to be able to manage ROS.
Ideally it would be nice for libwallaby to manage a ROS network in a simple way.
But it could also be as simple as adding in ROS stuff directly like making a publisher or subscriber.
This issue causes when we install the package via the following command
"sudo dpkg -i libwallaby_25.4-1_armhf.deb"
When we test the application by running the "make && sudo make install", everything works perfectly.
Motor functions like mav()
and mtp()
are not capped at a velocity of 1500. Similarly motor()
is not capped at 100. You can pass any int
velocity and it gets written.
This initially caused problems in the simulator (see kipr/Simulator#88), and while we'll add a limit there, it feels like libwallaby should cap it for controllers too. I'm not sure how the controller currently behaves if you exceed 1500.
...particularly the scaling.
libwallaby currently uses a signed short for +/- 2G so we get about 2^12 per G.
A typical un-calibrated reading from the test program with the board flat on a table would look like:
ax: 359 ay: 244 az: -16595
Will need to redefine include guards with new names
libwallaby/include/kipr/gyro.h
Line 8 in 354de42
I created a ASCII lightbulb replacement for wait_for_light.
There is a ~2 second delay added from this which we had to account for at the tournament.
The graphical library now works on Wombat (afaik) so we should add back the old graphical version to prevent an advantage for Wallabies.
camera_open
is called even though the camera is plugged incamera_load_config() appends the ".conf" extension, even if the user already provided it. We should check for the extension instead of always appending it.
Lack of bindings for python and java renders programs written in those languages incompatible with wallaby.
I'm making a github tutorial and this is a fake issue so I can get a screenshot.
Currently we only support 160x120. It would be nice to support at least 320x240.
Firmware updates have been pushed out to the Wallabies but haven't been pushed to this repo. Are they somewhere else?
During the tournament I saw multiple teams whose shut_down_in in python was not functional. I ended up having them use sys.time() to keep track of their timing as a fix is probably going to take an hour or more of development time.
I tested it in C and it was functional so it might be an issue in compilation from python to C.
My rough guess is that shut_down_in utilizes pthread to keep track of time but I haven't gotten into the source code for it yet.
The graphics section of libwallaby does not function on the Wombat.
I don't remember how as we discovered it a long time ago, but I would like to attempt to fix it in the future.
https://files.kipr.org/wallaby/wallaby_doc/group__graphics.html
Warning 1:
/home/pi/dev/libwallaby/src/botball_c.cpp: In function ‘void wait_for_light(int)’:
/home/pi/dev/libwallaby/src/botball_c.cpp:123:56: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
g_printString("READING - ON = ",INSET,30,BLACK,2);
Warning 2:
/home/pi/dev/libwallaby/src/botball_c.cpp: In function ‘void wait_for_light(int)’:
/home/pi/dev/libwallaby/src/botball_c.cpp:123:56: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
g_printString("READING - ON = ",INSET,30,BLACK,2);
^
In file included from /home/pi/dev/libwallaby/src/pixeltoaster/PixelToaster.cpp:17:0:
/home/pi/dev/libwallaby/src/pixeltoaster/PixelToasterUnix.h: In member function ‘void PixelToaster::UnixDisplay::handleEvent(const XEvent&)’:
/home/pi/dev/libwallaby/src/pixeltoaster/PixelToasterUnix.h:353:30: warning: ‘KeySym XKeycodeToKeysym(Display*, KeyCode, int)’ is deprecated (declared at /usr/include/X11/Xlib.h:1699) [-Wdeprecated-declarations]
const KeySym keySym = ::XKeycodeToKeysym(display_, event.xkey.keycode, 0);
^
/home/pi/dev/libwallaby/src/pixeltoaster/PixelToasterUnix.h:353:78: warning: ‘KeySym XKeycodeToKeysym(Display*, KeyCode, int)’ is deprecated (declared at /usr/include/X11/Xlib.h:1699) [-Wdeprecated-declarations]
const KeySym keySym = ::XKeycodeToKeysym(display_, event.xkey.keycode, 0);
^
In file included from /home/pi/dev/libwallaby/src/pixeltoaster/PixelToaster.cpp:17:0:
/home/pi/dev/libwallaby/src/pixeltoaster/PixelToasterUnix.h: In member function ‘void PixelToaster::UnixDisplay::handleEvent(const XEvent&)’:
/home/pi/dev/libwallaby/src/pixeltoaster/PixelToasterUnix.h:353:30: warning: ‘KeySym XKeycodeToKeysym(Display*, KeyCode, int)’ is deprecated (declared at /usr/include/X11/Xlib.h:1699) [-Wdeprecated-declarations]
const KeySym keySym = ::XKeycodeToKeysym(display_, event.xkey.keycode, 0);
^
/home/pi/dev/libwallaby/src/pixeltoaster/PixelToasterUnix.h:353:78: warning: ‘KeySym XKeycodeToKeysym(Display*, KeyCode, int)’ is deprecated (declared at /usr/include/X11/Xlib.h:1699) [-Wdeprecated-declarations]
const KeySym keySym = ::XKeycodeToKeysym(display_, event.xkey.keycode, 0);
This one will probably require some digging.
Doxygen and it's respective files are ancient in their implementation (like a lot of things).
We need to go through and bring everything up to the modern doxygen.
Additionally, we should check to make sure the page is actually being generated on build and not static files.
Cmake claims to be generating them, and it's told to do so in Cmakelists.txt but the way it acts about it is a little shady.
I've also had issues in the past with the documentation being generated.
After cleaning up we can standardize the commenting better.
I'm trying to obtain the camera object. Would I need to include camera_c_p.cpp and then use DeviceSingleton::instance() ?
Once I have the object, how do I grab a frame?
The doc
folder that's generated is not gitignored, resulting in ~1000 changes that git tries to track after a build. Unless there's desire to have a version of the generated docs in source control, I think it makes sense to gitignore the folder.
In botball_c.cpp the wait_for_light function does not properly take light sensor readings.
camera_load_config() does not seem to be working, as it always returns 0 and does not load the requested configuration.
For our test conditions, we have a single color configuration file ("Canberra.conf") specified in the GUI that sets up a single channel (I am not sure where this is stored in the file system). This configuration file was not designated as the default (and no others were). camera_load_config() returns a zero (presumably indicating an error) - and any call to get_object_count(0) results in a printed error message that the "specified channel must be between 0 and some-large-number." This suggests that a configuration had not been set up.
Furthermore, when Canberra.conf is configured as the default configuration in the GUI, camera_load_config() still behaves the same, however get_object_count(0) does not fail.
//////////////////////////////////////////////////////////////////////////////////////////////////////
int main()
{
int res;
res = camera_open(LOW_RES);
printf("Open result: %d\n", res);
// Does not seem to work: always returns 0
res = camera_load_config("Canberra.conf");
printf("Configuration result: %d\n", res);
int object_count;
point2 p;
while(digital(1) == 0)
{
// Address buffering issue
res = camera_update();
res = camera_update();
res = camera_update();
res = camera_update();
printf("Update result: %d\n", res);
object_count = get_object_count(0);
printf("Number of objects %d \n",object_count);
if(object_count > 0){
p = get_object_center(0,0);
printf("Largest object: %d %d\n", p.x, p.y);
}
msleep(500);
}
camera_close();
printf("Done...\n");
msleep(500);
return 0;
}
Currently, HSVChannelImpl objects all have a confidence of 1.0. We should implement a confidence value between 0.0 and 1.0 that is a function of the contour area and the bbox area.
Create and reorder the function calls so that they are no warnings further
The lower 8 bits are not being cleared.
This may be an issue with writeRegister32b
If the camera is being used by another source, camera_open() usually crashes the user program.
When the program exits on the Wombat, it shows the destructor ~Wallaby() on the console output.
Carol pointed this out to me while doing a workshop so I presume it confused a student/teacher.
This is connected to kipr/KIPR-Update#15
When using the wait_for_light function from libwallaby, our motors and servos would sometimes behave very strangely (motors not moving at full speed, servos moving without instruction). It doesn't happen all the time, and we are unfortunately not sure how to reproduce it.
cc1: warning: command line option ‘-std=c++11’ is valid for C++/ObjC++ but not for C
This happens multiple times during the build process.
However, I hope that the cleanup crew project will solve this in the process.
If not, it should be addressed eventually. I'm not sure if the line needs to be removed or the compiler needs to stop treating those pieces as C (I believe the latter).
When using the camera, errors from libjpeg continuously output to standard out.
Tello PR needs testing and to see if it can be merged in with refactor before final merge.
We made an update to the CMake configuration that enforces C++11 mode over C++0.
It also now uses CMAKE_CXX_STANDARD which was introduced in cmake 3.1; this also causes a minor inconvenience because we are still stuck on Debian Jessie, which is obsolete and cannot pull updated packages for cmake 3.1 without some finagling.
This was a step in the right direction, but it has caused some other problems with the standard changes between C++11 and C++0 mode.
I ran into this while working on a different issue. A temporary solution is to paste the old cmake C++11 handling back in.
It shouldn't be too difficult to fix, I'm mainly leaving this as a reminder so I can finish solving the first issue I was doing.
Example of one of the errors produced:
/home/pi/got2/libwallaby/src/digital_c.cpp:13:38: error: ‘nullptr’ was not declared in this scope
return Private::digital_value(port, nullptr);
^
Determining the scope of groups...
/home/pi/got2/libwallaby/src/digital_c.cpp: In function ‘int get_digital_value(int)’:
/home/pi/got2/libwallaby/src/digital_c.cpp:23:39: error: ‘nullptr’ was not declared in this scope
return (Private::digital_value(port, nullptr) ? 1 : 0);
^
Sorting lists...
/home/pi/got2/libwallaby/src/digital_c.cpp: In function ‘int get_digital_output(int)’:
/home/pi/got2/libwallaby/src/digital_c.cpp:33:40: error: ‘nullptr’ was not declared in this scope
return (Private::digital_output(port, nullptr) ? 1 : 0);
Old Version:
# C++11
# http://www.guyrutenberg.com/2014/01/05/enabling-c11-c0x-in-cmake/
include(CheckCXXCompilerFlag)
CHECK_CXX_COMPILER_FLAG("-std=c++11" COMPILER_SUPPORTS_CXX11)
CHECK_CXX_COMPILER_FLAG("-std=c++0x" COMPILER_SUPPORTS_CXX0X)
if(COMPILER_SUPPORTS_CXX11)
add_definitions(--std=c++11)
elseif(COMPILER_SUPPORTS_CXX0X)
add_definitions(--std=c++0x)
else()
message(STATUS "The compiler ${CMAKE_CXX_COMPILER} has no C++11 support. Please use a different C++ compiler.")
endif()
New Version:
# C++11
set(CMAKE_CXX_STANDARD 11)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF)
This will most likely require getting ROS2 working on the controller, which may prove to be a daunting task.
https://github.com/iRobotEducation/irobot_create_msgs
https://github.com/iRobotEducation/create3_examples
(These repositories are private, only people under the NDA with iRobot may view them)
Related Issue:
kipr/KIPR-Development-Toolkit#6
set_a_button_text
set_b_button_text
set_c_button_text
These functions do not change the text on the buttons when running programs.
This has been an issue for a while, but I must have forgotten to submit one.
The graphics library that we use for wait_for_light and usually the starting light program (and can be used in programs but rarely is), currently crashes botui or doesn't work at all.
I have seen a screenshot of a Wombat Tim got to display a graphic, but I haven't been able to reproduce it on any other Wombat.
I'll add a comment if I/Tim get more context from the photo. For all I know it was a cropped image of a Wallaby.
It's most likely that the graphics library used some underlying graphics framework of the Wallaby that Raspberry Pis don't have.
If the image I saw was a real Wombat, then maybe it's a bug that got added moving the code over to the Pi during development phase.
We need a conversion from voltage to battery capacity here:
https://github.com/kipr/libwallaby/blob/master/include/wallaby/battery.h#L28
The set_create_distance
and set_create_total_angle
functions occasionally set the angle counters to extreme values.
When I run the code below, the create will turn back and forth for a while, but eventually it will either miss a rotation going counterclockwise or rotate clockwise forever. In both cases, the displayed value for get_create_total_angle
will be around 18000. I'm not sure if it is the same value every time, but it's always in the same ballpark.
The issue is fairly rare, it usually takes a couple minutes of turning before I see it with the code below, but that is often enough to occur in about 1/4 of my runs.
A similar issue exists for set_create_distance, but I haven't looked into that one as much. The value the bug sets create_distance to is about 6000.
void create_turn_in_place(int degrees, int speed){
int cached_angle;
speed = abs(speed);
set_create_total_angle(0);
if(degrees>0){
create_spin_CCW(speed);
cached_angle = get_create_total_angle();
while(cached_angle<degrees){
cached_angle = get_create_total_angle();
display_printf(0, 0, "%d ", cached_angle);
msleep(10);
}
}
else{
create_spin_CW(speed);
cached_angle = get_create_total_angle();
while(cached_angle>degrees){
display_printf(0, 0, "%d ", cached_angle);
msleep(10);
cached_angle = get_create_total_angle();
}
}
create_stop();
}
int main(){
create_connect();
while(1){
create_turn_in_place(180, 100);
create_turn_in_place(-180, -100);
}
}
Also, I've tried using these wrappers, but they didn't help. That might suggest that the bug is somewhere besides the actual set functions, but I'm not sure where else it could be.
void set_create_total_angle_fixed(int angle){
do{
set_create_total_angle(angle);
}while(get_create_total_angle()!=angle);
}
void set_create_distance_fixed(int dist){
do{
set_create_distance(dist);
}while(get_create_distance()!=dist);
}
For the:
This is on the refactor branch.
I get a segfault when trying to run a program containing a motor function.
It occurs when calling the function WombatDevice::transfer
(gdb) backtrace
#0 0x76a2852c in WombatDevice::transfer(unsigned char const*, unsigned char*, unsigned int) () from /lib/libkipr.so
kipr/libwallaby#1 0x76a28254 in WombatDevice::w8(unsigned char, unsigned char) ()
from /lib/libkipr.so
kipr/libwallaby#2 0x76a26b4c in kipr::core::Platform::writeRegister8b(unsigned char, unsigned char) () from /lib/libkipr.so
kipr/libwallaby#3 0x76a4282c in kipr::motor::set_motor_mode(unsigned int, unsigned char) ()
from /lib/libkipr.so
kipr/libwallaby#4 0x76a3eb20 in move_at_velocity () from /lib/libkipr.so
kipr/libwallaby#5 0x76a3eb60 in mav () from /lib/libkipr.so
kipr/libwallaby#6 0x76a3efbc in motor () from /lib/libkipr.so
kipr/libwallaby#7 0x000105c8 in main ()
This is the file those last functions are defined in.
https://github.com/kipr/libwallaby/blob/refactor/module/core/src/device/wombat/wombat_device.cpp
I thought maybe it could be something wrong with the STM32 since I had some troubles with that earlier.
But analog functions are working fine so the communication with STM32 is not broken.
While testing the camera live view, BOTUI crashes when we try to go back.
This issues seems to be there after the merging of the pull request #106
Look into what resources are being consumed for the camera and what is being returned from the functions while calling any of the camera functions.
I am very new to compiling, so apologies if this may seem redundant, but what are said libraries in below error?
[ 39%] Linking CXX shared library libkipr.so
/usr/lib/gcc-cross/aarch64-linux-gnu/11/../../../../aarch64-linux-gnu/bin/ld: cannot find -lkj: No such file or directory
/usr/lib/gcc-cross/aarch64-linux-gnu/11/../../../../aarch64-linux-gnu/bin/ld: cannot find -lkj-async: No such file or directory
/usr/lib/gcc-cross/aarch64-linux-gnu/11/../../../../aarch64-linux-gnu/bin/ld: cannot find -lcapnp: No such file or directory
/usr/lib/gcc-cross/aarch64-linux-gnu/11/../../../../aarch64-linux-gnu/bin/ld: cannot find -lcapnp-rpc: No such file or directory
/usr/lib/gcc-cross/aarch64-linux-gnu/11/../../../../aarch64-linux-gnu/bin/ld: cannot find -lcreate3_common: No such file or directory
/usr/lib/gcc-cross/aarch64-linux-gnu/11/../../../../aarch64-linux-gnu/bin/ld: cannot find -lcreate3_client: No such file or directory
/usr/lib/gcc-cross/aarch64-linux-gnu/11/../../../../aarch64-linux-gnu/bin/ld: cannot find -lX11: No such file or directory
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/kipr.dir/build.make:250: libkipr.so] Error 1
make[1]: *** [CMakeFiles/Makefile2:1605: CMakeFiles/kipr.dir/all] Error 2
make: *** [Makefile:156: all] Error 2
These dependencies were not mentioned in the docs?
Any help appreciated. Thanks!
The discord user "Jammo2000" has reported that mrp is not functional.
He said he recreated the problem using the following code:
#include <kipr/wombat.h>
#define right_motor 1
#define left_motor 3
int main(){
int i;
for(i = 0;i<100;i++){
mrp(right_motor, 1000, -1000);
mrp(left_motor, 1000, 1000);
bmd(right_motor);
bmd(left_motor);
msleep(1000);
mrp(right_motor, 1000, 1000);
mrp(left_motor, 1000, -1000);
bmd(right_motor);
bmd(left_motor);
msleep(1000);
}
return 0;
}
Quote from the user:
"So, the move_relative_position (mrp) function in the kipr library is broken. 5-10% of the time it simply fails to move the motor at all."
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.