tsbertalan / ardu-imu Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/ardu-imu
Automatically exported from code.google.com/p/ardu-imu
What steps will reproduce the problem?
Compiling with use_magntometer =1
What is the expected output? What do you see instead?
arduimu.cpp: In function 'void loop()':
arduimu:376: error: expected unqualified-id before '.' token
arduimu:377: error: expected unqualified-id before '.' token
arduimu.cpp: In function 'void Drift_correction()':
DCM:170: error: expected primary-expression before '.' token
DCM:170: error: expected primary-expression before '.' token
What version of the product are you using? On what operating system?
Arduimu 1.8
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 16 Oct 2010 at 10:00
Hi all
I just got my arduimu v3 and its pretty easy to use thus far but I want to
incorporate a BMP085 pressure sensor and when I put use barometer to 1 I get
errors.
Output:87: error: 'temp_unfilt' was not declared in this scope
Output:88: error: 'alti' was not declared in this scope
Output:90: error: 'press' was not declared in this scope
Output:93: error: 'press_alt' was not declared in this scope
Have these declarations been forgoten in the updated code? where would I put
the declarations?
Thanks
Original issue reported on code.google.com by [email protected]
on 27 Sep 2012 at 1:19
What steps will reproduce the problem?
1. yaw values are wrong
2.
3.
What is the expected output? What do you see instead?
yaw values give aleatory or sometimes imu sends moves yaw values
What version of the product are you using? On what operating system?
arduimu v3
Please provide any additional information below.
sometimes imu don't send the correct values yaw is moved from the correct
value,
Original issue reported on code.google.com by [email protected]
on 22 Oct 2013 at 4:00
I used ArduIMU V3 and the unchanged current software release 1.9. When I look
at the YAW values, then I realize that North and South will be highly
asynchronous. YAW at hardware compass "north" is approximately 11 and hardware
compass "south" is approximately 156. Between north and south there are 145°
in clockwise and counter clockwise, there are 215°.
What is the problem and how can I fix it?
Original issue reported on code.google.com by [email protected]
on 3 Feb 2012 at 12:27
What steps will reproduce the problem?
1. Copy arduimu and libraries from ArduIMU 1.9
2. arduimu compiles in arduino 0.2.3
3. Copy libraries from ArduIMU 1.9.6
4. arduimu compiles in arduino 1.0.1
5. Copy libraries from ArduIMU 1.9.8
6. Many errors
What is the expected output? What do you see instead?
Project does not compile. Many errors
What version of the product are you using? On what operating system?
ArduIMU 1.9.8
Windows 7
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 12 Aug 2012 at 8:28
if you want to reduce the "GPS Checksum Bad" you can change one row inside
the file HardwareSerial.cpp
from
#define RX_BUFFER_SIZE 128
to
#define RX_BUFFER_SIZE 256
Original issue reported on code.google.com by [email protected]
on 16 Mar 2010 at 4:55
ArduIMU_1.9.8 target device code
Having experimented with an ArduIMU running 1.9.8 code, we found that, unless
we do a ground start with the sensor perfectly flat in the XY-plane, large
offsets are applied during subsequent operation. Looking at the code, it's
clear that ground start does a simple offset process, assuming a perfectly flat
sensor. I have not found any mention of this ground start requirement in the
Wiki.
During this ground start, an 'average' procedure is performed on 400 samples,
using the code snippet in Arduimo.ino:
for (int i=0;i<400;i++) // We take 400 readings...
{
Read_adc_raw(); // returns AN[]
for (int y=0; y<=5; y++) // Read initial ADC values for offset
AN_OFFSET[y] = AN_OFFSET[y]*0.8 + AN[y]*0.2;
...
I'm not sure quite what was intended by this, but it will not perform a simple,
linear average (which would be my choice for a simple startup offset
compensation calbration). The gain of this process tends to unity for large n,
but never reaches it (for n=4, the gain is 0.8976). Since each sample is
effectively scaled by 0.8 each time a new sample is taken, each i'th sample
ends up with a gain of 0.2*0.8^(n-i-1), where n is the sample limit, i.e.
there's an exponential bias towards to most recent samples. Apart from sample
zero, which has a gain of 0.8^n
Whilst an interrupt is set up to allow the MPU-6000 to interrupt the Atmel
processor when a data sample is ready, and this interrupt triggers the function
void MPU6000_data_int() in MPU6000.pde, the main processing loop does not use
it, instead using a 20 millisecond loop timer. Thus, the sample generation and
consumption are asynchronous (or plesiochronous), and there will be times when
a sample read hits the point at which the new sample is being updated by the
sensor (a sync slip), giving incoherent samples, and maybe even incoherent
upper/lower bytes values.
The accelerometer scaling configuration is confusing. The code in MPU6000.pde
is as follows:
MPU6000_SPI_write(MPUREG_ACCEL_CONFIG,0x08); // Accel scale 4g (4096LSB/g)
The constant 0x08 corresponds to an FSD of +/-4g according to the sensor
datasheet, but this also means a scaling of 8192LSB/g. Experiment shows the
sensor returning values around 4096 when static, suggesting that there is an
inconsistency somewhere in the code, or in the data sheet.
Since we do not know the design intent or design requirements for this code,
it's hard for us to say what is right or wrong; maybe someone more familiar
with the ArduIMU design and implementation could comment on these issues.
Thanks.
Original issue reported on code.google.com by [email protected]
on 6 Feb 2013 at 6:29
My last version of arduimu (with auto-declination disabled)
Original issue reported on code.google.com by [email protected]
on 30 Mar 2010 at 1:19
Attachments:
What steps will reproduce the problem?
1. Try to connect any ESC or servo
2. If you had more than 4?
3. Only can connect 2?
What is the expected output? What do you see instead?
What version of the product are you using? On what operating system?
ArduImu Flat v2
Please provide any additional information below.
I need some pin number, to work with the code, but I can't find anywhere...
Original issue reported on code.google.com by [email protected]
on 19 Apr 2011 at 2:05
What steps will reproduce the problem?
1. building under linux openSUSE 11.4
2.
3.
What is the expected output? What do you see instead?
the libraries don't build
What version of the product are you using? On what operating system?
v1.8.2
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 21 Aug 2011 at 4:34
I have been reading this code, as well as Bill's DCM paper, and I am wondering
if there is an available implementation (of any kind) of dead-reckoning using
the concepts from the DCM algorithm.
I noticed this file in what appear to be some of Bill's earlier implementations
(from MatrixPilot):
http://api.ning.com/files/OOZjvN9I7PtfdKmftHVruToOhl7IQQ4cfv*Pw8HbllP922hp7HimOb
7yIe*0hV0uVlqgmHKUHsDmwihbYvDFFg__/deadReckoning.c
It seems to provide dead-reckoning, but only when hooked up to GPS data. It
seems to me that the DCM concepts could be applied with a magnetometer to get
precise relative coordinates in indoor situations. Dead-reckoning could also
be used to report precise positioning information in situations where GPS
looses it's lock (ie a car's moment-by-moment turns going through a tunnel).
Are there any known implementations of this? In general, are there any good
open-source dead-reckoning algorithms I am missing? It seems like DCM is very
close to nailing down the position of an item (relative or absolute) instead of
just nailing down its orientation.
Any comments on the topic of dead-reckoning would be greatly appreciated.
Original issue reported on code.google.com by [email protected]
on 22 Jun 2011 at 1:25
What steps will reproduce the problem?
IMu works fine on the table. But then i put it in my car. AHI is just the
centrifugal vector. Drifts a lot.
I've measured the output of MPU-6000 and the values are different form v2
version hardware sensors..
Maybe there someone could do tune up for firmware to adopt v3 hardware to do
better stability of IMU?
THanks.
Virgis
Original issue reported on code.google.com by [email protected]
on 30 May 2012 at 8:10
BMP085 and HMC5843 can be used simultaneously on arduimu? how?
Original issue reported on code.google.com by [email protected]
on 28 Apr 2011 at 4:01
What steps will reproduce the problem?
1. Download and install latest version of Arduino IDE
2. Download latest ArduIMU software
3. Attempt to load ArduIMU software to ArduIMU board
What is the expected output? What do you see instead?
Code does not compile. Compiler error message "Wire.send() has been renamed
Wire.write()"
What version of the product are you using? On what operating system?
Windows 7
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 8 Feb 2012 at 3:09
if you set #define PRINT_BINARY to 0, the source does not compile.
svn revision 990
Original issue reported on code.google.com by [email protected]
on 13 Apr 2010 at 6:57
What steps will reproduce the problem?
1. download 1.9.8
2. compile it
3.
What is the expected output? What do you see instead?
compile error I had to rename Wire.write to Wire.send
and
Wire.read to Wire.receive in HMC5883
I also had to comment out AP_Common.h in various GPS files. Then it finally
compilled. is 1.9.8 not ready and should I use not so bleeding edge version.
What version of the product are you using? On what operating system?
windows XP 023 version of arduino.
Please provide any additional information below.
I followed the guide which any beginner without coding skills would have failed.
Original issue reported on code.google.com by [email protected]
on 24 Mar 2013 at 8:49
What steps will reproduce the problem?
1. Turn on IMU with GPS attached
2. Wait for GPS lock light (solid blue)
3. Disconnect GPS. Lock light remains lit
Original issue reported on code.google.com by [email protected]
on 16 Oct 2010 at 5:10
What steps will reproduce the problem?
1. uploading V1.8 to ArduIMU+ by Arduino 0019
2.
3.
What is the expected output? What do you see instead?
failed to compile: "expected constructor, destructor, or type conversion before
'(' token"
What version of the product are you using? On what operating system?
ArduPilot 2_7_1, ArduIMU+, MTK GPS, FTDI cable
Please provide any additional information below.
It seems FastSerial.h, AP_GPS.h and AP_Compass are not included in the zip.
Original issue reported on code.google.com by [email protected]
on 16 Oct 2010 at 2:43
Attachments:
What steps will reproduce the problem?
1. Put on Binary output
2. See serial output
What is the expected output? What do you see instead?
What version of the product are you using? On what operating system?
I´m using 1.9.8
Please provide any additional information below.
Hi, have tried to Convert the binary Data to my structs. Then I see that there
are no binary Data.. There was binary Data converted To ascii. In the Source
Code of Arduimu is Serial.print() instead of Serial.write() in use, which
converts the binary Data to Human Readable ascii. I have fixed this in the
attached File.
Original issue reported on code.google.com by [email protected]
on 24 Nov 2012 at 5:17
Attachments:
What steps will reproduce the problem?
1. The firmware doesn't use the INT0 and INT1 pins
2.
3.
What is the expected output? What do you see instead?
What version of the product are you using? On what operating system?
V3 on Linux
Please provide any additional information below.
The firmware doesn't seem to be using the INT0 and INT1 attached to MPU6000 and
HMC5883L, respectively. If external interrupts are abslutely necessary for the
project can those pins be used after disconnecting them from MPU6000 and
HMC5883L?
Original issue reported on code.google.com by [email protected]
on 5 Sep 2012 at 2:06
What steps will reproduce the problem?
1. Copy the arduimu and libraries to Arduino Sketchbook in My Documents
2. Press compile or verify
3. Get the error
What is the expected output? What do you see instead?
Compile, just compile
What version of the product are you using? On what operating system?
1.8.1
Please provide any additional information below.
That's the error output:
In file included from arduimu.cpp:14:
C:\Users\Debci\Documents\Arduino\libraries\FastSerial/FastSerial.h:105: error:
conflicting return type specified for 'virtual void FastSerial::write(uint8_t)'
C:\Users\Debci\Desktop\arduino-1.0.1\hardware\arduino\cores\arduino/Print.h:48:
error: overriding 'virtual size_t Print::write(uint8_t)'
Original issue reported on code.google.com by andoni94
on 22 Jul 2012 at 12:24
What steps will reproduce the problem?
1. #define PERFORMANCE_REPORTING 0
2. Build
What is the expected output? What do you see instead?
Compilation fails:
In function 'void printPerfData(long int)':
error: 'mainLoop_count' was not declared in this scope
What version of the product are you using? On what operating system?
v1.7 from zip file download. Win7.
Please provide any additional information below.
Comment suggests that PERFORMANCE_REPORTING is for uBlox only, and I'm using
MTK GPS, so it seemed sensible to disable it. Is comment incorrect?
Original issue reported on code.google.com by [email protected]
on 18 Sep 2010 at 9:01
ArduIMU build on Linux x64 with Arduino 1.0.3 fails with the following errors:
http://pastebin.com/yhzRQTe7
As you can see, some of the IO ports were not declared.
The root cause is wrong Core Includes directory: it must be
"$(HARDWARE_DIR)/variants/standard" instead of "$(HARDWARE_DIR)/variants/mega".
The offending line is located at "libraries/AP_Common/Arduino.mk", line 378.
It should be replaced with:
COREINCLUDES = -I$(CORESRC_DIR) -I$(HARDWARE_DIR)/variants/standard
However, to keep this script compatible with ArduPilot, I'd suggest to add
optional variable:
ARDUINO_VARIANT ?= mega
COREINCLUDES = -I$(CORESRC_DIR) -I$(HARDWARE_DIR)/variants/$(ARDUINO_VARIANT)
And override it in config.mk:
ARDUINO_VARIANT=standard
Hope this helps.
Original issue reported on code.google.com by [email protected]
on 25 Jan 2013 at 12:16
What steps will reproduce the problem?
1. Initialize IMU level
2. Slowly turn 90 in roll
3. Return to horizontal orientation.
4. Slowly turn -90 in roll
5. Return to horizontal orientation.
6. Repeat for pitch and yaw (yaw rotate 360 in 90 deg increments)
What is the expected output? What do you see instead?
Each axis output should correspond to the number of degrees turned
Roll reading: actual roll: - 90 deg -> RLL output: - 120
+ 90 deg -> RLL output: + 120
Pitch reading: actual pitch: -90 deg -> PCH output: -50
+90 deg -> PCH output: +50
Yaw reading: actual yaw: 0 deg -> YAW output: 180
90 deg -> YAW output: 108
180 deg -> YAW output: 45
270 deg -> YAW output: -40
360 deg -> YAW output: -180
What version of the product are you using? On what operating system?
ArduIMU V3
firmware version 1.9
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 28 Jun 2012 at 8:07
What steps will reproduce the problem?
1. Loading current code after re-configuring ardupilot to work at 57600 baud.
GPS working in binary ok.
2.
3.
What is the expected output? What do you see instead?
GPS log and lat is detected ok (as shown in IMU test program) but no fix
detected (blue LED never stops flashing).
What version of the product are you using? On what operating system?
I am using an old Arduimu v1 with v1.8.2 firmware
This is a school project and we do not have the budget to change the GPS. We
have also manufactured all the mounts to fit the EM406.
Can anyone point to the code used to detect the fix status?
We have a demo to give on Monday morning.
Many thanks
Original issue reported on code.google.com by [email protected]
on 12 Nov 2011 at 1:51
What steps will reproduce the problem?
Serial.print(Accel_Scale(Accel_Vector[2]));
What is the expected output? What do you see instead?
Using the conversion from ADC-values to accelerations by the defined scaling:
#define Accel_Scale(x) x*(GRAVITY/9.81)//Scaling the raw data of the accel to
actual acceleration in meters for seconds square
produces unexpected values.
-> expected is an acceleration in m/s2 in z-direction of about 9.81
To be correct, the conversion should be defined as:
#define Accel_Scale(x) x*(9.81/GRAVITY)//Scaling the raw data of the accel to
actual acceleration in meters for seconds square
to produce the expected output!
What version of the product are you using? On what operating system?
I'm using 1.5, but its still in 1.8
Original issue reported on code.google.com by [email protected]
on 8 Jan 2011 at 12:40
What steps will reproduce the problem?
1. Compare 1.9.8 release to repository (I couldn't find any revision that had
this magic number in it).
What is the expected output? What do you see instead?
1.9.8 contains:
void Euler_angles(void)
{
#if (OUTPUTMODE==2) // Only accelerometer info (debugging purposes)
roll = 1.9*atan2(Accel_Vector[1],Accel_Vector[2]); // atan2(acc_y,acc_z)
pitch = -1.9*asin((Accel_Vector[0])/(double)GRAVITY); // asin(acc_x)
yaw = 0;
#else
pitch = -1.9*asin(DCM_Matrix[2][0]);
roll = 1.9*atan2(DCM_Matrix[2][1],DCM_Matrix[2][2]);
yaw = atan2(DCM_Matrix[1][0],DCM_Matrix[0][0]);
#endif
}
This constant of 1.9 does not appear in the repository and it is undocumented
in this release. There is a comment on the downloads page talking about
calibration for pitch and roll, but it is unclear if it refers to this. It's
also not clear why the calibration is performed after extracting the angles and
not on the sensor measurements themselves.
What version of the product are you using? On what operating system?
1.9.8 from the downloads section.
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 19 Jan 2013 at 9:35
What steps will reproduce the problem?
1. Setting USE_MAGNETOMETER == 1
What version of the product are you using? On what operating system?
IMU v2+; Windows 7
Please provide any additional information below.
#if USE_MAGNETOMETER == 1
APM_Compass.Init(); // I2C initialization
debug_handler(3);
#endif
arduimu.cpp: In function 'void setup()':
arduimu:286: error: 'APM_Compass' was not declared in this scope
arduimu.cpp: In function 'void loop()':
arduimu:385: error: 'APM_Compass' was not declared in this scope
arduimu.cpp: In function 'void Drift_correction()':
DCM:170: error: 'AP_Compass' was not declared in this scope
also, how does one define which orientation matrix to use? is it here?
virtual void set_orientation(const Matrix3f &rotation_matrix);
Original issue reported on code.google.com by [email protected]
on 27 Dec 2010 at 3:18
What steps will reproduce the problem?
1. Just buy the ArduIMU V3.
2. Follow the instructions to load the wow "software"
3. Dump your money in the garbage.
What is the expected output? What do you see instead?
What I expect? Buy a product that really works, If don't, have some support
from the manufacturer. As far I can see on all forums and Wiki's nobody have a
ArduIMU working as advertised in your website as "Functional" IMU.
What version of the product are you using? On what operating system?
Tested all of them in the repository.
Please provide any additional information below.
My sadness?
Original issue reported on code.google.com by [email protected]
on 25 Dec 2013 at 5:45
Hi
I've added some enhancement
1. to start "ground mode" you simply press one button while starting the
device and release after the leds blinking. No more actions are necessary.
2. Compensating the Hard-Iron effects, when start in "ground mode" you must
make one complete turn ( turned off red led when ok). The value are stored
in the eeprom for the "air mode" use.
3. Added declination compensation calculated when the first time of the gps
speed are over 10m/s. Stored in the eeprom for future restart.
4. The YAW value are linked only to Magneto value and never to GPS.
Original issue reported on code.google.com by [email protected]
on 18 Mar 2010 at 8:01
Attachments:
What steps will reproduce the problem?
1. Connect 3.3v ftdi to either win 7 or os x, with up to date ftdi drivers
2. Compile and upload 1.9.8 code under Arduino duemilanove 382
3. Code will compile but never upload with no errors after letting run for 20+
minutes
What is the expected output? What do you see instead?
Expected to upload and run code, but only RX light comes on, when I would be
expecting to TX the new code to the IMU
What version of the product are you using? On what operating system?
V3, tried on OS X and Win 7 with RTS close option checked.
Please provide any additional information below.
If any further questions please do not hesitate to contact me.
Original issue reported on code.google.com by [email protected]
on 5 Mar 2013 at 8:29
What steps will reproduce the problem?
1. Set #define GPS_PROTOCOL 2
2. Load the code to the ArduIMU
3. Open the serial monitor and set the baud rate to 38400
If you set the baud rate at 38400, you get garbled data, change it to 57600 and
it is all clear. This should be clarified because in the ArduPilot 2.7.1 code,
it is set to receive the data at 38400.
This problem is most likely caused by AP_GPS library. AP_GPS_406.h is set to
#define GPS_406_BITRATE to 57600. I am assuming that the bitrate is set that
way because of the EM406 device, therefore, it should be noted elsewhere in the
code that the bitrate will change with this device.
Original issue reported on code.google.com by [email protected]
on 10 Jun 2011 at 9:41
The SIRF GPS (EM406A) still seems not to work with the arduimu with the current
avn code.
Original issue reported on code.google.com by [email protected]
on 13 Apr 2010 at 8:07
What steps will reproduce the problem?
1. Activate the itow for class NAV-VELNED
2. Compare the two itows for class NAV-POSLLH and for class NAV-VELNED, they
are different
3. When I print the ground speed/course, sometimes they update while sometimes
they just stop updates, very inconsistent
What is the expected output? What do you see instead?
The ground speed/course should updates at the same time as the GPS longitude,
latitude, altitude,etc. What I observe is they can not do that
What version of the product are you using? On what operating system?
1.7.1 and 1.8.1 versions, windows vista, Arduino 0021.
Please provide any additional information below.
when I disable the SOL message on Ublox, the ground course and speed update
together with the latitude, longitude, etc.
Original issue reported on code.google.com by [email protected]
on 13 Nov 2010 at 11:01
Initial steps:
1. ArduIMU + MediaTek GPS connected to PC using the FTDI cable
2. Loaded the ArduIMU software version 1.9.8 using Arduino IDE 1.0.1
3. Tested the output using the test software
Results:
The ArduIMU is stationary over the desk and the test software shows a cube
which keeps on rolling. I had to modify the ArduIMU code in order to get the
GPS data correctly ( AP_GPS_MTK16 GPS(&Serial); ) and I have corrected the
magnetic variation using the value provided by the web site in the code comment.
This is my configuration:
#define GPS_CONNECTION 0 // 0 for GPS pins, 1 for programming pins
// GPS Type Selection - Note Ublox or MediaTek is recommended. Support for
NMEA is limited.
#define GPS_PROTOCOL 4 // 1 - NMEA, 2 - EM406, 3 - Ublox, 4 -- MediaTek
// Enable Air Start uses Remove Before Fly flag - connection to pin 6 on
ArduPilot
#define ENABLE_AIR_START 0 // 1 if using airstart/groundstart signaling, 0 if
not
#define GROUNDSTART_PIN 8 // Pin number used for ground start signal
(recommend 10 on v1 and 8 on v2 hardware)
/*Min Speed Filter for Yaw drift Correction*/
#define SPEEDFILT 2 // >1 use min speed filter for yaw drift cancellation
(m/s), 0=do not use speed filter
/*For debugging propurses*/
#define PRINT_DEBUG 0 //Will print Debug messages
//OUTPUTMODE=1 will print the corrected data, 0 will print uncorrected data of
the gyros (with drift), 2 will print accelerometer only data
#define OUTPUTMODE 1
#define PRINT_DCM 1 //Will print the whole direction cosine matrix
#define PRINT_ANALOGS 0 //Will print the analog raw data
#define PRINT_EULER 1 //Will print the Euler angles Roll, Pitch and Yaw
#define PRINT_GPS 1 //Will print GPS data
#define PRINT_MAGNETOMETER 1 //Will print Magnetometer data (if
magnetometer is enabled)
// *** NOTE! To use ArduIMU with ArduPilot you must select binary output
messages (change to 1 here)
#define PRINT_BINARY 0 //Will print binary message and suppress ASCII messages
(above)
// *** NOTE! Performance reporting is only supported for Ublox. Set to 0 for
others
#define PERFORMANCE_REPORTING 0 //Will include performance reports in the
binary output ~ 1/2 min
/* Support for optional magnetometer (1 enabled, 0 dissabled) */
#define USE_MAGNETOMETER 1 // use 1 if you want to make yaw gyro drift
corrections using the optional magnetometer
// Local magnetic declination (in degrees)
// I use this web : http://www.ngdc.noaa.gov/geomagmodels/Declination.jsp
#define MAGNETIC_DECLINATION 2.382 // corrects magnetic bearing to true north
// Magnetometer OFFSETS (magnetometer calibration) (only for ArduIMU v3)
#define MAG_OFFSET_X 0
#define MAG_OFFSET_Y 0
#define MAG_OFFSET_Z 0
/* Support for optional barometer (1 enabled, 0 dissabled) */
#define USE_BAROMETER 0 // use 1 if you want to get altitude using the
optional absolute pressure sensor
#define ALT_MIX 50
Did they tested this software??!?!?
Thank you,
Alessandro Munari
Original issue reported on code.google.com by [email protected]
on 25 Oct 2012 at 11:26
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.